Hi all,
We are a university team and need to simulate a motor failure of a drone throught the modification of the firmware. Can anybody help us in finding which class can be useful for us? We just need to decrease the power of a single motor.
We use a Pixhawk 2, the drone is the DJI F450.
Thank you!
Hello,
You can grab a branch here https://github.com/AzurDrones/ardupilot/tree/motor_failure_switch that implement a motor failure on RC switch.
To use it set MOT_FAIL_NUM to the motor number you want to make fail. Set the faillure percentage on MOT_FAIL_PCT. Use switch, let’s say channel 8, by setting RC8_OPTION to 99. Now, putting the switch at HIGH will cut MOT_FAIL_NUM output pwm by MOT_FAIL_PCT.
PLEASE !!! TRAIN ON SITL !!! TRAIN ON SIMULATOR FIRST !!! YOU CANNOT BREAK YOU SIMULATOR !!! (http://ardupilot.org/dev/docs/sitl-simulator-software-in-the-loop.html)
This is a dangerous code, so please use SITL first to test the behavior ! And validate the complet mission you will make on SITL first ! That way, no surprise !
We will be interested in the result and the study you will make on this behavior, would you share it ?
If you do choose to test in the simulator, you can set the SIM_ENGINE_MUL parameter to reduce the power to one motor (I think it’s always motor #1).
We have this PR that we think improves redundancy on a hexacopter or octacopter (or any multicopter with at least 6 motors). Here’s a video of a simulator test of this PR: https://www.youtube.com/watch?v=cVTCDsHJRcc
@khancyr https://github.com/AzurDrones/ardupilot/tree/motor_failure_switch should be in master, that would help users test and learn what a given RPAS , with a given payload , will do…
Thank you for the fast answers. Unfonrtunately, we are not able to find MOT_FAIL_NUM and MOT_FAIL_PCT. Where are they? In the Mission Planner? Because we don’t see where they are supposed to be changed.
In any case, when the test will succeed, we will let you know the results.
Thank you!
I won’t push it into master as it is dangerous … it is pretty simple to implement (I have another version with a potentiometer to chose the power)
You need to clone the branch I give you and compile the firmware from that source (I can rebase it on the last RC , if you want)
You need to set you GCS (mission planner or other) to advanced user to see those parameter.
By dangerous, do you mean because people could configure it by mistake (not more dangerous than emergency stop) - or are there any adverse effects of adding it ?
Yep, I don’t trust most user as I saw here that the majority of failure are misconfigurations, so on critical behavior like this, it is better not to include it by default … If we had a dev mode compile time option, maybe I will be more confident to propose it.
Let me suggest that you change working FAIL_NUM from 1…8 to 101…108 , that should be foolproof enough for most fools.
Remember; as engineer you should not aim to make this perfectly foolproof, nature always will beat you by creating a better idiot.
Giving this option to semi-advanced users will have a positive effect on better understanding of redundancy , as-is , too many think that >4 motors == redundancy, and expect miracles or some alternative laws of physics.
I would also suggest this motor fail testing feature be added, specifically to diagnose individual motors for vibration from ESC or prop issues. I was thinking to disconnect the ESC signal wire to all but one of my octocopter motors to test them individually, but if there’s a better way I’d be all for it!
Okey, thank you! We had an issue with the github sudmodules, but now it works and the values appears in the Mission Planner. The last doubt that we have is: how do we set the Radio Controller switch? I mean, we just have to go to “Mixer” options and set CH8 to our switch? Or there are some additional tasks? We use the Taranis plus X9D.
I think Tridge has recently added a way to test GPS failure on real vehicles and so, because this is such an often requested feature, I also think we should add it to master. My view previously was just like @khancyr - I was worried we would lose vehicles… but I think with the suggestion from @Andre-K we could avoid most mistakes. There was a similarly fatal feature added to Plane (sorry I forget the exact feature) and Tridge used a similar magic number method to protect from misuse and he’s told me that he’s seen a number of logs with the parameter set to “1”… people just like to try stuff out :-)… as far as I know, so far he hasn’t seen any mishaps.
@rmackay9 I think you mean AFS_TERM_ACTION which requires the number that is the answer to “Ultimate question of life, the universe, and everything” to enable flight termination, at least the only magic number I know in ArduPlane 
Hello, i’m a member of the Veronica’s team. After adding the fault with the firmware of khancyr we did some flight test with our drone. We set MOT_FAIL_NUM = 2 and MOT_FAIL_PCT at 0,10 and 20 and we use the channel 8 for activate the motor fault. However studying the log after the flight we noticed no significative difference in RCOU C1, C2, C3 and C4. I think we should see a drop in RCOU.C2 when channel 8 is up. I enclose the log of our fly test https://drive.google.com/file/d/1zly3folzd7IyU78vMTKOe-gBjQCS3FhX/view?usp=sharing . Thank you a lot for the help!
Marco,
do you find that the motor is slowing down though? It’s possible you could test it on the ground in stabilize mode, just be careful not to lift the throttle so high that the vehicle takes off.
Perhaps @khancyr has some ideas…
Thank you for your reply. We have already tested the fault in stabilize mode and it seemed that motor 2 was slowing down and the control was more difficult, but we want to be sure that there is really a fault by having a confirmation from the log file. Are there any parameter that we could look for in the log in order to be sure about this fault? Moreover it seems weird to us that the errorRP and ErrorY don’t increment with the fault.
However we are quite sure that we simulate the fault in the correct way since when we set the fault at 50% we saw that one motor stopped and in the log we clearly saw that RCOU dropped down.
Thank you in advance for your help.
The ATT.errRP and ErrYaw are actually from the estimation system, not the control system so they won’t show any changed based on the controls going bad. Now that you mention it, perhaps we should move those fields somewhere else…
there should be PARM messages in the log whenever parameters are updated so perhaps that could be used to determine when the pilot initiated the motor failure? Beyond that you could modify the logging (see Log.cpp) or add a new log message to make it easier to graph when the failure is happening. We have a wiki page here which describes how to add a new log message… perhaps write to the log from the one_hz_loop().
Hello again, we need further information.
How this type of “failure introduction” works? I mean, the signal that represent the power loss in which part of the system is introduced? Before the controller (Pixhawk) or just after the controller and before the PWM? Where can we find that kind of information? If it is already explained in the code, sorry but we have not been able to find it 
I really say thank you for every advide that you can provide to us. Best regards.
The changes to the code (provided by @khancyr) are mostly in ArduPilot’s motors library. So after the attitude controllers, just before the pwm outputs are sent to the ESCs.
