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
This Thread is "What do you think the APM should do on fail safe" Jake you are in effect hijacking this thread? for the second time please start your own, if you wish to discuss this matter? it is not polite..
Sorry, I should have posted in the other thread or started another one I guess. OTOH it's hard not to notice and comment when half the thread disappears.
The one and only things that matter to me is that:
#1 the PPM encoder does NOT continue to put out a signal when it's not getting one (APM control takeover is fine).
#2 The plane does NOT crash under power.
#3 The throttle is cut in a flyaway situation when it exceeds a certain range.
The way I see it #1 should be easy, just fix the PPM encoder bug.
#2 requires an altitude on the plane and a failsafe hard deck where the throttle is cut.
#3 is partly implemented with the geofencing. But in a true out-of-control situation it's not going to work, so there needs to be another failsafe fence or max range where the throttle is cut.
All of these need to be ensured at all times. Anytime any of these can't be guaranteed the throttle needs to be cut. I think the easiest way to implement this is to ensure that we're using a hardware watchdog timer on both the processors to protect against hangs and blocking errors.
#2 + #3 could be implemented with a timer scheme. If the autopilot looses altitude info it should set a timer based on the last known good readings. So for quads it would just assume freefall or use the other sensors for an estimation, but on a fixed wing and you're flying straight and level you could assume you're holding altitude. If you're getting tossed about or other sensors are questionable also you could assume you're falling and kill the throttle based on the last known altitude.
For the fencing you could also use a timer or another fence to know when you've lost hope/control and need to kill throttle.
The only thing I see as making it non-reckless to start a machine and let it fly around under the control of a microprocessor is if there are good safeguards to prevent it from crashing under power. Manual control is the main safeguard, but in an out-of-range condition the autopilot has to take over the job of hitting the kill switch when things are totally out of control. This is the main safety issue. It really doesn't matter much what else it can do.
I think loiter for X minutes, then RTL makes perfect sense. If you're on a mapping mission or the like then it should probably just follow the mission plan and not worry about loss of signal.
Jake I deleted my posts. Doing so... I deleted 1 Ellison post. But I already PM Ellison about it.
I'm sorry about what happend. I'm now a regular member
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.
Thanks John !!
Thanks John for helping to bring this to a close.
Some people may actually want a working passthrough though. From my point of view it is still a logical design flaw to have it outputting signal when it is not receiving one.
It will still be altering the input signal in a manner that could caused undesired or unexpected behavior.
Is there some particular reason you can't just pass things along as one would expect?
By not replicating the input you are destroying information that may be useful. It might be useful for some people to know if they have a range failsafe or a broken throttle wire. By obscuring the signals the APM can't tell the difference.
Despite my comments, thanks for the work. You've made a major improvement in safety which will almost certainly save gear and reduce the potential for injury and property damage.
Jake: The PPM Encoder as the name implies, outputs a PPM stream to the APM main chip. It is impossible to skip a channel since a standard PPM signal is a pulse train with 8 channel values, where all channels must contain a value.
I guess I don't understand enough of the specifics. Why is it not possible to encode a zero or skip a pulse?
I guess I don't understand the specifics of RC PPM. I would think that a zero could be encoded and that a missing pulse per frame would be easy to do. Is the signal entirely differential to each previous pulse and not the frame?
I'm also not really seeing why the PPM is going to the main chip. I thought the PPM/PWM would be decoded from the input and sent to the main processor in a binary format?
Any resources you could point me to so I can get a better understanding?
Apologies if I'm teaching people to suck eggs.
The PPM Encoder takes up to 8 individual inputs from the Rx and re-encodes them as a single pulse train.
This allows all the Rx inputs to be received by the main APM MCU (2560) on a single pin with a single interrupt, thus freeing up hardware I/O and MIPs for autopilot functions.
For PPM, the channels are encoded as a "SYNC" or "Start" pulse of defined width, followed by one pulse for each channel.
The first pulse after SYNC is channel 1, the second is channel 2 etc.
Edit - Picture from MFTech:It is self-evident that pulses cannot be skipped as the APM would then shuffle channels 'up' one for each skipped channel, having no idea of which channel(s) were skipped.
RC servo control pulses are nominally 1000uS to 2000uS in width. Thus 900uS is considerably shorter than nominal.
You can however force most RC equipment to output 900uS by trimming as short as they go, hence it can be programmed as a failsafe level that will not be output under normal conditions.
This makes it a very good value to use as an 'invalid data' marker.
Still not quite getting this. If I were to skip a channel why exactly would this screw up the ordering?
I don't see how this is "self-evident".
To me it is "self-evident" that you have a 22.5 ms frame with a sync pulse and 8 time slots. It seems really strange to me that they'd use variable time slots. A fixed time slot system would be easier, more reliable, and use less processing power I would think.
Anyways, thanks for the explanation. Maybe you can clarify my confusion even further since a variable frequency control scheme seems like chaos to me.
I don't know much about analog signals other than digitizing them. Maybe a simpler PWM->binary scheme would work better in the long run?
I assume that the APM is using edge-triggered interrupts to detect the start of each channel in the multiplexed signal, which is really simple (simpler than synchronizing based on a clock signal, I'm guessing).
But it should still be possible to signal invalid or other conditions using the edge-triggered approach, using pulse lengths that won't be output by a receiver under normal conditions, as Richard pointed out.