In 2014, we wrote about some failsafe software from ETH Zurich that allowed a quadrotor to remain fully controllable even with one busted motor. The unbalanced torque generated by three motors means that a quadrotor can’t help but spin, but with a bit of cleverness, software can compensate for the spin and keep the quadrotor stable and even allow it to obey control inputs, allowing it to land more or less safely.
This is a valuable capability, but there are a few things that it doesn’t address. For example, what if your quadrotor loses a rotor over an unsafe area? What if something happens to it when it’s already traveling at a high speed? Or what if it’s trying to deliver something and really needs to make it to its destination, no matter what? At IROS 2018 in Madrid last week, researchers from Delft University of Technology presented a controller that’s able to keep a partially disabled drone flying at a high speed indefinitely, meaning that you have a better chance than ever of getting that taco that you ordered back in 2012.
It’s a little hard to tell because of all the spinning, but the drone in the video is a Parrot Bebop 2. It’s also a little hard to tell that it’s flying in a wind tunnel, but it is, to simulate high speed forward flight without having to go anywhere. The quadrotor reaches a maximum speed of 9 m/s, which is about half the maximum speed of the Bebop, but it’s fast enough for the robot to experience the kind of aerodynamic complexity that comes with flying fast while spinning (at nearly 1200 degrees per second), which has never been tested before.
Keeping the quadrotor stable while flying with three rotors instead of the four that its used to requires a specialized controller. Here, there are three separate loops: a PID loop for position control, and then two nonlinear loops for attitude control and control allocation (which sends speed commands to the rotors). The aerodynamic effects that you get from the combination of high rate spinning and high speed forward flight are nontrivial to manage, and the system has to keep careful track of data from the robot’s built-in gyro and accelerometer to compensate. Motor saturation was also an issue, meaning that the controllers would ask for more thrust than the motors could provide. To mitigate this, the Bebop was stripped of its camera to save mass, but it wasn’t enough—the 9 m/s limit was reached when all three motors saturated and the quadrotor lost control.
For the purposes of testing, the quadrotor was tracked in the wind tunnel with an OptiTrack system, since the area it had to keep itself in for the wind tunnel to work properly was relatively small. It sounds like there’s still some work to be done before trying this outside, though—in addition to more careful modeling of the aerodynamic affects (especially as speeds increase), the motor saturation problem will need to be solved somehow to allow for reliable higher speed flight. It may be the case that the Bebop just can’t handle it, and that this recovery technique will only work for higher performance quadrotors.