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 Richard on -
That variable period is what Pulse Position Modulation means.
It is the way that analogue RC Txs communicated with their Rx, and thus a lot of Rxs still have this as an optional built-in output - including modern digital ones.
You'll notice that in the above diagram, "Start" is not given a length. In reality the Start only has a minimum length and can be as long as needed.
There is also no requirement for the Rx (or PPM encoder) to output exactly 8 channels, it can output fewer (or in fact more).The key reason for this scheme is because it can be easily decoded into standard servo pulses using cheap discrete logic - a microcontroller (MCU) is simply not needed.
(My old 40MHz gear was easily modified to add an extra four channels, giving me an 8ch TX/Rx for the price of a 4 and half an hour's work)
An MCU can receive this PPM signal using one interrupt on rising edge and one timer as follows:
- Measure the time between each successive rising edge.
- Once you get more than 6000uS, begin.
- The time to the following rising edge gives you Channel 1, the next is Channel 2, then 3 etc.
Thus if Pulse 2 is omitted, then the width of Pulse 3 will be used as Pulse 2 and so on.
Once the next "Start" completes it'll know that one of the channels in the previous frame was missing - but which one? There's no way of knowing.
- Not to mention that Rxs are allowed to output fewer than 8 channels so ti could be normal!As a bonus, almost all MCUs have at least one "Capture Compare" port, which handles the rising-edge-to-edge timing measurement in hardware so you don't even have to worry about interrupt latency affecting the measurement, as long as the pulses are long enough that you can read it from the buffer before the next rising edge.
(So very short pulses are bad.)
-
DeveloperPermalink Reply by Andreas M. Antonopoulos on -
John,
have you had a chance to test on a stock 9X (or other controllers) or should I do that now?
-
DeveloperPermalink Reply by John Arne Birkeland on -
There has been no change in the encoder logic, so I have not done extensive testing with different systems. Just the usual latency and timing tests with a scope using my regular Futaba radio and the FASST system. Only difference now is that if you unplug the throttle channel, instead of keeping the last known value it will change to 900us.
So please do any tests you feel like. There is no such thing as to much testing. :)
-
Permalink Reply by Eagle on
-
Sorry John I'm lost... ArduPlane 2.34 is working so far... should I follow the HowTo? and apply the code changes? or "There has been no change in the encoder logic" ???
-
DeveloperPermalink Reply by John Arne Birkeland on -
What I meant is that there has been no change to the logic used in the code to make ppm from the servo signals, so behavior is exactly the same as earlier except that it now also will detection and handle lost of the throttle signal. So unless you have a broken throttle wire or one of those 9x radios that stop the throttle signal on failsafe, you will not notice any difference.
If you decide to update, follow the wiki how-to.
-
Permalink Reply by Jake Stew on -
Not flying away to later crash who knows where, possibly still under power, whenever a non-locking signal wire connector comes loose seems like a pretty major safety improvement.
Don't you think everyone should be doing the update? Shouldn't every page on this site have a big red warning notice telling people they need to perform this critical safety upgrade ASAP?
-
DeveloperPermalink Reply by John Arne Birkeland on -
Unless you change your tone of communication, this will be the last time I respond to any of your messages..
Yes, there is/was a design flaw in the PPM encoder under certain conditions. At the moment of design the 9x FS behavior was unknown, so the possible danger of the flaw was balanced against the need for good overall performance and decided to be at an acceptable level. When I was made aware of the 9x FS behavior, a patch was made since the danger no longer was at an acceptable level.
You behave like you have never flown R/C and UAV's before, and yet have a fixed expectation as to what is possible. R/C and UAV at the hobby level and even more so at the DIY level crash all the time. The developers who know the system better then anyone, crash more then most people. Heck even the big boys from the military and well known aviation companies spending big money, crash all the time. So it is all a balancing act where you try and find acceptable solutions, but guess what. In this hobby you will crash, it is just a matter of time.
-
Permalink Reply by Jake Stew on
-
Please educate me or point me in the right direction, I'm happy to do my homework. I wasn't aware that there is any mention of these issues anywhere, which is why I'm trying to learn through discussion via this forum.
I realize RC aircraft crash all the time. I have lots of glue and packing tape to attest to this knowledge.
I would respectfully suggest that unexpected runaway behavior is a little different than simple failure or known possible errors. My understanding from reading the documentation was that the PPM encoder puts out the input when in manual mode. I'm just trying to understand the reasons and circumstances where this would not be the case.
Since I was completely surprised by this design issue/behavior I humbly suggest that others might be surprised also, and it might behoove the community to inform them in some way.
I seek only to spare someone the unfortunate happenstance wherein a loose connector might cause them significant financial loss, and the additional emotional distress inflicted when they find out there was a patch that could have prevented it had they only known of it.
-
-
Permalink Reply by Ellison Chan on -
Jake, the "non-locking wire" connector is a non-issue. If a flyer is so concerned about that, simply tie it down or use locking connectors. The onus is on the modeller building the aircraft, not the software.
The only thing a radio failsafe needs to be concerned about is a failure in the radio that prevents the receiver from getting a proper signal. Let's stick to that issue in this thread, which is the intention, not to worry about whether we can handle a loose cable.
-
Permalink Reply by Jake Stew on
-
> Jake, the "non-locking wire" connector is a non-issue.
Of course! ...unless it comes loose and your aircraft flies away under full power because a certain device starts injecting an unintended signal.
We're talking about failsafes in this thread, that's what my post was about, so please don't hijack this thread.
-
-
Permalink Reply by Andrew Dunlop on
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
-
Queensland
4 members
-
ArduCopter User Group
1291 members
-
UK Ardupilot Group
110 members
-
ArduRover User Group
184 members
-
Documentation Editors
51 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
