Replies to This Discussion

Permalink Reply by Jake Stew on May 25, 2012 at 4:42pm

The 9X has a perfectly reasonable failsafe when it goes out of range.  It drops the throttle signal and freezes or drops the other channels.  This is the most logical behavior I can think of.

I still don't understand what people expect it to do.  As a basic TX/RX it does exactly what you would expect a basic system to do.

The bug, design flaw, or whatever you want to call it is entirely in the APM.  A large company would certainly initiate a product recall or at the very least mail a letter and email every customer that purchased the unit a warning notice.  There's a HUGE liability here.  Somebody WILL get hurt by this sooner or later.

The most similar thing I can think of is the Toyota brake issue.  That cost them many millions, but they didn't even consider any other option than recall. It's the same as if your cruise control fuse blew and the computer held you at 70mph while disconnecting the brakes.

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on May 25, 2012 at 5:16pm

Jake: I'm not going to bother responding anymore. You either don't understand open source and liability or are intentionally not listening to anything I've said. At any rate, I suggest you move on to another community that works the way you'd like it to. 

Permalink Reply by Richard on May 25, 2012 at 11:33am

Loss of throttle channel must trigger the failsafe routines.

It's as simple as that, nothing else is acceptable.
- If you've lost control of the throttle channel, you've lost control of the aircraft.

Ok, a fixed-wing could be deliberately crashed into the ground, but I can tell you for certain that a significant number of fly-aways and hard crashes will have actually been caused by this.

A similar bug in early Spektrum radios resulted in a full product recall.
- You'll find threads about that DSMX issue all over the Internet.

What the failsafe should actually do is a different matter, and obviously depends on the specifics of the aircraft. But it must trigger.

• ▶ Reply

Permalink Reply by Brad Smith on May 25, 2012 at 7:28am

their are other issues here too on a plane i would prefer the throttle go high in case i,m i,m flying over trees i could just circle till the ESC cut out, on my heli you could cut the throttle and i could auto rotate and land, on a quad ? i think these are valid issues but it all depends on what and where you fly so it might be best to make it selectable with the best option for your platform preselected ! this is one of the reasons the AMA doesn't want us to fly on their fields and nobody wants to crash on the pentagon or the google  campus. hehe

• ▶ Reply

Permalink Reply by Brad Smith on May 25, 2012 at 8:50am

i think this discussion will help with the safety issues ,but keep in mind there is no way Chris and the team can realize the bounds of of my stupidity and ignorance . what the old saying

"the more links you put in the chain the better the chance you'll find a weak one"

and this little board is amazing at what it can do if you have done your job at properly setting it up ! this is a work in progress !

• ▶ Reply

DeveloperPermalink Reply by Andreas M. Antonopoulos on May 25, 2012 at 8:54am

At the very least, let's hope we can document the CR*P out of this problem so that newbies (like me too) can avoid problems. 

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on May 25, 2012 at 11:25am

The I2C lockup issue (which actually caused a crash of my own helicopter) was over 6 months ago.  It was fixed.  Please move on.

It's unfortunate that this bug existed, but it did.  The software is written by volunteers.  If you can help find bugs, find some, fix them, and submit it to the developers.

Simply complaining about the possible existence of bugs in free software doesn't help anyone.

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on May 25, 2012 at 1:09pm

It was a bit cavalier, but it's also the honest feeling I had.  I read back through this thread after posting my first comment about it, and I was surprised to see people talking about that bug as if it was still active.  I couldn't figure out if that was being done out of honest ignorance of the issue, or if it was intentionally inflamatory.

Like I said, that particular bug cost me about $200.  It was also dangerous as my heli is capable of killing somebody, and I was stupid enough to fly it in my town-center.  I was too cheap to buy a membership in the local club, and too lazy to drive a couple miles out into farmland.  So I flew it in the football field at the local highschool.  Luckily it didn't wander too far before coming down, but it actually almost crash landed in the local police station parking lot.  Wouldn't that have been fun!

The bug was not my fault, but the risk to other people WAS.

I think part of the problem here is that people are expecting the system to be foolproof, because they are flying in dangerous locations.  20 years ago, people didn't fly at local parks and schools.   The models are all large things with loud engines, and there was also much better understanding that these things can be dangerous.

Radio systems have gotten MUCH better than they were in the past, but then people turn around and fly in populous places, and get upset if the *system* fails.

Anyway, all of this is not to ignore the fact that there is an issue here, and it's worth discussing.  But still nobody has come up with a foolproof plan.  I would strongly argue against this idea that loss of signal should result in a "kill" command in the APM.  That's a really foolish thing to do.

I think a safer approach would be to have incremental failsafes.  If the Thr channel is lost, then enter Alt Hold.  I'd say that should be true unless it also see the rudder go hard over, which could mean the user is attempting to disarm.  In that case, disarm.  But otherwise, Alt-Hold, and let the user fly it back using the pitch and roll and wait for the battery to die (or disarm), or they can change it to RTL themselves.

If  the radio sees loss of pitch or roll, then enter position hold, and let the user decide to keep flying, land it, or RTL.

Another thing that would be really helpful, is to signal the problem to Mission Planner with MAVlink messages.  I don't know if that's possible, but it should be.  It would be great to hear 'Warning, loss of throttle channel input!"

