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
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.
- Radio link lost?
- Receiver failure?
- Throttle wire failure (as demoed in the YouTube vids)
- APM software bug?
- APM hardware failure?
- PWM encoder or decoder failures?
I think you need to answer that before you can figure out a) how to detect it and b) what to do. It seems like different people have different failures in mind.
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.
Wow this thread really gets into it. I have been flying rc for a long time and now that I have just started with the quad. What is a fail safe going to give you? Your money back? Everybody knows that in electronics thing just fail. Even the best fail-safe in the world isn't going to guarantee anything. I have seen alot of things happen in rc and with it there is no failsafe. You can sit here and argue about the legal matters and what not.
What goes up has to come down eventually.
Sorry, guys there's already a thread talking about the legalities, can we not limit discussion here to technical issues?
One problem I see with this, and the earlier discussions, is that nobody is actually talking about a failsafe. Everyone wants to talk about what things you could think of for the APM to do in various situations.
A failsafe is for when control fails. What everyone wants to talk about is fallback modes for minor problems.
There's no point in talking about that until it's worked out how we're going to implement the failsafe. We're going to need a watchdog or other timer to activate the failsafe. So all of these fallback plans are going to have to update/reset that timer regularly to prevent failsafe activation. Until that system is worked out these fallback plans are just going to be additional ways to defeat or avoid having a real failsafe.
I'll just repost part of my reply in the other thread as its relevant and apparently was glossed over::
I wholeheartedly disagree. My logic says that the APM should ship with some sort of default failsafe, one that can be overridden by the user, clearly, if they deem a different method more appropriate for their particular situation. However, for an autopilot capable "brain" for lack of a better term - a piece of hardware that is receiving data from multiple built-on sensors and has the capability to act on its own, there should be some expected out-of-the-box functionality and failsafe.
From Chris Anderson:
How I think I understood that is the APM cannot make any failsafe decisions because the PPM encoder operates independently and is not flashable through software/Mission Planner. This means that the same code running on that independent chip applies no matter what platform you're running on. That would also mean that there is no communication between that system and the APM, or that the communication is bad/damaged/whatever ultimately making it unusable, thus the APM cannot make any decisions. With all the other sensors on the APM I would think information pertaining to the communications/control signal quality would be good info to have. If we have the hardware to fly autonomously and make a certain level of decisions then let it do just that no matter what mode you're flying in.
The same failsafe code has to be used on every platform. Rarely in life does one shoe fit all, and technology, especially NEW technology, is no exception.
If I were flying a plane I would think that upon signal loss preventing safe control of the aircraft it would be best to throttle up, circle (gps hold), and beep the buzzer - hopefully alerting you to the fact that there is a problem that needs your immediate attention and give you some time to fix it.
If I were driving a boat, rover, or any other "land" based platform I would absolutely not want it to throttle up, in fact I would want the opposite. If signal loss occurs for too long I want it to STOP. A runaway gas powered rover throttling up to 60MPH can cause some serious damage, injury, or who knows what. STOP, BRAKE, BEEP. Alert me that there is a problem so that I can correct it.
If I were flying a single, quad, hex, etc al chopper I wouldn't want it dropping from the sky, that's unsafe, and I sure as shit don't want it to throttle up and fly away! In my case there was a 3-4MPH crosswind so it climbed vertically and horizontally. This thing is supposed to know where it's at spatially as it's packed with sensors and designed to self fly... Why not do an Altitude + GPS hold and beep? No matter what it's doing, once failsafe kicks in it will auto stabilize, STOP, BEEP, and hold position even if there is a crosswind. Altering you to a problem. Regardless it wont fly away and it wont come crashing to the ground.
If you wanted to get fancy the failsafe code could change its actions should the battery reach a certain depleted state. In the case of a plane it could auto-spiral down still staying GPS locked. In the case of a land vehicle same result - STOP. And for a chopper it could slowly descend to the ground. It could also include a beeping signaling low/critical battery.
GF is a great way to contain your craft but it doesn't work on or solve the above issues. GF is a great way to vet hardware and test failsafes, but how would it fair using it all the time for every flight no matter the size of the fenced in area?
I believe a certain level of functionality should be possible and defaulted. I think some attention needs to be paid to monitoring the quality of the only signal that's telling this thing what to do.
At this point if the battery gets too low it drops from the sky. If signal is interrupted or lost it either drops from the sky or flys away. It's monitoring for loss of control signal but has no way to act on it. No matter what happens the pilot on the ground has no idea what's going on - either their gear is under control, flying away, or crashing to the ground. Seems like autopilot hardware should be expected to "auto" a little more.
I just want to see this taken care of for everyone's safety, but also so I can feel confident in flying this equipment without the fear of losing my gear or chopping something/one up.
Well, from a legal standpoint, I don't know of any RC equipment maker providing failsafe as a legal requirement nor can I see anyone being able to make the legal case that not providing it is grounds for negligence. But, I'm not a lawyer.
Technically, failsafe doesn't have to be based on loss of signal. Because we are an autopilot, loss of signal. We have an IMU that can tell us our acceleration and elevation. Basically, if we're heading for the ground at a high rate of acceleration, we're in trouble, loss of signal or not. We can add code that detect this situation and in the case of a x-copter, stop and hover at a safe height. For a plane, we can do the same with a loiter.
-
1
-
2
-
3
of 3 Next