Uncommanded motor start when disarmed after installing Yaapu

ArduPlane Plane 4.5
1

I wonder if I can ask for some help understanding the logs I’ve managed to get about this incident.

Running ArduPlane 4.5.7

A quadplane vehicle was on the test bench for final configuration checks. All 4 engines had been tested and worked correctly multiple times over the previous days, as well as a brief run this morning and everything looked good.

I have a dual battery setup and wanted to get the telemetry for the flight battery as well as the RxBat, so this morning installed Yaapu onto my EdgeTX v2.11 TX16S Mk2

Yaapu correctly saw the extended CRSF telemetry and reported the correct voltages for both batteries as well as the ARM sensor etc, but it refused to add any of the extended sensors into the EdgeTX telemetry page (which was the reason I wanted it).

After trying a variety different ELRS settings without success, I reverted to my original ELRS config, checked the motors and servos worked as expected, checked the vehicle was in manual mode, and disarmed the vehicle.

The TX was left on, with telemetry connected and the plane with a USB-C to QGC. Whilst reading a post here, one of the motors fired up to what sounded like 100%, I immediately grabbed my TX and hit the throttle cut switch and nothing happened, so pulled the flight pack from the ESC.

As it was unarmed I got no logs, so I went through every setting on the radio and in QGC to see what might have happened. After about an hour of checking & research, I gingerly plugged in the flight pack again, the ESC started fine, the servos were fine, I armed it and moved the throttle a tiny amount.

(I suspect the same) One of the 4 motors immediately went into 100%, the throttle cut switch did nothing again, so dumped the TX to pull the flight pack again, this time I was too late, the engine had shredded itself, and spun the entire EDF blade set through the engine nacelle, fortunately no where near me!

To be clear though, the only settings I’d changed this morning were on my TX for Yaapu, and set the BATT/2_ARM_VOLT param to 0 to avoid battery fail safes. Except those two, no arming, safety or ESC params were changed in any way. All the other Ardupilot params were unchanged from a few days previously.

When the motor auto-started the first time, the TX had been sitting on my desk untouched for about 5 mins.

However, this time, because it was armed I have a log file that I’d appreciate some help/advice in analysing. These are the relevant start, max and last throttle inputs I can find:

1970-01-01 02:13:16.61: AETR {TimeUS : 4396615479, Ail : 115.0, Elev : 196.0, Thr : 1.0, Rudd : 0.0, Flap : 0.0, Steer : 0.0, SS : 1.6699999570846558}
1970-01-01 02:13:17.21: AETR {TimeUS : 4397215427, Ail : 115.0, Elev : 196.0, Thr : 5.0, Rudd : 0.0, Flap : 0.0, Steer : 0.0, SS : 1.6699999570846558}
1970-01-01 02:13:17.33: AETR {TimeUS : 4397335428, Ail : 115.0, Elev : 196.0, Thr : 0.0, Rudd : 11.0, Flap : 0.0, Steer : 11.0, SS : 1.6699999570846558}
1970-01-01 02:13:19.33: AETR {TimeUS : 4399335220, Ail : 115.0, Elev : 196.0, Thr : 3.0, Rudd : 244.0, Flap : 0.0, Steer : 244.0, SS : 1.6699999570846558}
1970-01-01 02:13:19.37: AETR {TimeUS : 4399375140, Ail : 115.0, Elev : 196.0, Thr : 100.0, Rudd : 1534.0, Flap : 0.0, Steer : 1534.0, SS : 1.6699999570846558}
1970-01-01 02:13:21.45: AETR {TimeUS : 4401454960, Ail : 0.0, Elev : 0.0, Thr : 0.0, Rudd : 0.0, Flap : 0.0, Steer : 0.0, SS : 0.6741989254951477}

But I can’t find anything obvious why it went from Thr : 3.0 to Thr : 100.0 in .04 of a second!

Thoughts much appreciated

2

Yaapu has no ability to send commands from the radio. It only reads CRSF data.

Can you share the log file you have?

1 Like
3

Yes sorry, I didn’t mean to suggest it was the Yaapu script itself, but rather something around enabling a feature it required to process the CRSF Telemetry.

RC_OPTIONS for CRSF Passthrough had been enabled all day and very brief runs of throttle input tested with it on.

Also, although the log file implies the whole throttle input was at 100, I am fairly certain only one engine responded to that, as the vehicle spun violently off it’s bench mounts before I caught it.

Log files here: https://drive.google.com/drive/folders/1STGY8NhX-eWrQ-pydxmgspPBRd—cCh?usp=drive_link

Log7 is the incident, but the other logs were created during the previous hour or so and Log2 shows the Thr behaving normally. The only physical change across them was a flight pack swap due to the battery fail safe triggering.

4

The plane was armed in manual mode, with full throttle. Things will happen…

Then had an RC failsafe, so it started switching modes based on the configuration for RC failsafe. Circle mode then RTL.

The four motors were all went from full signal to min when the fail safe occurred.

image
image1025×521 22.3 KB

Have you done the motor tests in a q-mode? I’m confused by the the configuration you have set. I see the four quad motors, but I don’t see any output to a horizontal motor, or tilt servos, and tail sitter isn’t active. Can you tell me what kind of configuration this is? I’m wondering if the configuration is confusing the motor setup (Or I’m tired and shouldn’t be look at logs right now..)