Anyway, the idea is to let the user make the decisions, not the APM.  The APM is not smart enough.

It would also be great to develop a Safety Best Practices Guide in the wiki.  I'd propose the use of programmable failsafe Rx with CPPM signal might be recommended.  I also STRONGLY recommend every craft have the ability to boot APM independent of the motors.  This solves SO many problems.  It allows testing without risk.  And it allows you to "bring up" the system in a safe way.  Most ESC's will not throttle up if they have a high signal when you plug them in.  So if something is wrong with the APM and it's sending signal when it shouldn't, you're still safe.  And it also ends this "blipping when booting" problem.  It just makes sense.

3D RoboticsPermalink Reply by Chris Anderson on May 25, 2012 at 11:51am

Kevin: Your "Wiki Ninja" badge means that you have full wiki edit access. If there is something in the documentation that needs to be updated/corrected or reconciled, please do it! This is a community site and both the software and the documentation is created by the community. Our response to requests for improvements that are not already being handled by the dev team is always the same: here are the keys, please DIY!

And as Robert has pointed out, I2C lockouts were solved long ago. Not an issue anymore.

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on May 25, 2012 at 12:49pm

Kevin, about the only details I can remember is that the I2C bug was really only found because of a particular "signature" in the log files, which was that sometimes if the compass made contact again, the code would restart if nothing happened.  This made it appear as if the copter "teleported" when viewing the GPS logging.  This is how we knew it was a real "freeze" bug in the code, and not just some signal lockout.  In my case, the copter came in and out of freeze, it just felt like I'd lost control, but the GPS log showed it sort of "blinking" from place to place.

Still, the cause was unknown.  I can't remember who figured it out, but fairly quickly, somebody else found a non-blocking I2C library, and plugged it into the code.  Then the testing was a simple matter of disconnected the Mag while the board was running, because previously this was a 100% failure mode.

But again, as to the reference to QA, you're aware this is an open-source project, right?

Though, things have gotten better in the past few months.  Most changes are now vetted amongst the devs.  At some point we freeze the code, and Marco Robustini coordinates testing.  That's the QA.

But again, this is an open source project.  It's not perfect.  We have some brilliant people working on it, but they can't see everything.  If you want "perfection" you can spend $7000 on a DJI system, and then suffer from their bugs instead.  The extra money really only guarantees they will fight harder to blame the problems on you. ;)

DeveloperPermalink Reply by R_Lefebvre on May 25, 2012 at 9:53am

Guys, just to bring a little perspective here, since I think some of you are new to the hobby.  I've been doing this for 20 years.

Loss of signal has ALWAYS been a problem for R/C models. Back in the 72MHz days, the Rx didn't even know the signal was gone.  Depending on the weather on any given day, it could result in the Rx outputting something non-deterministic, or in most cases, all the servos would freeze in their last position.  In almost all-cases, this resulted in the model running away with throttle applied.  This was a common occurrence, and it's why responsible modellers did a range check every day.

Now, with the advent of 2.4GHz and digital Rx, we had the opportunity for the Rx to actually recognize a signal loss, and attempt to do something useful.  

But what should we do?  What is the one thing that every model should do on signal loss?

It's undefined.  Every model is different.  You could drop the throttle signal low to shut off the power.  But in the case of a gas powered model, which direction is "off"?  The throttle servo could be reversed due to mechanical setup.

In the case of the throttle channel, or really any channel, is the better choice to force a crash?  In my mind, forcing a crash increases the odds of injury for the simple reason that in my experience, a good number of signal loss scenarios can actually be corrected if you have a little time.  And staying in the air buys you that time.  Forcing a crash increases the odds of hitting somebody, because simply stated, it increases the odds of a crash.

This is a really philosophical question.

I think this is why the Turnigy Rx does what it does.  Dropping the signal output will result in result in most servos staying in their last position, and that includes gas engine throttle servos.  In the case of ESC's, I'd expect they would stop the motor.  It's just one of many options, and it's the one they chose.  Some Rx will hold all channels at their last known position.  It may be better in some cases, but not others.

The best option is obviously a fully programmable Rx, so the user can program it to do what they want.

In the case of the APM, all the same questions apply.  Is it better to force a crash?  Or is it better to buy time and hope the signal comes back?  Or is it better to Loiter until the batteries die (maybe loitering over that daycare facility)  (And BTW, many old-school RCer's would ask you WTF you're doing flying anywhere near a daycare facility or school).  Or should it RTL, maybe where people are standing?  What if there is a tree, house or daycare facility between it's current location and the LZ?  

The system is currently not smart enough to make decisions.  And in the lack of the intelligent decision making, sometimes "do nothing" is the best answer.

• ▶ Reply

Permalink Reply by Brad Smith on May 25, 2012 at 11:22am

well said , my vote would be climb to safe altitude(user selected)and RTL then loiter for a specified time (user selected) then auto land or even if your flying auto with waypoints you could have it follow the waypoints back to home and auto land (user selected) we can do all of this ourselves but it wont help the next guy unless he happens upon this discussion which should probably be deleted upon a solution to prevent having another round of misinformation 

• ▶ Reply

• ‹ Previous
• 1
• …
• 5
• 6
• 7
• 8
• 9
• …
• 12
• Next ›
• Page