We’re looking to develop an automatic failsafe algorithm that will allow a qauadcopter to gracefully cope with the loss of a propeller or motor, and execute a soft landing instead of a full uncontrollobale crash.
To accomplish that, we need to be able to monitor the the current (A) consumed by each of the motors (or at least one(1) for the purpose of our test).
We thought about installing an AttoPilot current sense breakout between the PD and one of the ESCs, but we don’t know how to feed that data back to RPi/Navio+ since the blocks the RPi GPIO connector. Does anyone have any suggestion?
The ports with the most free connectors (i.e. to support at least 4/quadcopter connectors) are I2C or SPI buses or PWM (13 in total). Then you need to find a sensor which produces that output. Another alternative would be an I2C connected A2D converter chip/circuit as a bridge to those sensors.
I hope you are successful with that project, because although the X8, Y6 or hexacopter are probably the minimum redundancy to successfully fly home with standard firmware, I always wondered if it would be possible that the other motors would detect the deficiency of the broken motor/propeller and not over-react.
At least a broken fall should be possible. In an advanced scenario I wonder if the physics were possible to break a fall even when it must flip a few times.
But can you really measure the deficiency with the current alone? My guess is you need to know that the motor/propeller is not producing any lift any more. Or are you saying if the motor is accepting current, but the quadcopter is still not correcting it’s attitude, then the propeller is broken. Or when the motor is not accepting current, then the motor is broken.
Some dead-zone would be required to account for strong winds then. Isn’t there a way to see via the built-in amp sensor of APM/Navio, that the overall draw did not increase (relative to other motor changes + and -) after the motor was powered up to correct the tilt? Then maybe you don’t need any additional hardware just the logic written into APM.
Sounds like an interesting project. Could imagine you’ll get through a few frames during testing!
How about rpm sensors for each motor/prop? If the prop is not turning or turning very slow, you can be sure no thrust is produced. And since you are observing the end of the thrust “system”, you do not have to worry about which part failed. Motor blocked, ESC burned, wire broken, prop gone, everything results in zero rpms at the prop. Only problem would be windmilling, if the copter is already falling. Perhaps it is possible to catch that situation by comparing the PWM value that is going to the motor with the resulting rpm at the prop.
Another advantage would be, that you do not have another part in the power system that could fail.
That’s a very good point and there are other requests to get RPM and ESC temperature that were made on other forums. Specifically two existing methods which are available but missing APM software:
Some ESCs/firmware already sense temperature but the APM/PWM link cannot return it. They have I2C headers which could be soldered to replace PWM and add super fast (better than OneShot) update speed plus the data feedback. There is an open discussion on APM forum for genetic I2C/CAN ESC support which is moving along but very slowly.
Enable use of existing telemetry sensors, specifically update the existing FrSky SPort connector support to pass-through FrSky inputs (currently MAVLink does not allow external senor input). Then you can take off the shelf FrSky RPM and temperature sensors (and a whole lot more).
These two features together with some enhanced failure logic are three separate features which would make a big difference to APM capabilities and robustness. I think the failure/crash control logic should have options with and without the various sensors for flexibility, similar how the EKF feature improves flight/location awareness regardless of how many specific hardware devices you invest in.
I don’t use APM but I figured I’d throw my two cents in how we get motor data in our research. The new CastleCreations ESC’s have the ability to output live telemetry which includes data such as
RPM
Temperature
Current
Voltage
Ripple
In order to access the telemetry in real time you will need the Castle Serial Link and it can be set to communicate in either serial, I2C, SPI. I would imagine that it would be possible to somehow integrate it into APM or at least have APM pull the needed data off of it. The big down side to this setup is that it is somewhat expensive, especially since you will need one serial link for each ESC.
Great to know such devices are available. I think this is going to be a trend.
@Al_B I think the end result is the RPM is much more useful and given current restrictions (no MAVLink support for external sensors) you will need to program either an APM “hook” or even customize the main source code yourself.
To get an idea of how much effort is involved, I would search the code for “EKF” because that is also a whole solution which spans across the whole APM system (involving sensors and overrides to the system’s behaviour based on it’s own decision). So your code will probably need to touch almost every source file where EKF is currently referenced, excluding EKF specific stuff like GPS of course.
One approach could be that your code runs as two parts:
Detection - runs in the background checking the motor RPMs, and invokes a new type of “failsafe” when one of the drops significantly in relation to the desired motor output. Then it invokes a new failsafe mode (e.g. “Crash” mode).
Failsafe - “Crash” mode could override the motor outputs, spin or whatever you find is the best way to reduce damage. No idea here, this probably takes a lot of physics theory, research, trial and error.
Using a failsafe mode rather than hacking in everything as custom APM logic will also improve diagnostics. It will be clear when the decision was made and when the mode switch occurred. And then the pilot could always override it if it was a false alarm. For testing maybe you need to write another module which will deliberately cause one motor to fail when you flick a switch.
The whole ESC input type/upgrades to APM is going to be a long wait I think. So I would not make your project dependant on that if possible. But go to DIY Drones and at least suggest it there because maybe they already have a guide for such extensions.
Thanks everyone for your comments and suggestions. Unfortuntatly, the Castle Serial Link only takes 9V max input. Luckily, there is a similar alternative with the INA219 Current Sensor Breakout from Adafruit so we’re going to give it a try.
It might be worth to mention some high level details on how our algorithm works and why we cannot use RPM or PWM as an input.
Our APM library includes three main components: an identification block, a reconfigurable control block, and a decision making block. The identification block monitors each motor load characteristics and the current drown, based on which the failures are detected (here is where we need the input from the current sensor). The control block generates the required total thrust and three axis torques for the altitude, horizontal position and/or orientation control of the drone based on the time scale separation and nonlinear dynamic inversion. The altitude is directly controlled by the total thrust generated by the motors. The horizontal displacement as well as the orientation of the quadcopter are controlled using time scale separation and nonlinear dynamic inversion, where the torques are used to control the fastest variables, that is angular rates, which are used to control the corresponding orientation angles. The last step is to use roll and pitch angles to control the horizontal displacement of the vehicle. The decision making algorithm maps the total thrust and three torques into the individual motor thrusts based on the information provided by the identification block. When the motor current sharply drops when the load torque vanishes (e.g. the propeller broke or fell off the motor or the motor failed), then the controller is switched to the safe mode, which gives up the yaw control, commands a soft landing spot and descend rate while maintaining the horizontal attitude. This means that it won’t be possible to keep the copter flying, but it will slow it’s descent.
I’ll post back once we have some test results. Thanks again!
Whilst reading your response I thought about another twist on this. ESCs can be programmed to reverse for 3D flight. What if the ESC was programmed with 90% PWM “travel” for forwards/upwards/normal flight and 10% was used to reverse spin. Then APM would be calibrated/overridden to only use the 90% PWM cycle for usual travel, but your control override could tap into the negative 10% to make the one motor on the opposite side of the failed motor spin backwards and stabilize the spin. Maybe it only works with 45 degree pitch props, but they are common enough for racing quadcopters so I would choose one if I new such a failsafe would save damage with it. Just throwing that idea into the mix, good luck!
