After nearly two years of putting around with no nasty surprises my heavy Hex, "The Witch" has been behaving badly and yesterday gave me a fright.
A couple of weeks ago I moved up to 3.1 from 3.0.1 and in test flights noticed that there seems to be some sort of coupling going on between yaw commands and pitch/roll, because whenever the ship is in Loiter mode and holding position and even a gentle smallish (20-30 degree) Yaw input is commanded there is significant lateral movement. I posted a question about this on the new Arducopter forum and have gotten zero support there, so yesterday I decided to make a video of the behavior and to post it here. There's still no video because of the below event, but I would sure appreciate some help with that.
So, as I was preparing to launch yesterday with the intention of making that video, here's what happened (clip is in HD on Youtube).
I was peering down at the indicator lights while arming to make sure I had solid blue (I now hate even more not being able to see those lights at a safe distance). That was a nasty scare (see Oliver jump!) when the Witch abruptly spooled up under my face, with no input from me and zero control. Neither the spool-up nor the shutdown was commanded by my Tx. Flight Mode was Stabilize.
As is seen from the log (attached, and a screen shot at end of video) the Hex thought it was landing. The only failsafe set to "Land" was GPS loss. One other failsafe was enabled, Throttle (to RTL). Geofence was also enabled with 100 meter distances and RTL action."Check on Arming" was disabled.
Location of incident was our AMA field, very GPS friendly with no history at all of glitches, multipathing, etc., as it's far from buildings etc.
Firmware was 3.0.1, I had dialed back to that from 3.1 a couple of days ago while hunting for the source of the Yaw problem (it made no difference). APM 2.6 with Ublox GPS and compass both on stalks, excellent vibration numbers, never crashed, no question of inadequate power.
Log file attached.
I'm hearing that this may not be the only incident of its kind recently. I'm pretty unhappy about it, and until I at least find out the cause I consider flying this ship, in which I have a lot of time and money invested, rather risky. I'm hoping for practical advice here to prevent a recurrence. Meanwhile I'm bumping the firmware back up to 3.1 and disabling all the failsafes and Geofence.
Thanks for looking!
Replies are closed for this discussion.
Exactly what are you saying, sir?? I waited until well after the official release of 3.1 and went over all release notes as far as I know. For that matter, what release note would EVER mention such an extreme event as a possibility?. The incident occurred with 3.0.1 on board, which had been working just fine for a long time. And I'm an experienced pilot, computer and flight system savvy, and am also working in close contact with a fellow hobbyist who is a professional engineer and who wrote many of the Wikis here. Also as anyone can see from my posting history here I'm obsessively safety conscious. So you are perhaps critical of the software itself, is that your problem? In that case please be specific about how that applies to my questions or if it's just general opining kindly post that somewhere other than here, where I asked for help with two specific problems. Or maybe you didn't bother actually reading my post and viewing the video, and you think that what happened was just the normal new light motor-turning upon arming - it wasn't that at all, as is obvious.
For those too lazy or computer-challenged to view the video of this incident, the text in my earlier post apparently does not make it clear enough, in spite of identifying the firmware version, that this incident is not the now normal light motor-turning-on-arming feature (which I have disabled via my Tx sub-trim in any event - a horrible feature, IMHO),
Why have you disabled the feature using subtrim?
just use the MOT_SPIN_ARMED parameter as explained in the 3.1 released thread.
Are you sure using subtrim in an odd way hasnt triggered rtl or something? as the last part of that is to land.
sounds like stuart might be on to something. once RTL is above the launch spot, it switches to land. so it may have gone RTL because of your subtrim, and immediately determined that it was above the launch spot, and went directly to land.
that parameter needs to be edited, not trimmed out.
@Stuart and Ted
Hi and thanks so much for the on-topic helpful replies. Hmm, that would indeed seem to be a possibility. The sub trim was not added originally to keep that spin-up from happening, it was done a while ago and had to do as I recall with the values the JR12X Tx was putting out when I originally set up a throttle failsafe. When I went to 3.1 I was surprised when the props didn't do the little spinup dance and realized that it was due to that trim setting. Since that spinup-on-arming thing is not something I like (as a longtime R/C pilot it's disconcerting because on every other aircraft it would signal trouble) I just left it that way. Maybe for some reason the trigger value and the Tx min. output value got too close to one another, as it were, and caused this, though it didn't happen on any previous occasions. Anyway, I should be able to replicate the effect (with props pulled). I dearly hope that was it, as it's an easy fix. I'll report back with the results. Thanks again!
I got to know how to turned them off from you. Thanks!
Do you know why would my Tricopter flip left (180 degrees) after 1-2" of the ground? (Stabilized Mode).
It keeps flipping, not sure why. Any lead? Thanks
In response to Andke, Oliver is meticulous in following instructions, loading firmware and executing tuning and calibration procedures and he is safety conscious to a fault. He also flies 450 sized helicopters.
Prior to 3.1 you actually needed to stand in proximity of your copter to be able to establish GPS lock among other things.
Even with 3.1 unless you have your failsafes set up to not allow takeoff without GPS lock it is still very difficult to know the APM's status without observing it directly.
Unless you have telemetry of course, but only a small percentage of our flyers have and use telemetry so it is not a normal or reasonable presumption of it's presence and Oliver does not have it.
I do think that your responses have exposed an Achilles heel for our failsafe system and I think that the appraisal that tuning out the motor spin feature with sub trim is not the proper way to do so was correct.
There are arguments on both sides regarding the value of motor spin on armed and the fact is that different copters idle spin is drastically different from copter to copter (really slow to non-existent on some and entirely too fast on others).
From looking at Olivers logs it can be readily gathered that for whatever reason a failsafe was generated and that his preset "Land" failsafe was executed and that already being on the ground it displayed some bizzare behavior attempting to do so.
If you look closely at the copter trying to spin up you will notice on his hex 3 motors spinning up (every other one) and the others not.
Clearly it was attempting a yaw (presumably to align it's land direction) and it actually seems to have used the internal on the ground turn off the motors feature (which is part of the Land mode) to turn off the motors completely. (This is done by determining that the copter has not moved more than 20 centimeters vertically in (I believe) 2 seconds.
So in the end the I have landed autoturn off saved the day.
It would probably be better if we also had a (I have not taken off yet) flag as well that was cleared immediately after take off.
That would probably solve this sort of problem.
Might I suggest adding external blue and red LEDs as described somewhere in the Wiki? I had the same difficulties of having to poke my nose in too close to see GPS and arming status. Very uncomfortable feeling. Ordered some extremely bright blue and red LEDs from SuperbrightLEDs.com and now I can see those things in sunlight from 50 feet away. Between the LEDs and resistors it cost less than $1 each. You can use just plain Radio Shack LEDs, but I wanted something very bright (and didn't exceed the APM's current limits).
I agree wholeheartedly with your observations, I've often given the exact same advice to others (except I still don't like the spinning props being used as an indicator, just gimme a nice bright LED) and am slightly embarrassed by having been ambushed like that. I will mention though that this particular hex is seriously overweight and even at full throttle its a bus not a sport car and takes a bit of time to get moving, so I'm not so uncomfortable around it.
Thanks for the kind words Gary and for the further analysis, with which I concur albeit without hard evidence of the exact sequence that triggered the RTL and/or LAND prior to liftoff. I tried to reproduce the problem on the bench but had no luck. But I do suspect, as was hypothesized here earlier by Stuart and Ted, that my throttle subtrim might have been an issue. The low throttle reading (via the Radio Calibration page) was 985 and throttle failsafe was set to activate at 975, perhaps rather too close, yes? I've done away with that now and reloaded 3.1. Test flight was normal except the yaw - pitch/roll coupling effect is still present.
Thanks, I concur completely, The only reason I allow myself to get close to this particular hex is that it's so overweight that it's a total slug and I'm confident of being able to get out of its way.
I run a strip of red and a strip of green ultrabright LEDs on the rear of the left and right arms for manual flight orientation - that works really well in full daylight. What would be nifty would be a little relay that would turn them on, one set for armed, the other for the sat. acquisitions.