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
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.
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:
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.)
have you had a chance to test on a stock 9X (or other controllers) or should I do that now?
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. :)
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.
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?
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.
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.
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.
> 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.