Replies to This Discussion

Permalink Reply by Crispin on May 1, 2012 at 12:53am

@Andreas re: testing failsafe

I was looking at the code a while ago (2.5.0) at a way of manually triggering the fail safe and it looked rather simple. IIRC, there were two places which set a status to failsafe. It was a while back and I've been on other stuff since so memory fades. Would it be as easy as I was thinking to have a way to manually trigger the failsafe? perhaps through a channel 6 switch?

A friend of mine got it all setup as per the wiki, did a test and it RTLd but then crashed, breaking a motor and prop. He saw the test as a success because at least it crashed within walking distance. He had two previous fly-aways which lead in a couple of hours of searching for each.

I set mine up the same as him but don't really want to test it for obvious reasons. 

• ▶ Reply

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

Crispin: see Andrew Tridgell's geofence work, I could use testers on the ArduCopter port

http://diydrones.com/profiles/blogs/geo-fencing-for-arducopter-keep...

• ▶ Reply

Permalink Reply by Crispin on May 1, 2012 at 1:57am

Andreas , I saw that and think it's a cracking idea for what it is intended. Thing is, you need to set it up for each area you are going to fly in.

I can't (still skimming article though) see how that could enable a manual test of fail safe. Most of us set it up and hope it works when needed, much like the airbags in your car :| 

I'll certainly give the fence some testing when the weather improves, would June 2014 be ok? Cosidering swapping the quad for a boat at the moment...

• ▶ Reply

DeveloperPermalink Reply by Andreas M. Antonopoulos on May 1, 2012 at 2:29am

See the part that talks about auto-fence, no need to setup. It will just draw fence around your starting point. Also an altitude floor and ceiling. So you just get GPS lock, take off and arm the fence once you are at (above) the preset "floor". 

No need to setup the fence in advance.

That furious little drone that was simulated bouncing off the walls for 5 hrs (the mushroom flight trail)? I never set any fence coordinates, just took off and it set up an auto-fence.

• ▶ Reply

Permalink Reply by Crispin on May 1, 2012 at 2:32am

ahh, that is awesome then. Thanks. will try it.

• ▶ Reply

Permalink Reply by Vernon Barry on May 1, 2012 at 3:01am

My concern here is, if we have the code "do something" how does the untrained pilot react?

In other words, your flying, your not good at judging distance yet and you hit the limit (altitude or just distance). You think you lost control so you move the sticks to wrong positions and then it get's really bad. I'm just saying that there's more to this than just adding functions and failsafes. This is why RC guys have clubs, buddy boxes, training, and proper flight fields and rules. Because the human is in the loop, we have a whole lot of unpredictability, and further, we still have no collision avoidance and that's not something that comes cheap. The sensors alone are cost prohibitive (RADAR, LIDAR?). All I'm saying is that RTL is scary and just really dangerous if you didn't know what was happening, depending on where the aircaft was and the path, there could be obstacles in the way, and then how do we handle return of control? How does the user know they lost control? How do you train the user for the situation to not cause a crash after a failsafe occured?

Again, I don't think bounding is a bad thing, but the above questions show why it's experimental at best.

And sorry, it's just how I think about it but "predicting" a radio with invalid failsafes is a total crapshoot. It might work, but it also causes more "loss of control" events due to the pilot not knowing how to react and the "rules" for returning control after a failsafe event are going to be rather complex. The safer and proven method of ensuring the radio has proper failsafes is the best bet and minimally, should be the layered security approach always.

• ▶ Reply

ModeratorPermalink Reply by Gary Mortimer on May 1, 2012 at 3:44am

I will second that, I have had RTL based on power consumption for wings.

Once I was mucking about after completing a photo run, low passes etc. I had forgotten about the power based RTL.

When pre determined amount of power had been consumed the wing just headed off by itself to climb upto 100m and start its circle. It flew between two large trees on the way I wondered what on earth was happening. It all ended ok but I don't forget power consumed RTLs now.

