I have Hitec R/C equipment in my APM2-equipped Telemaster. The rx is the Optima 7. This rx has a failsafe capability where you can select the throttle setting and the control surface position when signal is lost. Loss of signal results in the failsafe selections within one second. My configuration setting is zero throttle and neutral control surfaces.
I have tested this setup (no APM connected) with partial throttle and control surface deflection. Turning off the tx results in advertised failsafe behavior.
My understanding is that in APM2 MANUAL mode, receiver outputs are supposed to be directly passed through without modification to the servos and ESC. Thus I expect failsafe settings to be passed through unchanged when I test it with APM2 connected.
The results have left me concerned! It appears that the control surfaces behave properly, ie, they go to neutral. The throttle, however, does not go to zero. There is a modest reduction in the motor speed but it is nowhere near zero.
Do I have reason to be concerned?
The radio and PPM encoder people both probably would have avoided these problems if the signal wasn't designed and referenced in such a wacky manner.
Again you are talking about how you want things to work, not how they actually work in practical applications.
Decoding the incoming PPM signal on the main CPU is very efficient because of dedicated timer hardware designed to catch and measure incoming pulses like a PPM signal. A digital communication protocol between the PPM chip and the main chip, would require A LOT more resources to decode in the main chip. The same main chip that is very, very, very busy doing everything else needed to keep a plane/copter in the air. Most of the development time on the APM platform is spent finding ways of making the things we want to do, efficient enough to be possible to execute with the resources and execution time available. That means that usually they are far from the ideal solution. But the alternative is to not do them at all.
I don't understand... the Atmega32-U2 has one 8-bit timer, one 16-bit timer, interrupt and wake on pin-change, and 20 external interrupts.
That sounds pretty weak compared to most other modern microprocessors, but you can trigger your interrupts on either the rising or falling edge of the signal and digitize the thing pretty easy using just interrupts and one timer at most?
The Atmel summary of functions looks impressive at first glance. But all those functions have shared hardware and dedicated I/O pins. So once you select one feature, you loose all others that share that hardware. Same goes for features sharing the same I/O pin. If you use the pin for one function you cannot use it for another. So there is a very limited set of hardware functions that you can run at the same time. The whole thing is a juggling act with assigning pins and selecting combinations of hardware features that can work together on those pins.
And the 32u2 is not dedicated for PPM encoding. It is also used a USB<->Serial converter when talking to and programming the main chip.
So in the end with the USB<->Serial running, what was left to work with for the PPM encoder was 8 input pins with a shared toggle in pin change interrupt, one toggle on compare interrupt with output pin (PWM generator), and a single 16bit timer to keep track of the timing for both the input and output signals.
Vernon, I tried these settings on my ARDU Copter, it was flying fine and then something happened, not sure what and it just dropped out of the sky. It would have been fine, but it landed on the neighbors porch. Also not that big of a deal, except the cat was outside watching it fly around and attempted to grap it out of the air. The cat is now minus part of its paw and my neighbor is pissed. I dont think this was a good "failsafe" as it failed and nearly killed the cat!
Please don't take this the wrong way, but did you test those settings?
Rule One: Know what your aircraft does on loss-of-signal. Never guess and never assume.
If you don't know, don't fly until you find out.
- Take the props off, run it up and turn off the Tx. What does it do? Is that what you expected?
Rule Two: If it's not what you think it should do, given the aircraft and where you fly, change it. Then go back to Rule One and know that it really does that.
- There are several options available to the APM, some 'smarter' than others. Smarter options are clearly harder to test.
Finally, the right settings for your aircraft are not necessarily the right settings for my aircraft.
Quite simply, it is your responsibility to decide what your aircraft should do, and it's your responsibility to check that it actually does that. Nobody else can do that for you.
My quadcopter is small, dumb as a brick and simply drops out of the sky. I know this so I only fly it in situations where this is a safe thing to do.
I'm not surprised your neighbour is pissed, as it doesn't sound like you knew what the failsafe behaviour of your aircraft really was.
Finally, assuming you were flying a multicopter, those are actively stabilised and any number of things can make it crash - one stalled motor or cracked prop, one dodgy power connection and down it will go. So really, (almost) any multicopter could deck itself at any moment.
I know that a well-optimised multicopter looks so stable, but they really are continually fighting to stay in the air.
I'm sure you'll never make that mistake again. You aren't the first and won't be the last to do that - hopefully others will learn from your mistake as well.
The first part of your message addresses the very issue that prompted me to start this thread. If I lose signal in MANUAL mode I want the motor to stop and the control surfaces to go neutral (no flyaway). I set up this failsafe condition in my rx and tested it with APM2 out of the loop. It worked as advertised.
Then I put APM2 back in, selected MANUAL mode and tested the rx failsafe again. Control surfaces went to neutral but the motor did not stop! So somehow APM2 is influencing the throttle channel. This is contrary to my understanding, expressed by Chris Anderson (it would be nice if he chimed in) that MANUAL is a pass through mode (like the autopilot is not running),
There's been a lot of discussion and fighting over that recently. The APM doesn't have any sort of pass through.
It's supposed to have a software mode to emulate a pass through type connection, but there are problems with decoding and re-encoding an analog signal without problems.
I've been trying to get them to clarify these things in the pseudo-wiki and documentation, but I can barely get them to actually explain it in the forums without getting my ass chewed.
Important info about failsafe:
APM has a limited failsafe function, running on the secondary PPM encoder processor, which is designed to do two things:
Here's what the failsafe will not do:
Further the manual (and this is for APM 1.0 not 2.0) states you must modify the stock firmware in the PPM encoder to configure these 2 optional functions
2.- PPM Throttle Failsafe: The throttle failsafe is an optional feature of the built-in "PPM encoder" of the APM. The header file of the PPM encoder source code allows you to define which input channel the PPM encoder will monitor and the threshold values. If the defined channel reaches the defined threshold value then the "failsafe" will be triggered. (This usually happens when your 72Mhz is out of range or turned off.) When the failsafe is triggered the PPM will set the output servo signals to the user-defined positions. These "pre-define servo positions" are located in the same header file of the PPM encoder source code (I will explain this later). This allows you to set the autopilot to the correct mode to safely return to home (Multiplexer routed to autopilot and autopilot mode set to "Return to Home").... But for this you will need basic programming skills, to install WINAVR/AVR STUDIO and have an AVR programmer... I'm working on a simple solution... In the meantime, the easiest way is to switch to 2.4Ghz RC systems. Buy one now. ;-)
3.- PPM Multiplexer Failsafe: This feature allows you to "hard" route the four main input channels (Ch1, 2, 3 and 4) to the outputs (Ch1,2,3 and 4), by using any defined input channel (In the same PPM encoder source code header). Channel 8 is the default channel for activation. This is useful in development stages when the Autopilot may freeze or crash (It will work even if the microcontroller is dead). This in not useful for helicopters and quadcopters, because the special mixing needed to fly those things will be done inside the Autopilot, so be careful. Anyway the header file allows you to disable this feature, this will also free another input channel that can be used for something else....
I think you are specifically refering to #3 and again, it requires you to flash the PPM in order to work.
This is why in my first post, I provided the link and instructions to flash the PPM to the latest update which would detect your failsafe settings and fix your safety concern.
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.
How did Trent and Nick of MyGeekShow.com manage to get the failsafe on the APM2 to work with a seemingly stock 9X radio?
In eposode 74 they also show the Tx/Rx LEDs flashing on the APM2 with nothing attached to the USB port. Is this showing PPM activity? The LEDs on my stock APM2 do nothing when the USB port is not active. Is this part of the PPM firmware update?
With others help I have managed to reflash my APM2 with the latest PPM firmware (v2.2.68). I now see the same LED activity that I saw on episode 74 of MyGeekShow. With my stock 9X radio and receiver the Tx LED flashes rapidly with good signal reception and slowly with no reception.
The best part is the failsafe. Upon signal loss the AMP2 goes to circle mode. If signal is restored within 20 seconds it returns to the mode you were previously in. After 20 seconds it goes to RTL mode. It will stay there until the signal is restored and you manually change to another flight mode.
I just purchased the upgraded Tx module and Rx from HK to make my 9X radio system failsafe but now I see that will not be necessary.
I am glad Trent and Nick made this work. My question is why didn't I found out about this here on this forum! Has someone posted this capability somewhere here and I just missed it? This is great news ,IMHO, for 9X radio owners. I know this will probably keep me from losing a plane!
I started this thread by posing some questions wrt my Hitec rc equipment and failsafe. Your latest message is interesting. Does the APM2 failsafe work as you describe regardless of the active mode? Do you think if I reflash the PPM firmware my system will work like yours?
The failsafe works from the 'manual' modes. Stabilize, FBW, manual etc. If it is in guided/auto mode it will not switch on radio loss. I do not know about your Hitec. It would be worthwhile trying. I didn't know it would work till I tried it! You can always revert back to the older version.