search

ArduPilot / ardupilot

ArduPlane, ArduCopter, ArduRover, ArduSub source
http://ardupilot.org/
GNU General Public License v3.0
10.91k stars 17.41k forks source link

Full throttle on power up (quadplane, octoplane) #9741

Closed jonathan84clark closed 2 years ago

jonathan84clark commented 5 years ago

Bug report

Issue details Sometimes when you power on a quadplane or octoplane all motors turn on to full power. The issue cannot be reproduced reliably. The motors slow down after a second or so when the flight controller finishes booting up. I believe the best approach to reproducing this is to power cycle a quadplane or octoplane (with the props removed!) over and over again. If that does not reproduce the issue then having the aircraft takeoff and fly then power cycling a few times might do it.

Version ArduPlane master as of 10/31/2018

Platform [ ] All [ ] AntennaTracker [ ] Copter [ X ] Plane [ ] Rover [ ] Submarine

Airframe type Both a quadplane and octoplane

Hardware type Pixhawk 2.1

Logs System logging has not even initialized when this defect occurs

WickedShell commented 5 years ago

@jonathan84clark ChibiOS or PX4 builds? And do you have a log/set of the parameters?

jonathan84clark commented 5 years ago

Never tested with ChibiOS. PX4 does not reproduce the behavior. It also does not reproduce in any other frame type (just quadplane and octoplane). The engineers here have seen the problem multiple times but didn't know which log files it was in. I went through 10 log files and couldn't see any indication that the RC output was high (that's why I think it happened before the Pixhawk 2.1 booted up). I do have a parameters QuadParams.zip

file though.

WickedShell commented 5 years ago

@jonathan84clark There are only 2 ArduPilot firmwares that can run on a Pixhawk 2.1, ChibiOS based, or PX4Firmware based (this is the px4-v3 target if you were compiling it yourself). You would have been running with one of the two.

jonathan84clark commented 5 years ago

Oh, Im sorry I am still new to this. Yes I used ./waf configure px4-v3 then ./waf plane to do my build.

peterbarker commented 5 years ago

On Fri, 9 Nov 2018, Jonathan L Clark wrote:

Oh, Im sorry I am still new to this. Yes I used ./waf configure px4-v3 then ./waf plane to do my build.

Was it a reboot or cold-power-on?

Can you supply a specific git hash?

Did you ever put a ChibiOS based build on the machine and then go back to px4-v3?

jonathan84clark commented 5 years ago

Yes, typically it occurs on a cold-power-on. And does occur fairly regularly although I haven't actually researched how frequently.

We have been able to reproduce it with ArduPlane 3.9.2. I have not performed a regression test; I'm not sure how far back it goes.

The ONLY builds we have put on the Pixhawk 2.1 are ArduPlane 3.9.2 and builds I created from my own branch (px4-v3 is the config). My the only difference between my own build and ArduPlane master is that I have added precision landing into quadplane. However this issue was present before I even touched the code.

peterbarker commented 5 years ago

Did you update the bootloader on the board at all? I'm not suggesting you do at this point - just gathering information.

What sort of ESCs are involved here?

Do you happen to have a logic analyser (e.g. Saleae) with which you could take a trace?

jonathan84clark commented 5 years ago

No, I did not update the bootloader. The UAV engineer has indicated that they are Castle ESCs. I do have a logic analyser, however I have had some difficulty reproducing this issue myself. I just did 50 power cycles, nothing. I tried a few other things as well.

The first time I saw the issue myself the drone (which is a quadplane) was facing away from me with all 5 props installed. The drone was right in front of me when it happened. It immediately lifted off the table. I ducked and escaped with only minor cuts and damage to my shirt. But that incident has raised serious safety concerns. If we deploy drones like this on a large scale it will be extremely dangerous for technicians to work on them. My co-workers have reported seeing the issue in the field several times on multiple prototypes.

peterbarker commented 5 years ago

@jonathan84clark When you were using the logic analyser - were you using servo-y-leads or equivalent to keep the ESCs in the loop?

jonathan84clark commented 5 years ago

I'm sorry there must be a miscommunication. I have not used a logic analyser yet. The main reason why is because I cannot reproduce the issue manually. It reproduces at random. There is no way to catch it in the act. The only time it has reproduced so far is with props in the field and on the workbench a couple times.

auturgy commented 5 years ago

This sounds similar to an issue resolved here: https://github.com/ArduPilot/ardupilot/pull/9353 however there are enough differences that it seems unlikely that they are related. Can you provide a firmware or push your branch?

jonathan84clark commented 5 years ago

As I started previously; the engineers at my company reproduced this defect with the ArduPlane 3.9.2 build. That build can be found in the releases section of the ArduPilot Github repo. If you would like to inspect the changes I made. My fork of Ardupilot is https://github.com/jonathan84clark/ardupilot I am working on the irLock_10_31_2018 branch. That branch has also reproduced the issue. As well as a pull from the latest version of master on 10/31/2018

auturgy commented 5 years ago

Yeah - got all that, just wanted to double check that we weren't trying to re-attack a solved issue, and without a log it's a bit tough to look into something. I'd suggest testing with Q_M_SAFE_DISARM to 1, to disable PWM to the vtol motors whilst disarmed. @tridge

tridge commented 5 years ago

@jonathan84clark can you please give the exact parameters you had loaded at the time this issue happened.

@auturgy we already have several options for controlling output to motors while disarmed. I don't want to add another one without understanding what is going on here.

jonathan84clark commented 5 years ago

Thanks for the help. @tridge Yes. Here they are.

I will have the guys make the parameter change to the code on all our prototypes and see if that resolves the issue.

Yeah, this is a difficult issue to reproduce. It seems to only reproduce when it is the least convenient for everyone. I am planning to do some more work with the UAV engineer and project manager today to try and figure out a reliable way to reproduce it.

fisherParams.zip

WickedShell commented 5 years ago

Regarding this class of issue. I know of a specific scenario which only occurs under PX4 based builds. When programming the IO processor mixer PX4 sends out a low/minimum pulse. However the moment we complete the programming and go back to a no pulse mode PX4 will cut the pulse no matter where it was. If you were sending PWM output pulses, and it gets cut very short it can be interpreted by the ESC as a high throttle signal under oneshot. I've seen this spin props up multiple times. (To the point where to boot safely on plane all props had to be removed). This specific problem does not occur under ChibiOS builds however due to how the timer is reloaded.

IamPete1 commented 2 years ago

@jonathan84clark Any updates? I don't think we have a report of this happening on a ChibiOS build?

jonathan84clark commented 2 years ago

I haven't looked at this in years. I have been out of the drone industry. I am fine with you closing it, although this is the kind of bug that could send someone to the emergency room to get a finger reattached. When the drone in front of me did this I had five 10 inch props coming at my face.

IamPete1 commented 2 years ago

@jonathan84clark I don't mean to minimise the issue, its certainty a very nasty one. However this report is no longer useful starting point for an investigation due to the change in HAL from px4 to ChibiOS.

If anyone has seen this on a recent release we would certainty be very keen to get more details and hopefully track down the problem.