Potential Thrust Loss - can you set it to RTL automatically?

Hi,

For Potential Thrust Loss warnings, is there a way to change the severity to a major fault and automatically take action on this warning e.g. hover in place or RTL?

We have been having issues with some wiring to the motors and losing power to a motor on our Hexacopter. This is a known issue and we are working on fixing some poor soldering work and we fix what we can but on motor loss we are still getting crashes so I’m hoping for some input as to what we can do in the event of a motor loss.

In this latest time, it has flown fine for a short period with motor loss but once it tries to turn around it fairly rapidly loses speed and altitude and crashes. The thrust loss warning is very easy to miss.

The configuration is a hexa X with 21kg MTOW with 7.1kg max thrust per motor.

This is the log:
https://singleagriculture-my.sharepoint.com/:u:/g/personal/bensingle_singleagriculture_com_au/EbwYyx4q-XpKpXgDt5DQZPgBKc_KhgLojsSw7FEtiOkMGw?e=h3eVld

Any help would be appreciated.

Just changing the mode to hover instead of RTL will not prevent a crash if one or two motors stop operating due to hardware issue. So I do not get the point of your request. Care to elaborate more?

1 Like

I thought of something in LUA scripting but I dont have a sample of detecting thrust loss for you.

Ideally you would fix the physical issues before flying again and you would never have the thrust loss messages again. If you use a transmitter and receiver that supports yaapu telemetry you’ll get warning sounds and a message whenever anything happens during flight. Otherwise set up a telemetry radio and groundstation - your observer can keep an eye on the MissionPlanner HUD.

If you do set up yaapu telemetry you will wonder how life was possible before - it’s definitely worth the cost and effort. You only need a second hand Taranis X9D, or a Radiomaster TX16S or similar. The new radios are not much dearer than a used one.

Thank you. I’ll have to look into those radios. LUA scripting was where I thought I would have to go and 100% fixing the physical issue is the goal. We’ve tried but still occasionally get the fault, then it is too easy to miss the Thrust loss notification and once it starts going down you have as little as 10 seconds to recognize the issue and rectify it. We use UGCS which gives you a notification every time it gets to a waypoint and the Thrust Loss messages get lost in those messages.

Thanks amilcarlucas.

Changing to hover does let you prevent the crash. It will still fly ok, if a bit rough with one motor not working. This instance for example, it flew for about a minute just fine with one motor not working and it didn’t have an issue until it tried to fly back into the wind and then it seems to have prioritized forward speed (in auto mode) rather than maintain height. When I have noticed the fault previously and then manually put it into hover, I was able to successfully land it as well as RTL worked fine.

The problem comes on picking up the issue in the first place. We do long flights of up to 50 minutes with UGCS as our GCS software which will also print out every time it gets to a waypoint which on these types of missions, so it’s not unusual to have 3 or 400 waypoints. The thrust loss warning on appears in the log text and it just gets lost in a mountain of text. Look away for 15 seconds and you’ll miss it. It’s very easy to miss the fault especially when you are trying to both keep your eye on the drone and the GCS. The flight log is basically hidden in the corner and with so many waypoint notifications it is ineffectual at communicating faults (this is a UGCS issue, not Ardupilot obviously, but they haven’t done anything about the issue when I have raised it with them).

The goal is to change the severity of Potential Thrust Loss to a mission critical error (which it is in our case) like low battery or loss of GPS which has both automatic responses from the drone and actual warnings show up in UGCS on the screen proper, not just in the log, with audible warnings.

So to summarize, Potential Thrust Loss warning is almost always a mission critical warning but it is not treated as such and I am trying to find out how to treat it appropriately even if I have to modify my drones. This is by far our biggest issue with our drones by probably an order of magnitude as any other fault (that is recoverable) is dealt with appropriately.

On a related topic, when a motor fails, it will make the demand for that motor go to 100% (which I understand as it is trying to get maximum thrust out of that motor if it is just underperforming or the actual demand on the drone is too much for example), however, in an actual motor failure event this is probably the worst thing to do when you have motor redundancy. 2 issues, 1) with 3 phase motors, if a power cable between the ESC and motor fails and you keep trying to run the motor at 100%, you just burn the motor out as it doesn’t function properly, but one set of coils is still working (this happened in this log). 2) if it is an intermittent fault and the motor suddenly starts working again i.e. because of a lost connection (have had this happen previously) then you will suddenly get one motor go to 100% thrust, when the drone was compensating for no thrust from that motor… which results in the drone flipping. A much better response would be to turn that motor off, and accept it isn’t working properly when you have redundancy with your motors (for the first motor anyway).

Hopefully, that explains a bit better what I’m looking for. Appreciate your time. Thank you.

I was going to recommend putting in a Pull Request, or submitting one myself, so I looked in the code and the thrust loss message is given the emergency status, so maybe it’s the way UGCS is handling this.

/ArduCopter/crash_check.cpp

   // send message to gcs
        gcs().send_text(MAV_SEVERITY_EMERGENCY, "Potential Thrust Loss (%d)", (int)motors->get_lost_motor() + 1);

In MissionPlanner this would be bold red text right across the middle of the HUD

Interesting. Good to know. I will have to contact UGCS to get them to fix that (not optimistic that they will).

Edit: Cleaning up responses:
What would be the best way to implement to change it to RTL or Loiter do you think? Found the below:

Looks like this has been discussed previously with the conclusion to put it into RTL and disable yaw (not sure I agree with this) and not sure if this was ever implemented.

Possible LUA script is below:
thrustloss_loiter.lua (1.7 KB)

OK, so you just need to set up that thrust loss script, set it to RTL instead of loiter.
There’s also LUA scripts for disabling a motor in-flight if you are game.

Ideally you would never need any of these - there must be some issue causing your thrust loss that needs to be found and fixed, rather than putting so many mitigations in place.

Have you got a photo of your power wiring and distribution?