Copter 4.0 did great (thou scary) with hexa failed motor

I think this maybe good feedback for enhancements due to its unique circumstance. S550 hex with a Pix1 and AC4.0 (latest beta). standard flight over a customer location, about 500m out and 200ft up…motor 4 doesnt actually totally fail, but enters an on/off cycle condition, thus when i entered RTL, it would trick RTL with the motor coming on and off ever 5 second or so…when the motor was out it would perform the standard yaw rotation while heading home, however when the motor would quick in, RTL would switch to normal flying mode (as if it had 6 working motors) only for the motor to fail again and RTL have to enter another yaw rotation.
anyways it did end up making it home and even landing, but at a significant power cost where it almost consumed the entire 10k mah battery and very slowly struggled to get home.
I tried taking over manual stabilize mode and honestly I did far worse than RTL was doing, so I let it do its thing.
Maybe there is a feature enhancement opportunity here that when AC is in RTL (or any auto mode?) to assume a motor is dead, if a high PWM output doesnt produce expected thrust after X number of tries? I realize this would be much easier with an RPM sensor or ESC telemetry…if thats the case so be it…
I am not able to upload the log since i am not at liberty of disclosing customer locations, privacy, etc ,etc, etc. (Ill see if I can start working on a utility that scrubs the location info from the logs, thou am not sure if it will have significant side effects to the rest of the data structure)

4 Likes

@imrj,

Thanks very much for the feedback on the motor failure handling in Copter-4.0.0. I wonder if the cycling you were seeing was perhaps caused by the motor failure heuristics (i.e the algorithm that it uses to decide if the motor is failed or not). It’s possible that it was thinking it was failed, then thinking it had recovered, thinking it had failed again, etc.

I’m very interested in seeing the log but I understand the need for privacy. The log could be anonymised by removing the ADSB, AHRS, CMD (for mission commands), CAM (camera), ORIG (shows where the origin was set), TERR (terrain), RALLY (rally points), GPS and POS messages.

As Randy suggested we have a motor thrust loss detection that does something similar to what you are suggesting. It may or may not have been triggered but the repeated cycling of the motor would cause it to detect thrust loss and then detect that it is back again.

I would be very interested in seeing why it took so long to get home even with the motor cutting in and out.

Thanks for the feedback and I hope we can see the log.

@rmackay9 do we provide a “log anonymizer” script? I guess we should.

1 Like

Mission Planner Ctrl-F Anon Log button?

4 Likes

@Anthony_Short, thanks for that. This is additional proof that you can use MP for nearly 10 years and still not be aware of all it’s functions!

EDIT: some of the messages I’ve listed above (like ORIG) are relatively new, I wonder if MP will anonymise these as well.

2 Likes

You can anonymise logs via plot.dron.ee too (original log is modified in-browser and not uploaded, to be clear).

2 Likes

@aannurag, re the motors stopping, the most likely cause is a hardware issue (with the motor or ESC) or perhaps the ESC calibration hasn’t been done to ensure the range that the ESCs expect matches the pwm outout being sent by the autopilot.

In this log it looks like a failure of motor 6 (back left). It’s got all the classic symptoms of this which is the failed motor going high and the opposite motor going low. We also see the vehicle pitch back and roll left (towards the failed motor).

I think it would be good to use the motor test feature to ensure that motors are all starting/stopping together. There’s also some info on motor ranges here on the wiki.

From looking at the parameters it seems like MOT_PWM_MIN has been set but not MOT_PWM_MAX. For either to take effect both must be set. I’ve raised an enhancement request to add a pre-arm check.

@aannurag,

If the range is specified as 1100 to 1940 then I think it might be good to try setting:

  • MOT_PWM_MIN = 1100
  • MOT_PWM_MAX = 1940

It’s possible that the MOT_PWM_MIN will need to be lower in order to make the motors stop but it’s a good start. I recommend then going through the Setting Motor Range wiki page to get the MOT_SPIN_ARM and MOT_SPIN_MIN parameter values set correctly.

The PWM range definatly needs to be set to

  • MOT_PWM_MIN = 1100
  • MOT_PWM_MAX = 1940
    as Randy has said. However none of this explains why the motors would stop after 20 minutes.
1 Like

Exactly. Need more details on load on motors, battery details, a good integrated power module.

1 Like

hey guys is me the OP again…just wanted to say this happened AGAIN on motor 6 now and based on what am reading on this thread to my surprise am not alone…this hexa had been performing flawlessly for me until i get to AC4…so something is definitely off base here…and like others stated, it seems to fail like a few min into the flight…I got lucky again this time but am not chancing it anymore…I have sunnysky motors and hobbywing ESC which are notoriously reliable…
this occurrence happned 2 days after my first post, but ive been travelling overseas so not back home yet

@imrj,

Any chance you can provide a log file? It’s a real challenge to investigate issues with a log. There’s just too much room for misinterpretations and misdiagnosis of an issue without one. I’m not saying we don’t have a problem, just that it’s difficult to investigate without a log…

1 Like

Hey @aannurag
Is it possible to add power module to monitor your power consumption? Looks like your aircraft is flying fine till your lipo has enough juice. Can you give me more info on max wattage from the engine?
Also AUW.

I have tested the power system in a thrust test rig. In the test, the hex-copter was easily able to sustain for more than one hour at 80% throttle after which the battery voltage reduced to 42V.

Moreover after each crash I have checked battery voltage to be > 48V, which clearly points that this is not a power issue.

Thanks for the feedback. I’ve created a to-do item here to investigate reducing how often this message appears.

Hey @rmackay9
I think this has to do something with respect to motor thrust expo. @aannurag 's thrust at hover is at 31% whereas the PWM is averaging at 1500-1600 & more. I wonder those T-motor alpha ESCs are doing correction for thrust linearity!?
What do you think?
I agree it also has motor failure symptoms. :grin: