By: Julia Ng

Editor’s note: This is the latest post in our NVIDIA DRIVE Labs series, which takes an engineering-focused look at individual autonomous vehicle challenges and how NVIDIA DRIVE addresses them. Catch up on all of our automotive posts, here.



Safety Force Field (SFF) vehicle software is designed specifically for collision avoidance. It acts as an independent supervisor on the actions of the vehicle’s primary planning and control system, which could be either human-driven or autonomous. Specifically, SFF performs real-time double-checks of the controls that were chosen by the primary system. If SFF deems the controls to be unsafe, it will veto and correct the primary system’s decision.

SFF is provably safe, in the sense that, if all road participants comply with SFF and the perception and vehicle controls are within expected design margins, then it can be mathematically proven that no collisions can occur.



How SFF Works



SFF leverages perception data from various sensor types to compute a physics-based forward simulation of all perceived objects in surrounding traffic. SFF forward-computes them executing a Safety Procedure, which is a trajectory that would safely bring each object to a stop. For example, one safety procedure could be defined by braking-only, while another could be defined by steering to align with the direction of traffic and then braking.



Each object traces out a trajectory, or more formally, a volume in space-time that it would physically occupy during the execution of a safety procedure — we call this the vehicle’s Claimed Set. Overlap between claimed sets of different objects physically means there is risk they will occupy the same space at the same time in the future, i.e. collide. As soon as any claimed set overlap happens, SFF mandates that these objects take action to mitigate the situation, and computes the best real-time control commands for each object.



To decide what control command is “best” for each object, SFF leverages a mathematical function called safety potential that is a numerical measure of how safe a given situation is. SFF performs a perturbation analysis on claimed set overlaps between objects to see which control actions would help avoid the collision, and how much better they would be compared to the baseline safety procedure.



Image: The claimed set of ego car (in yellow) overlaps with claimed set (in pink) of the left-turning vehicle that is not properly yielding to ego car, indicating potential for future collision. SFF running in ego car intervenes by braking to avoid the collision.

From all control command choices, SFF picks a braking/steering combination that is least disruptive to the control action planned by the primary system, while being at least as safe as the safety procedure. In this process, SFF can also choose to steer the car in combination with braking. The steering behavior mimics the correct instinct of human drivers to steer onto a drivable shoulder to avoid a forward collision when sharp braking is not a valid option.



SFF simulates objects executing a safety procedure rather than continuing to go at their observed speeds and accelerations. The reason is that a safety procedure is defined by control actions that are always allowed from the safety perspective. The safety procedure execution is fully forward-simulated until all objects on the scene come to a stop. At that point, it is guaranteed that no more collisions can occur.



Considering Longitudinal and Lateral Components



SFF forward-simulation and collision checking is done in full three-dimensional space-time and is accelerated by GPU computing. Doing both in 3D requires higher computational capability than splitting these operations into separate longitudinal and lateral components.



Joint consideration of longitudinal and lateral components, however, is important because many real-world traffic maneuvers are neither longitudinally clear nor laterally clear, yet are safe to execute (e.g. lane change in congested traffic). Moreover, in other practical scenarios, such as missing lane markings and parking lot driving, it is not even clear what the lateral direction is. A unique aspect of SFF is that it can readily handle such complex scenarios.



For practical in-car implementation, SFF also has built-in safety procedure margins which account for real-world reaction time, as well as imperfections and latencies in other autonomous vehicle software components and subsystems.



For more information on Safety Force Field, check out the SFF white paper.