1 Like
5

Hi Allister,

Thank you for taking the time to help look at this, it is really appreciated.

You are right, this is an unusual aerodynamic configuration. It is a quad tilt tandem wing with no control surfaces. Each wing is independently tiltable from -10° to +100°, where the tilt wing itself is the control surface. Initially configured with fwd wings as ailerons and flaperons and aft wings as elevators only.

I intended to keep the vehicle entirely in manual mode for initial tests until I had a better handle on the flight dynamics, and could see how well they matched the simulations. I’ve currently only done unpowered glide tests.

Ultimately this will get a lot more complex, but I am initially only testing powered horizontal flight, no VTOL/STOVL, with Q_PLANE enabled to allow vectored yaw.

Given what you said and looking at log7:

I have seen FS_SHORT_ACTIN is set to CIRCLE as you pointed out, which I have now disabled.

However, both batteries had BATT/2_FS.. set to None, THR_FS_VALUE was left at the default 950 with my TX min throttle at 990us and the RX was responding correctly. So I’m not sure I understand why a 100% throttle would be commanded when I set throttle to ~3%.

It’s also worth pointing out the motors didn’t go to min, I had to disconnect the flight pack from the ESC to stop them.

Although I still find it concerning, I guess I’ll have to put the uncommanded throttle event when disarmed down to some kind of weird logic I created.

6

Yes, the parameters and log files show that you have switched off almost all the relevant pre-flight checks. At the same time, the RCx_OPTION 153 channel is probably already at 2000 µs when you switch on and plug in the battery. According to the log file, the VTOL is therefore in armed status right from the start!

Rolf

1 Like
7

At the same time, the RCx_OPTION 153 channel is probably already at 2000 µs when you switch on and plug in the battery

Hi Rolf,

Well that’s the weird thing. The first time the TX was just sitting on the other end of the bench, with Yaapu telemetry reporting disarmed on my TX. Sadly no logfile for that one.

The second time I definitely armed it, and both the Rx & flight batteries were already plugged in. The throttle went to 100% when I commanded a tiny throttle input. I thought at first I’d managed to create some kind of odd throttle reversal, but I hadn’t changed anything from previously.

I have a Strobon beacon I’m going to wire up to the FC armed state, but I’ve also got a bright orange post-it note stuck to my FC to remind me to re-enable all the pre-flight checks :wink:

8

You might want to reconsider and re-enable all the pre-flight checks now. Might save you these unplanned motor events on the work bench.

9

The challenge is, from listening to your comments, it is something to do with a failsafe, after it was already armed. The batteries and RC were in good working order when the vehicle was armed, so I’m not sure I see it would make any difference.

My suspicion is that my enabling BATT2 also enabled a failsafe I wasn’t aware of, and that I spent so long with it on the bench, that either that BATT2 FS or me changing TX/RX packet rates for the Yaapu telemetry caused a radio FS, and the mode change that you pointed out. With telemetry not working correctly I never saw the alert and wouldn’t have realised the significance anyway.

I can’t help feeling this is a flaw in the setup process, especially when I assume a great many people spend many many hours with their vehicle on the bench testing & configuring it - and need it armed to work on it.

IMO having a flight mode failsafe occur in this environment is just dangerous, and even more so when I was specifically and always in manual mode. I have now disabled all FS I can find, as I think they might be the opposite of safe on the bench.

Thinking about this more, whilst obviously Ardupilot inexperience on my part, to my mind MANUAL mode meant just that. If I disable an autopilot, I don’t expect it to re-enable itself and then command a 100% throttle, especially if it has no GPS lock and no active ASI, I’m not sure how it thought it could RTL or CIRCLE in those circumstances!

I think it might be worth clarifying in the docs that MANUAL mode doesn’t mean you can’t get taken out of it automatically. A param to specifically request this might be nice.

10

You shouldn’t arm the vehicle on the bench unless you are doing motor testing and have a plan to disarm or safe the vehicle by other means after the testing is done.

1 Like
11

I was motor testing. As I mentioned, I set the throttle to around 3% then the FS/mode change commanded a 100% throttle, at which point I unplugged the flight pack from the ESC.

12

From a Q mode (q-stab or q-hover) use the motor test function in Mission Planner. That will tell you everything you need and let you have the fail safes on. Also, take the props off so if a motor does light up it keeps the excitement level to a minimum.

1 Like
13

I’m a MacOS/Linux guy so looks like I’m stuck with QGC sadly, and this is an EDF quadplane, so I’d need to rebalance the blade set of all 4 engines every time if I took them off, and I would need it armed to re-balance them :laughing:

I know QGC is pretty primative, but I’ll have a look and see if I can get any failsafe alerts, I haven’t seen any yet. The Yaapu widget is now happily giving me BATT failsafe alerts whilst QGC just stays silent.

14

There is a motor test in QGC. I haven’t used it, but it might be a safer option. There’s also v5 of QGC out for testing. QGroundControl v5.0 - Release Candidate

I’ve run MP on Ubuntu using wine. Works pretty well. Maybe not my daily driver but good in a pinch for specific functions like motor test.

2 Likes