How to ensure the safety of Self-Driving Cars: Part 4/5
So, the car has its plan, and we’re pretty confident in that plan based on Part 2 and Part 3. But it’s still just a plan, the vehicle now needs to execute. We call this the “Act” phase, and that can be short for “Action” or “Actuation.” The car needs to give commands to each actuator, which are most commonly brake, accelerator, and steering box. However, this can also include other actions like changing the suspension settings in real-time (active or semi-active suspension) or applying (vectoring) more brake or acceleration on one wheel over another. This can even actuation modes we’ve haven’t thought of yet, but due to the fact a robot is driving the vehicle and not a person, can be implemented.
Some of these crazy actuation modes might include turning each wheel independently, or leaning the wheel along with turning. It might include an actuator that controls the angle of the trailer that follows a vehicle. It might be self-balancing a vehicle by moving a ballast. It could be anything! This concept can lead to futuristic vehicle designs that can still navigate the road safely due to the diligence the engineers performed in the sensing, panning, and acting software development stage:
Part 4: How well did the self-driving car act out its plan?
What do engineers need to verify here? They need to check that the plan was executed, and how accurately. They need to determine how fast the vehicle recovered from path deviations. They need to determine how quickly the vehicle took an input from the plan stack and sent out commands, then how quickly the vehicle took to respond to those commands. They need to determine how to do better.
The following sections will look at each of these concerns and determine how engineers are and will eventually ensure that the vehicle does want it’s supposed to do.
How accurately did the vehicle stick to its planned path?
The field of study that’s used to answer this question is “control theory.” Control Theory is the study of control systems, which are functions that have inputs and outputs, and can feedback information from the real world to make better outputs:
Imagine trying to heat liquid on a stove to a set temperature below boiling. If you crank the flame on the stove up all the way, you’ll get to the temperature fast, but you’ll likely overshoot it and then you’ll have to crank it back down. If you barely turn the flame on, it’ll take a long time for the liquid to heat, or you may never get there. If you crank up the temperature as much as possible in the beginning and gradually turn the flame lower as it approaches the right temperature, you’ll get to the correct temperature fast with no overshoot.
The same principle applies anytime a system wants to get to a desired output, or a “set point.” For an autonomous vehicle, this may be a steering command, acceleration value, or brake percentage. Engineers must “tune” their control system for any of these commands to get to their desired value as quickly as possible and without overshoot. Luckily, there’s a whole series of tools and techniques in control theory to optimize this process. For every single command, we need to be sure the control system is tuned in such a way that it gets to its setpoint as fast as possible without overshoot.
So, when we look at the GPS data from the autonomous vehicle and check how closely a vehicle stuck to its intended path over changes in actuation, we have a place to start to improve this. If engineers individually tune every control parameter to optimize each response, and they still see deviations from the vehicle’s intended path, something else in the AV stack must be the culprit.
How did the vehicle recover from path deviations?
Even if we’re sure the control system is tuned appropriately, there will still be deviations in the intended path due to unforeseen interference. For example, if a rock rolls under a tire and the tire hops slightly, how does the vehicle recover?
You may think that the sense system should adjust for a new scenario and the plan system should change course. But if the deviation is small enough, some small adaptions in actuation may be a more efficient way to handle this scenario.
What element of the AV stack to use for each scenario is an engineering decision. Whatever decision is made on the method for accounting for path deviations, rest assured there will be simulation and testing involved with lots of data.
How fast did the vehicle respond to its path decisions?
Engineers will tune their step-responses from their control systems as best as possible to get the fastest response. But that’s just one element of the response time of the control system. Engineers will also need to benchmark how fast that decision took to make, or the loop time for the control system. They will have to account for any latency for the CAN bus for electrical signals to travel to the actuators. The right selection and placement of hardware will dramatically affect this latency.
Of the elements in the AV Stack, the final control that decides actuation is most likely the highest priority in terms of latency. For that reason, it is very possible that engineers may use dedicated ASICs for these control systems. We need to be sure the hardware does what its told to do and as quickly as possible, since this is the last line of defense between the AV stack and the road.
How can the vehicle do better?
Now that we have all this data, we can take some time and really crunch it to determine how each vehicle can function better and safer. It’s also an opportunity to look at entire fleets of vehicles and see if we can’t see any trends in how the vehicles are operating.
Perhaps the engineers built a model of the vehicle in their software for determining how much brake to apply based on desired acceleration and current vehicle speed. Maybe the data shows that under certain scenarios, that brake amount proved insufficient. By data analysis, we can find that in those cases where the brake was insufficient, it turns out the vehicle was going downhill. So, the engineers build a new model by analyzing the brake percentage vs vehicle speed vs inclination of the road, using best-fit linear regression. They can then plug this new model into their AV stack, test it, and deploy it. Now, the vehicle stops perfectly every time.
We should be able to find these trends in vehicle data, whether that data is with a real car on the road or with simulated data from MIL, SIL and HIL. We can optimize the AV stack by tying that data back to the specific elements of the AV stack and understanding where to improve.
There’s just so much data, and not an easy way to do this! Well, maybe we’re working on something to help 😊.
Conclusion
There you have it. We should be confident that the act phase of the vehicle will respond appropriately, but there will always be ways to improve. I think there will be much more effort spent in the challenges of sensing and planning, though it behooves us not to forget about actuation.
Read the Rest of the Series: How to ensure the safety of Self-Driving Cars