Less is always more KISS

This has the potential of being a really interesting conversation.

• ▶ Reply

Permalink Reply by Jake Stew on May 1, 2012 at 9:39am

This isn't just for improperly set radios.  Any number of problems could cause the receiver to freeze.  Even a telemetry radio could freeze and cause a problem.

The idea is that the autopilot should know that some things are NEVER right to do.  When you start the flight you should pick some parameters, like a max range setting, based on what you're trying to do.  If anything causes the craft to violate these the autopilot should take corrective measures.

There's all sorts of ways to handle potential problems.  It would be easy to say set your max range at 1 mile.  For a quad on a training/testing mission if you go over 1 mile away you KNOW something is seriously wrong and should abort flying.  If you set the range reasonably you shouldn't ever have a problem.  Alternately, you could have it beep or otherwise warn you, then take control if you don't respond within X amount of time.

With a sophisticated autopilot there's just no reason for it to think that it's OK to just sail off and crash somewhere far away.  I'm not talking about geofencing your backyard, that could cause some problems.  But if you're in a proper flying location there should be a large zone between how far you want to fly and how far it is safe to fly.

A simple distance or fence safeguard would go a long way towards avoiding legal claims of recklessness.  Generally, if you take preventative measures that should have prevented endangering someone and they fail it's just an accident.  If you set up a system that you know full well could sail off and crash into something or someone due to any number of problems, that's reckless endangerment. 

• ▶ Reply

DeveloperPermalink Reply by Andreas M. Antonopoulos on May 1, 2012 at 4:37pm

It would be nice if we could add a voice annunciator. Disarming announces the settings (one last time) before takeoff:

Voice from copter:

"ARMING

MODE STABILIZE

RTL ON

FENCE ONE ZERO ZERO METERS

STAND CLEAR FOR LIVE MOTORS

ARMED"

• ▶ Reply

Permalink Reply by Vernon Barry on May 2, 2012 at 4:27am

Easy enough, Speakjet standalone text to speach conversion using the 2 chip combo. From a programming perspective, it's far better to not send serial or even parallel asci text out of the main loop in the mega 2560 code, but with some interfacing, either single line outputs or some simple digital status could be used and stored phrases in the speakjet.

http://www.sparkfun.com/products/9578

Again, we would want to make minimal changes to the mega code, just alow for a simple interface between a second board running speakjet, as to impact the main flying code loop the least, writing serial or parallel acsi data would slow the main loop to a crawl.

This breakout shield has a tiny amp and an area to mount the asci to speach conversion chip http://www.sparkfun.com/products/9811

http://www.sparkfun.com/products/10661

Bascially, it's a couple of more chips, but minimal programming even a novice could do would make this work. It's just going to be some basic serial writes out of a second Arduino(say a pro mini 328) the serial text to speach conversion chip, and then the speakjet chip + an amplifier and speaker.

Because speakjet is so versatile, this is really just a matter of following the examples with the main goal of not impacting our current flying code.

Permalink Reply by Vernon Barry on May 2, 2012 at 4:40am

Actually, I just came up with an even better idea. We take the current code for the OSD displays since it "reads" mavlink data, thus no changes to the existing arducopter code. We then modify it to send the relavent data to speakjet (very simple).

And this can be used at either end of the telemetry link ground side or heli side.

Further, and this is the best part of the mod. Instead of modifying the ardupilot code for all these desired safety features, we instead modify the new OSD/speakjet code with USER failsafes. We put a dog shock collar on the "Pilot" (AKA stupid user), and whenever a user induced error (hit the fencing limit, wide open throttle, etc..) speakjet announces the error and shocks the piss out of the Pilot.

How about that for some "Pilot training"!!!! Brings new meaning to "system armed".

Permalink Reply by Vernon Barry on May 2, 2012 at 7:52pm

Somebody beat me to it, the exact solution I described.

http://diydrones.com/photo/705844:Photo:109385

 

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page