Looking for feedback on a modified ardupilot architecture
Daniel Ricketts
I’m trying out a slightly modified architecture for ardupilot, and I’m hoping to get some feedback from the community. In many places, ardupilot has some fairly complex control logic (e.g. Loiter mode). Moreover, as processing power increases, it will be possible to execute even more complex control logic, maybe even incorporating machine learning. This is exciting because it could lead to much better performance. However, in addition to high-performance control, we might also want our autopilot software to try to ensure basic safety properties, like staying below 400 ft or staying some distance away from airports (I understand that there are scenarios where you might want to go above 400 ft, but let’s suppose that you never want that to happen). One way to try to ensure this would be to build safety logic into existing controllers (in the same way that the geo-fence is implemented). However, it could be difficult to determine if this safety logic operates correctly within increasingly complex controllers.
Another option, which I’m investigating, is to implement a simple safety “shim”, which runs after all of the ardupilot controllers have run, but before any signals are sent to the motors. This shim performs a safety check on the outputs from the higher level controllers. If the check passes then the shim issues exactly the same outputs as the higher level controllers. Otherwise, the shim issues a conservative action to try to ensure the desired safety property.
For example, if the shim is trying to preserve an altitude upper bound, it would check whether the output of the higher level controllers would put the UAV in a state in which it could not stop before the upper bound. If the check fails, the shim would induce a negative vertical acceleration.
The advantage of this architecture is that the shim logic is very simple and is guaranteed to check outputs of all controllers, regardless of the vehicle’s current mode. This means that, even if higher level controllers become extremely complex, one only needs to look at a single piece of simple code to determine if the safety logic is correct.
I’d love to get some feedback on this architecture from the ardupilot community:
Is this general architecture useful, and would it be something worth contributing to ardupilot?
Where exactly should the shim code go? At the moment, I see two places for the shim: immediately before the motor mixing code or immediately after the motor mixing code (AP_MotorsMatrix::output_armed() for a quadcopter). If the shim were to go before the motor mixing code, it would operate on throttle, roll torque, pitch torque, and yaw torque. If the shim were to go after the motor mixing code, it would operate directly on PWM values to be sent to the motor. The advantage of running before the motor mixing code is that the shim could work at a more reasonable level of abstraction. For example, the altitude upper bound shim could just change the throttle while leaving roll, pitch, and yaw to the mixing code. The disadvantage to running before the mixing code is that one has to trust the mixing code to do the right thing.
The shim architecture can result in jumps in accelerations of motors. Can this cause problems? For example, the upper bound height shim either issues exactly the output of the higher level controllers or issues a negative vertical acceleration. In certain scenarios, this can result in very fast oscillation between the positive value output by a controller (if the vehicle is trying to climb rapidly) and the negative acceleration of the shim. This doesn’t cause problems in simulation, but I can imagine these fast jumps in acceleration could cause problems in reality, or could be physically unachievable. Ultimately, I’ll run the shim on an actual quadcopter, but I’d love some feedback from experienced developers/pilots as well.
Point 3 above is just one example where we want to be extra careful before trying something new on a live quadcopter. We've been relying on the simulator to guide us but this begs the question: how trustworthy is the simulator? Suppose we simulate a new controller technique and it works well in simulator, how good an indication is it that it will work well in practice? Have you experienced surprises when going from the simulator to a real quadcopter?
This new architecture is part of a project at UC San Diego on formal verification of controller software in UAVs. The goal of the project is to build controllers that can be easily verified to satisfy safety properties with respect to some model of the physical dynamics of the UAV. This architecture seems well suited for that goal. However, even if you don’t believe in formal verification, this architecture could still be useful.
I’d really appreciate any feedback that people have, positive or negative.
Evan Slatyer
(1) and (2) - My intuition for this is that to make it work really well, you'll have to include most of the existing lower-level control code in the shim layer. For example, if you go outside a GPS fence, just setting torque or raw motor power values will not help at all; it's more likely to result in a crash. To get out of this situation safely you need the full attitude controller at your disposal, which then requires the full set of sensor inputs, and the EKF/DCM attitude estimator, etc. The only case where a direct motor input definitely works well is when you go to zero power to avoid altitude violations, and even that may not be optimal (eg. optimal may involve using the motor(s) to push the vehicle down, rather than letting gravity do it).
If you do include the existing code for all of those low-level modules, then you've got two copies of the code running; one which has (presumably) been very carefully verified and one that hasn't been. This is obviously a bit pointless; you might as well just delete the unverified one and have everything use the other set. After this it starts to look a lot like the existing failsafe architecture, where certain events (eg. loss of signal) can force the vehicle into specific "safe" modes (eg. return to loiter) and the lower-level code is assumed to be doing its job correctly.
It seems to me that actually the "shim" needs to go at the other end, at the highest levels (mode selection). Rather than detecting a violation and trying to control the motors directly (which, as above, is very hard) it might be better to have a bit of code that detects a violation and immediately pushes the autopilot into a "safety" mode that simply aims to avoid violations. That way, the safety mode can still use all of the essential lower-level modules (attitude estimation and control, sensor processing, etc). These modules will need to be verified, of course, but you'd have to create a verified version of them anyway for use by the shim; after verifying them for that, there's no reason not to let the rest of the autopilot use the verified modules too.
(3) Super-fast motor movements are physically unachievable, but they also don't tend to do damage. With that said, going continually from zero to full power and back is likely to eventually cause problems for either the ESCs (lots of heat dissipated during motor braking) or battery, or for the throttle servo on IC engines. This sort of thing could certainly happen if (for example) it climbs to 401ft in altitude hold mode (set to 500ft), drops back to 399ft (thanks to the shim), climbs back to 401ft (altitude hold), etc. There'd have to be logic to ensure that after a safety violation, it doesn't just go back to the mode that caused it. I've also got no idea how the attitude estimator would handle that sort of oscillation.
(4) If you set up the oscillation mentioned above and the attitude estimator in the simulator doesn't care, then the attitude estimator on the real vehicle is very likely to be fine - so it's great for testing whether the code is doing something reasonable. Obviously it won't tell you much about practical issues; if your ESCs overheat and die after the fourth oscillation, you'll only find that out with a real quadrotor.
Cheers,
Evan
Team Tiltrotor
Thanks
Randy Mackay
I pretty much agree with Evan.
Although the original arguments make a lot of sense in that we want the safeguards to be at the lowest level possible so they apply to the most flight modes and can’t be bypassed by higher level code/flight modes, I don’t think it’s going to work well if those controls are put way down at the motor control level. For example, to implement a fence, the lowest level it could be introduced is the position controller.
Sounds like you’ve already looked closely at the code but for others, the current fence logic works in two ways, it’s implemented as a separate watcher which runs continuously looking for violations, and if that happens it steps in and yanks control from the pilot or autopilot (i.e. switches to Land or RTL). In addition it’s [altitude] limits are use in the flight modes that can easily respect them (like alt hold, loiter).
-Randy
From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Evan Slatyer
Sent: 28-Feb-15 9:04 PM
To: drones-...@googlegroups.com
Subject: [Bulk] [drones-discuss] Re: Looking for feedback on a modified ardupilot architecture
Hi Daniel,
(1) and (2) - My intuition for this is that to make it work really well, you'll have to include most of the existing lower-level control code in the shim layer. For example, if you go outside a GPS fence, just setting torque or raw motor power values will not help at all; it's more likely to result in a crash. To get out of this situation safely you need the full attitude controller at your disposal, which then requires the full set of sensor inputs, and the EKF/DCM attitude estimator, etc. The only case where a direct motor input definitely works well is when you go to zero power to avoid altitude violations, and even that may not be optimal (eg. optimal may involve using the motor(s) to push the vehicle down, rather than letting gravity do it).
If you do include the existing code for all of those low-level modules, then you've got two copies of the code running; one which has (presumably) been very carefully verified and one that hasn't been. This is obviously a bit pointless; you might as well just delete the unverified one and have everything use the other set. After this it starts to look a lot like the existing failsafe architecture, where certain events (eg. loss of signal) can force the vehicle into specific "safe" modes (eg. return to loiter) and the lower-level code is assumed to be doing its job correctly.
It seems to me that actually the "shim" needs to go at the other end, at the highest levels (mode selection). Rather than detecting a violation and trying to control the motors directly (which, as above, is very hard) it might be better to have a bit of code that detects a violation and immediately pushes the autopilot into a "safety" mode that simply aims to avoid violations. That way, the safety mode can still use all of the essential lower-level modules (attitude estimation and control, sensor processing, etc). These modules will need to be verified, of course, but you'd have to create a verified version of them anyway for use by the shim; after verifying them for that, there's no reason not to let the rest of the autopilot use the verified modules too.
(3) Super-fast motor movements are physically unachievable, but they also don't tend to do damage. With that said, going continually from zero to full power and back is likely to eventually cause problems for either the ESCs (lots of heat dissipated during motor braking) or battery, or for the throttle servo on IC engines. This sort of thing could certainly happen if (for example) it climbs to 401ft in altitude hold mode (set to 500ft), drops back to 399ft (thanks to the shim), climbs back to 401ft (altitude hold), etc. There'd have to be logic to ensure that after a safety violation, it doesn't just go back to the mode that caused it. I've also got no idea how the attitude estimator would handle that sort of oscillation.
(4) If you set up the oscillation mentioned above and the attitude estimator in the simulator doesn't care, then the attitude estimator on the real vehicle is very likely to be fine - so it's great for testing whether the code is doing something reasonable. Obviously it won't tell you much about practical issues; if your ESCs overheat and die after the fourth oscillation, you'll only find that out with a real quadrotor.
Cheers,
Evan
On Tuesday, February 24, 2015 at 5:00:16 AM UTC+11, Daniel Ricketts wrote:
I’m trying out a slightly modified architecture for ardupilot, and I’m hoping to get some feedback from the community. In many places, ardupilot has some fairly complex control logic (e.g. Loiter mode). Moreover, as processing power increases, it will be possible to execute even more complex control logic, maybe even incorporating machine learning. This is exciting because it could lead to much better performance. However, in addition to high-performance control, we might also want our autopilot software to try to ensure basic safety properties, like staying below 400 ft or staying some distance away from airports (I understand that there are scenarios where you might want to go above 400 ft, but let’s suppose that you never want that to happen). One way to try to ensure this would be to build safety logic into existing controllers (in the same way that the geo-fence is implemented). However, it could be difficult to determine if this safety logic operates correctly within increasingly complex controllers.
Another option, which I’m investigating, is to implement a simple safety “shim”, which runs after all of the ardupilot controllers have run, but before any signals are sent to the motors. This shim performs a safety check on the outputs from the higher level controllers. If the check passes then the shim issues exactly the same outputs as the higher level controllers. Otherwise, the shim issues a conservative action to try to ensure the desired safety property.
For example, if the shim is trying to preserve an altitude upper bound, it would check whether the output of the higher level controllers would put the UAV in a state in which it could not stop before the upper bound. If the check fails, the shim would induce a negative vertical acceleration.
The advantage of this architecture is that the shim logic is very simple and is guaranteed to check outputs of all controllers, regardless of the vehicle’s current mode. This means that, even if higher level controllers become extremely complex, one only needs to look at a single piece of simple code to determine if the safety logic is correct.
I’d love to get some feedback on this architecture from the ardupilot community:
1. Is this general architecture useful, and would it be something worth contributing to ardupilot?
2. Where exactly should the shim code go? At the moment, I see two places for the shim: immediately before the motor mixing code or immediately after the motor mixing code (AP_MotorsMatrix::output_armed() for a quadcopter). If the shim were to go before the motor mixing code, it would operate on throttle, roll torque, pitch torque, and yaw torque. If the shim were to go after the motor mixing code, it would operate directly on PWM values to be sent to the motor. The advantage of running before the motor mixing code is that the shim could work at a more reasonable level of abstraction. For example, the altitude upper bound shim could just change the throttle while leaving roll, pitch, and yaw to the mixing code. The disadvantage to running before the mixing code is that one has to trust the mixing code to do the right thing.
3. The shim architecture can result in jumps in accelerations of motors. Can this cause problems? For example, the upper bound height shim either issues exactly the output of the higher level controllers or issues a negative vertical acceleration. In certain scenarios, this can result in very fast oscillation between the positive value output by a controller (if the vehicle is trying to climb rapidly) and the negative acceleration of the shim. This doesn’t cause problems in simulation, but I can imagine these fast jumps in acceleration could cause problems in reality, or could be physically unachievable. Ultimately, I’ll run the shim on an actual quadcopter, but I’d love some feedback from experienced developers/pilots as well.
4. Point 3 above is just one example where we want to be extra careful before trying something new on a live quadcopter. We've been relying on the simulator to guide us but this begs the question: how trustworthy is the simulator? Suppose we simulate a new controller technique and it works well in simulator, how good an indication is it that it will work well in practice? Have you experienced surprises when going from the simulator to a real quadcopter?
This new architecture is part of a project at UC San Diego on formal verification of controller software in UAVs. The goal of the project is to build controllers that can be easily verified to satisfy safety properties with respect to some model of the physical dynamics of the UAV. This architecture seems well suited for that goal. However, even if you don’t believe in formal verification, this architecture could still be useful.
I’d really appreciate any feedback that people have, positive or negative.
--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Daniel Ricketts
Thanks a lot for the feedback. It was very helpful.
@Team Tiltrotor - We’re focusing on quadrotors for now. The general goal of our project is not quadrotor specific, and we want to eventually generalize what we’ve done to cover other vehicle types. However, formal verification is very labor-intensive and we’re a relatively small team. It will most likely be a long time before we get to other vehicles.
@Randy and Evan - I see your point. Our low-level approach will only work on the few properties that don’t necessarily depend on attitude (probably just altitude and z-velocity upper bounds).
The idea of implementing the shim as mode switching logic (like the geo-fence watcher) is very interesting. However, there is one major challenge with moving our shim logic to a higher level of abstraction: even if we do verify properties of lower level modules like attitude control, the abstraction/interface that they provide is not quite what we need for verifying safety properties. This is essentially a tension between the typical goals of controllers and the safety properties that we’re trying to verify.
The goal of a controller is to eventually achieve some desired state, while our goal is to achieve bounds on state. The fact that a controller eventually achieves some desired x-y position doesn’t guarantee that the vehicle didn’t first exit a safe x-y region before returning to the desired position.
It may be the case that the strong safety properties we’re trying to verify are inappropriate for this domain. This raises the question of what properties we can verify in this domain, besides stability (in the control theory sense). In other words, if we do implement the shim as logic that switches to a safe mode at the right time, what safety properties can we verify about the safe mode, if any? Can we actually verify anything about bounds on the vehicle’s state?
In any case, you guys have given me a lot to think about. I like the idea of putting the shim as mode switching logic, but I need to think carefully about what formal properties this system could satisfy.
@Evan - We flew an actual quadcopter running our altitude limiting shim, running right after the motor mixing code. As you predicted, the attitude behavior of the vehicle was the same as in the simulation - perfectly fine. We tried flying somewhat aggressively at the upper bound at various attitudes, and there were no issues. This was surprising to me. I expected the shim to destabilize the attitude.
The motors did oscillate quite a bit at the upper bound when the pilot attempted to exceed it. The motors were able to achieve the frequency of oscillation necessary to keep the vehicle below the upper bound, and there was no obvious damage to the motors from overheating. However, the oscillation was a bit weird from the perspective of the pilot. It would be nice to have a smoother experience. I suppose this is another reason to implement the shim as mode switching logic. As you pointed out, this would prevent the vehicle from oscillating back and forth between the negative acceleration of the shim and the acceleration of the offending mode.
Evan Slatyer
It's a bit hard on the quadrotor (in that it'll probably crash frequently), but it could be very useful. There are lots of situations for UAVs where the risk or cost of going outside the allowed area is far higher than the cost of replacing a completely destroyed UAV, and having some sort of low-level, super-reliable system in place for that would be good.
Cheers,
Evan