What do you think the APM should do on fail safe
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 to This Discussion
-
Permalink Reply by Andre S on -
Great initiative this discussion. I have been trying to follow the other thread but it seemed to change directions all the time.
So how about doing as you suggest, enabling GF by default in a smallish box (say 100m x 100m x 100m) where point (50m,50m,0m) is the home location? I mean having a box "around home"?
Only problem I see with GF is that it needs a working GPS. The failsafe should be (somewhat) resilient to loss of GPS, which could be a gradual shutdown of the motors for multicopters and a complete throttle shutdown of throttle while keeping other servos for planes. Just my 5 cents..
-
Permalink Reply by Jake Stew on -
There's a good chance that your keyboard has a carriage return key on it somewhere. Posting a massive wall of text like this, especially without proper capitalization or punctuation, isn't the most effective way to start a discussion.
-
Permalink Reply by Brad Smith on -
Ive always had trouble with being proper :P i posted in the wrong discussion and had to cut and paste to this(still don't think its the right place) but its the best i can do with my limited knowledge sorry
-
Permalink Reply by Brad Smith on
-
if you would like to edit it feel free as long as it comes out to the same point i,ll replace it with yours thanks
-
Permalink Reply by Eagle on
-
Brad, I inserted some carriage returns. I did not change anything else ;) Jake you are a bit of topic.
-Eric
-
Permalink Reply by Tom in ON on -
Jake, I agree with you. Good topic Brad, but after reading the first line I skipped to the answers.
Good that others have more patience and goodwill.
-
Permalink Reply by Ellison Chan on -
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.
-
Permalink Reply by Jake Stew on
-
You're right, in most cases I don't think it would be negligence. Negligence is "a failure to exercise the care that a reasonably prudent person would exercise in like circumstances". Reckless endangerment is "recklessly engaging in conduct which creates a substantial risk of serious physical injury to another person".
“ 'Reckless” conduct is conduct that exhibits a culpable disregard of foreseeable consequences to others from the act or omission involved."
Forgetting to check your rearview mirror is "negligence". Placing a brick on your accelerator and letting your car run down the road is "reckless endangerment". The closest analogy I can think of is throwing rocks over a wall when you don't know what's on the other side, that would also be reckless IMHO.
As I've pointed out several times earlier... Starting a potentially dangerous machine without a guaranteed way to stop it is reckless. If it endangers (doesn't have to even hurt someone) it is legally "reckless endangerment".
It is also not weather or not it's the RC makers responsibility to include a failsafe. You are responsible for the judgement on weather your equipment is safe to operate or if it may endanger people. If you always operate out in the country with a reasonably short range aircraft, and keep it in sight, and let others know you're flying, and your plane is loud enough for others to hear and avoid... then you can safely do pretty much whatever you want.
I don't think most people fly that way anymore. People are flying in backyards, parks, sports fields, etc. with other people around.
-
Permalink Reply by Zen on -
I'll just repost part of my reply in the other thread as its relevant and apparently was glossed over::
"It is entirely down to the operator to examine their airframe and airfield and select an appropriate response to loss-of-signal.
It is not the place of Jake Stew, myself, 3DR or DiyDrones to make that decision, and this was never about what the APM should do on LoS..."
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:
"... let me explain a little more more how the PPM encoder works. First, it runs on the 32U2 chip, not the 2560, so it's loaded at the factory and can only be changed with an AVR programmer. Second, because it's running on a different chip the same PPM encoder code applies to all platform software, from ArduCopter to ArduPlane to ArduRover, etc."
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.
-
Permalink Reply by Brad Smith on
-
all good points ,at this stage we would probably be best to work on a interim solution that could be implemented through the MP
"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?"
but it would keep your craft in a defined area at a defined alt and speed and would override a faulty failsafe rx issue and with autoland would save the day
-
Permalink Reply by Richard on -
Your "If..., If..., If..." is exactly what I meant by the phrase.
"It is entirely down to the operator..."
You have your APM in your hands, and how can it possibly know which of those three options is the right one?
Perhaps "900us" on the throttle channel is actually "maximum power to the engines!"
You, as the operator of the craft, are the only one who can know* which response is the correct one, and you need to set it.
APM could, in theory, do many different things if contact is lost with the operator.
The end result of that action must be an aircraft/rover that is stationary, disarmed, and on the ground within a predictable region that's as small as possible.
How to get to that stage is the question that only the operator can answer.
It is however a great idea to come up with a few standard responses for the operator to choose from.
One of those options should be "Kill all engines". That's clearly the right thing for a rover in many (most?) situations and may suit other craft.
Other options are also good ideas - for a *copter, controlled vertical descent to ground and disarm is a good option - it saves the airframe and avoids dropping a possibly large object on someone.
- An active *copter is rather loud and a slow descent gives someone under it warning and time to move out of the way that they would not have if it simply dropped out of the sky.In my opinion, an infinite loiter is a bad solution - if signal is never regained, the craft will eventually run out of batteries and crash after a long period of uncontrolled flight that may interfere with the safety of other craft.
- Even if the signal is regained before the batteries run out, the operator should be terminating the mission anyway to determine the cause of the fault.*You're the one legally responsible, anyway.
(Unless you're under the local age of majority in which case your parents/guardians are responsible.)
-
Permalink Reply by Zen on
-
I don't disagree. I'm talking out-of-the-box functionality. All of which can be changed or overridden should the pilot know what they're doing. The "endless" loiter is bad as you pointed out, which is why I suggested the low battery function. If this thing knows where it's at (roughly) in a 3 dimensional space then maybe it could hold for a bit then drop by x feet every x seconds as dictated by the battery strength?
Just trying to figure out a way for the autopilot to engage and save the hardware and the people. With the current hardware setup/code it is not possible. When that is fixed and it becomes possible then a "default" set of failsafes would make this a lot less risky of an adventure. I don't expect the APM to know anything about what is controlling it (9x, spektrum, etc), but that shouldn't matter anyway --- the autopilot should be able to take over with regard to safety of the craft and the (possible) people below when it's no longer being told what to do.
Also, no matter what failsafe is active - I think the buzzer should sound. As per the auto-decent example, sure the chopper should be loud enough, but it wouldn't hurt to beep also.
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
ArduCopter User Group
1282 members
-
Terrain/Surface Mapping
115 members
-
ArduRover User Group
183 members
-
ArduCopter Italian Group
87 members
-
ArduPlane User Group
673 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
