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.
Thanks, Tom, good idea, I looked at that way back when but forgot about it.
This would be easy to do using the CopterLEDs function. That's exactly why it was created, because the LEDs are even harder to see when the APM is buried in a copter frame. If the LED strips draw too much current for the APM outputs, just use your favourite current switching method, triggered from the CopterLEDS. A ULN2803, or FET's, whatever.
I agree with those who posted about LEDs. I use VERY bright LEDs purchased from ebay. They are using the LED feature as R.L. suggests. One Red and one Blue. They are like head lights they are so bright and easily light up areas on my home walls over 7' away at night. You don't want to look directly into them. They are great at the angle on my quad and perfect for indicating status from a good distance.
I like the motor spin - Very Much! I am able to give a verbal to others around what my actions are. The buzzer sounds to alert that actions are beginning. The motors spin Very Slow with the exterior indicator LEDs are on. EVERYONE now knows not to just wander through. This works even for the Deaf just not the ....
Folks, if you have a transmitter that supports a "Throttle Hold" switch consider using that in conjunction with this slow-spin feature, if you simply must have that silliness happening. "Throttle Hold" does just what it says, it holds the throttle at a preset value. I've used it routinely for years on most everything I fly, set to zero. What that does is prevents a surprise spin-up if the transmitter throttle stick is inadvertently bumped, which happens all too easily unless you clamp your thumb around the stick while carrying the radio or while it's hanging from your neck. In fact, the only injury (eleven stitches worth) we've had at our local AMA field in years was from exactly that. Airplane in one hand, radio in the other, bump/whack/slash. Anyway, flipping a switch into Throttle Hold and then back out as the last thing before takeoff is a great safety habit to get into and if you set the hold value correctly it will still allow that slowmo prop show.
Maybe a modern reality is that moving forward the systems should only fly with telemetry and an electronic checklist that does not allow take off until it has been carried out. Don't mean to start a war with this post, I can just see it being the way things go.
I actually set up my custom Tx that way, with a dedicated Thr Hold switch, with a red LED indicator on the switch. You could arm it, but it won't do anything until you raise the Thr Hold switch. More importantly, you CANNOT arm it if the ThrHold switch is up.
It works perfectly, and is a great two-step safety.
It also prevents the dreaded mid-air shutdown of the motors by accidentally dropping the throttle too low, as when the switch is up, it locks-out the very bottom of the throttle range. The result is an extremely obvious on/off switch for the motors, with no in-between or unclear states. The motors are running, or not.
That being said, I still thing Mot Spin Armed is a good idea, and your insulting comments about it, and many other things, is probably why nobody jumped to help you here.
@ Gary Mortimer
I'm all for a preflight automated checklist, elements of which are already present in many systems, but can that be really effective without a stable, unchanging hardware/firmware/software combination? It might be a lot to ask to keep such a checklist up to date in the very dynamic experimental environment hereabouts. Also it seems to me that sometimes bad combinations of things happen that aren't foreseen and that a checklist will therefore miss. But some universal checks, like battery voltages etc. would be nice. For example a very common mistake in R/C is taking off with nearly exhausted batteries.
A problem with both automated checklists and telemetry is that neither can compensate completely for plain old carelessness. How many accidents are caused by things like loose props or electrical connections, flying beyond one's skill level, flying into obstacles and so on? We know from long analysis that the vast majority of fullsize light aircraft crashes are due to pilot error, and those happen in spite of facefulls of big fat instruments and awesomely reliable hardware. I don't think it's a whole lot different here.
Sigh. Once again a worthwhile thread is polluted and ruined by this guy slinging nasty personal insults for no reason whatsoever. I said nothing "insulting" about spin-up, insulting a parameter would be like insulting a rock. I am closing this thread and I will close every future thread I start which this guy uses to launch personal attacks on me or anyone else. For the record, Loofa's animosity towards me is due to his incomprehension and frustration at having been flummoxed in an earlier philosophical discussion. Rather than retreating he resorted to a personal attack then, and now he apparently wants to escalate that into bullying and more of the same.