First this IS NOT a bashing session this is a search for answers and opinions so try to be respectful and courteous !
me personally i think the APM is capable of bringing my plane back and landing if the rx fell out ! do i think DIY should be responsible to implement it ? no but they are flying too so if we come up with a good proposal i,m sure they would try to make it happen !
this discussion is intended to come up with scenarios where your platform would go out of control ! and what we can do ! there should be a sister post Mitigating the chances of losing control .
i,ll start out . with Geofencing(here after to be referred to as GF) turned on i can't see how your platform can fly away so maybe GF should be turned on from default with a tiny box that you have to adjust to your area,platform,and conditions ? but not all of us carry a laptop to the field so maybe we should be able to save it and recall a few different versions for different fields and or conditions that way you could program it at home and go fly , but if you turn it on to far away from the place you selected as home it should lock up and beep or flash an error that way it wont try to fly 40mls back to your house (00) a safe configurable selectable autoland function tied too GF would be nice too.
at least this would protect the DIY community from litigation and put responsibility on the user and would save a newbie from a painful costly learning experience !!! feel free to poke holes in my ideas !
Questions leads to answers and isn't it wonderful we need not wait another second to make the APM better and if we do a good enough job maybe the government will force the AMA to use our product on all there large dangerous aircraft ! and would help in the UAV community acceptance into the sport
now have at it
Replies
I first saw a "Berg Pin Header Strip" on the original IBM PC in 1981. They're cheap, lightweight, and easy to use (although non-polarized in most applications). They were, however, never intended for high vibration applications. No, I'm not picking on 3DR at all; unfortunately they've become a standard in the hobby industry with which any manufacturer would be obliged to comply.
Needless to say, you won't find any such connectors in my aircraft. From the APM connections to the LiPoly pack balance access harness, everything is soldered permanently where possible. The few connectors are high-grade locking types.
Considering that there are few machines with vibration signatures as high in magnitude or complexity as a multicopter, any serious practitioner in the art should solder wherever they can and incorporate higher-quality connectors where they must. This eliminates many of the potential "fails" from which the craft must be saved.
http://lmgtfy.com/?q=rc+ppm
I have updated the ArduPPM firmware for the APM2 (v2.2.67) so that it will detect a missing throttle signal and set the the throttle value to 900us. APM1 version will come later.
Binaries: http://code.google.com/p/ardupilot-mega/source/browse/#git%2FTools%...
How-To: http://code.google.com/p/ardupilot-mega/wiki/APM2Encoder
You can set it to whatever you feel is best, after all, you are responsible for what you are doing with it? you can even preconfigure a course of action to take in great detail if you wish, such as stop for so long then go somewhere then stop again then come back and spin around a few times, the possibilities are endless, but the buck stops with whoever is in command of the vehicle. So whereever you fly you, the pilot must decide what is best for the scenario..
Perhaps I am being stupid? forgive me I have only read the first couple of pages and the last page, but isn`t it fairly easy to set up a failsafe upon loss of signal? my Tricopter returns to launch and lands on loss of signal, but I can change it to do a few other things if I feel it would be better?
OK let's try dealing with a specific case related to failsafe performance, instead of all this high level abstraction going on.
ArduPPM (ppm encoder) failsafe and throttle channel:
First some back story. Reading PWM signals from up to 8 R/C receiver channels and maintain timing so that you have good stick resolution (>1000 steps), is very difficult with the atmega32u2 hardware. The PWM pulses from all the channels has to be intercepted and dealt with using a single shared interrupt, regardless of the channel signal pattern that may or may not have overlapping pulses. At the same time you also have to stay compatible with the USB<->Serial conversion code that Arduino use to reach the main atmega2560 chip from a USB connection (replacing the expensive FTDI chip used earlier).
So certain shortcuts had to be made in the design, to make it possible. One such shortcut is not dealing with the (physical) loss of single channels. Checking for such combination in a shared interrupt, takes to long and would affect stick resolution. So the loss of throttle channel (actual wire signal loss) not triggering failsafe has been a known weakness from the start.
Now for the dealing with a specific case part.
I think it would be possible to make a special case for the throttle, without having to degrade the stick resolution. But it would have to be a very specific set of behavior. I see two possible behaviors (that would be possible with the limitations set by timing requirements).
1. After a certain duration without a valid throttle signal, the 'all channels lost' failsafe option is triggered (throttle 900, channel 5 1555 (mode 4), the rest centered at 1500) . This failsafe would then stay active until a valid input is detected on the throttle again. The problem with this is that it would actively disable input from other channels if throttle dies.
2. After a certain duration without a valid throttle signal, throttle is set to 900. How this is dealt with is then up to the main logic in the APM code.
As I see it option 2. is the best solution. Any suggestions, comments before I implement this?
Kevin, I do not believe for a second that you are not capable of contributing.
6 months ago, the sum of my coding knowledge was a course I took in high school 20 years ago where I learned BASIC. That's it. Everything I've done here has been self-taught. I would welcome you looking at what I (or anyone) has done and if there are problems, tell us or fix it. But again, we're only doing this for fun, so the method of delivery is very important to getting listened to.
How did I get to be a Dev? I studied, and I studied, and I studied the code until I started to understand it. This also involved learning C++. I found a few issues, and submitted fixes. That's it. But whatever I submit is reviewed by people much more knowledgable. Very little goes in without being vetted by peers.
I railed against "the system" a bit at first, until I quickly learned that that wasn't getting me anywhere. Things work better from the inside. I started by fixing the wiki pages that could be fixed, and grew from there.
Interesting discussion. Still reading all the comments as we're looking into failsafe techniques for our unique flight conditions.
One common thing is present: if you lose supervisory control, hold position, verify and correct your heading (so [you] it knows what to do next). For planes it's tight circles, everything else, just stop and hold. All other startegies (GF, RTL, Land, Lift, etc..) are context sensitive (e.g. don't want to RTL in a middle of others flying around). Achieving that one mode: then there are many ways on how the APM can get your vehicle back safely.
Also by example: 9 out of 10 robots (from Willow Garage's to iRobot's) trigger an e-stop, or "motor-power-off" on a failsafe event, newer units are starting to hold position (i.e. vamp).
Last night I proved out the solution to the phsyical problem of the throttle wire losing contact.
I'm using an FrSky module in an older Futaba radio, and an FrSky DR8SP receiver feeding CPPM to the APM2. This means there is only a single wire going to the APM, not 4+. This means that if the single wire should lose contact, you lose *all* control. So, single point of failure. But then again, you only have to get 1 wire right. If the loss of any single signal could cause a loss of control, this solution is 4 to 8 times less likely to cause a loss of control.
But the real test was what happens when that wire is lost? So I unplugged it, and the radio channel display in MP shows that the throttle signal drops to 900, all others are centered, and so the APM enters failsafe which is RTL. IMO, this is the safest option.
Now, I did discover that when reconnecting the Rx to the APM, it caused the APM to reboot. I tracked this down to the apparent fact that there are some caps in the Rx which need to charge, and the inrush currently momentarily browns out the APM. This would be a problem if you had a flaky connection that was coming on and off. However, I solved this by simply plugging a 3300uF capacitor into the APM to help support the voltage level when the Rx is reattached.
So to summarize:
1. Cost is only ~$60? This also gets you telemetry, which is awesome. This allows you to see an impending radio link loss before it happens! AND you get a fully programmable failsafe so that you can program in whatever failsafe you want to have if the Tx signal is lost. Want to shut the motors down? No problem. Want to RTL? No problem. Want to Loiter/Circle? No problem.
http://www.hobbyking.com/hobbyking/store/__14354__FrSky_DF_2_4Ghz_C...
2. The CPPM signalling is easier, cleaner, and 8 times less likely to cause a partial loss of control.
3. The FrSky system is extremely fault tolerant. It has possibly the best RF noise rejection available, and the fastest reboot and re-link time you can buy. True diversity from dual antennas. And does not brown out until <2.8V
http://www.rcmodelreviews.com/frskyreview2.shtml
4. I think everybody should have a capacitor bank installed on the APM power rail as a safety precaution in any case. These cost a few bucks at most, and can prevent a momentary power glitch from causing a reboot.
http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=...
I use one of these on my big heli. It helps if a servo has a problem, and can actually keep the APM alive for well over 2 seconds if power is lost.
http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=...
IMO, "Failsafe" is not trying to make a system handle a fault in the least terrible way. Failsafe is making a system that won't have a problem in the first place. Reducing failure points is a huge part of that. Choosing the right equipment is also very important. And finally, flying in a safe location is the 3rd leg of the stool.
You are all now informed of the "best practices" for safety, and you have no excuse to try and blame 3DR or the APM Developers if you have a crash caused by using a crappy 9X radio system.
Again, IMO, all this talk of watchdog timers forcing reboots is potentially increasing the chance of crashes. And again, people exist on the ground, not in the air, so not crashing into the ground should be mission #1. Forcing a reboot GUARANTEES a crash of a Copter. Causing unnecessary reboots will increase crashes, and increase risk.
Ok, guys this is what happens, when I leave the house for a few hours. I thought we already agreed that this thread was to discuss technical issues related to failsafe? We're not debating the merits here, please take that discussion to the other thread. If people don't keep this discussion technical, there's no point in having two threads discussing the same thing, so I will close one of them.
-
1
-
2
of 2 Next