Anyone know why servos connected to my APM 2.5 outputs crank to 0% for 15 seconds while booting when there is nothing plugged into the APM 2.5 PCM/PWM inputs? Is there a parameter that I can set to avoid this? It pushes the servos well below the Arduplane "RC minimum pulse width" parameters for each channel which is particularly annoying. It doesn't matter if the APM is configured for PPM or PWM input.
Why do I care? When I power up my Arduplane APM 2.5 setup for PPM input and connected to my PPM mode FrSky D8R-ii plus, all my servos connected to the APM crank to 0% (strain!) for the first 15 seconds that it takes the APM to boot up. Then they all go to the middle as expected. It only does this when my transmitter is off. Of course, normally my transmitter would be on but there are times I want to plug in my plane without firing up the transmitter. This behavior didn't happen when I was running PWM inputs and a bundle of cable between my Spektrum receiver and APM.
The FrSky D8R-II plus is properly setup for failsafe. For example, when I boot the apm & D8R-IIplus when the transmitter is on, the problem doesn't happen and if I later turn off the transmitter, the plane goes into failsafe mode (Circle followed by RTL) as expected.
Replies
I agree, this needs to be changed. I wish I knew how....Drives me nuts, but I've managed so far as well.
That would be great!
It also seems to me that the FrSky D8R-II plus running D8R-XP firmware should immediately send its configured failsafe PPM signal after power up if it isn't hearing from the transmitter. Instead, I'm pretty sure it is sending nothing since the APM reacts that same way during power on, whether or not the RX is connected or disconnected (and when the transmitter is off).
I'll try to put a scope on it to see for sure. Learning to use sound card oscilloscope to visualize my control signals has been on my list of a while.
Hi,
The code looks real good, actually. There are no "too many defaults fighting to overwrite each other" as is often seen in other software.
So you really have your transmitter and your receiver on while starting up the APM?
The transmitter should be on when you start up. What happens is that the APM's failsafe feature kicks in during startup. That failsafe has nothing to do with radio failsafe. It's about reverting to manual control if the program seems stuck somewhere and the mainloop does not run (which is the case during startup init). If the RC input has never received anything when that happens, it will default channels to their mimimum value (900 us) as we see. But if your TX is running, it should really pick up some normal centered channel values and output those.
All modern RC receivers that I know send nothing on their outputs until they hear from their transmitter.
Do you use single cable PPM or do you use that PWM to PPM converter with, like, 8 cables from the receiver? I don't know what that does if there is no signal from the RC receiver.
A quick fix is to locate the init_ardupilot() procedure in system.pde. There is a call to init_rc_out(). If you move that to the very bottom of init_ardupilot(), the problem is gone. But only do that if you are quite sure there are not good signals from the RC receiver to the APM very shortly after startup.
The servo torture is your punishment for not turning on the transmitter first :)
Regards
Soren
Thank you very much for looking into this and getting back to me.
>So you really have your transmitter and your receiver on while starting up the APM?
When I plug in my plane battery, both APM and RX power on at the same time. If the TX is on when I do this, no servo torture. If TX is off, then torture.
>If the RC input has never received anything when that happens, it will default channels to their mimimum value (900 us) as we see
I'm not concerned that it moves the servos. But it seems to me that the APM shouldn't move them beyond the parameter specified in RC#_MIN value - the init code has to be either ignoring these parameters or moving servos before it has read them, neither of which sounds right to me. I have mine dialed in as follows and the APM code should honor them by not exceeding them, unless there is some good reason that I can't think of...
RC1_MIN 956 (Aileron)
RC2_MIN 1181 (Elevator)
RC3_MIN 1143 (Throttle)
RC4_MIN 1097 (Rudder)
>All modern RC receivers that I know send nothing on their outputs until they hear from their transmitter.
I have no expertise in this area, but my testing contradicts this comment. I've been running my APM for almost a year now with a Spektrum AR6200 DSM2 RX which only outputs PWM. When it is wired up to the APM in a most simple way with four PWM cables, and I power up my plane (which powers on both APM and RX), I do not get servo torture regardless of my TX being on or off. I presume this mean that on power up with TX off, my AR6200 RX is outputing something, probably it's failsafe signals.
If I remove the RX (removing the four PWM cables) and power up the plane, I get torture.
>Do you use single cable PPM or do you use that PWM to PPM converter
Single cable. The FrSky D8R-IIplus RX outputs CPPM on one cable which is perfectly understood by APM 2.5. I'm hoping to maiden this new setup tomorrow. It really works great so far on my bench, even have RSSI now on my MinimOSD.
>If you move that to the very bottom of init_ardupilot(), the problem is gone.
I should definitely role up my sleeves and try to understand/review the code. That's on my list. But until I get more comfortable understanding it soup to nuts, I wouldn't want to be flying code that I've modified. But definitely thanks for the suggestion. I'll look at this part of the code for sure.
>The servo torture is your punishment for not turning on the transmitter first :)
Touché!
Thanks again
Bill
Hi,
Okay I think we have pretty much gotten to the bottom of it. The Tx should be on at bootup and things should be okay. I had some servo torture too the other day, I really have to check once more that I did remember the Tx. Else I need examine this again.
But okay, what we get is:
1) In Ardupilot failsafe mode (fail safety against lack of main loop progress, not missing signal), the RC input is routed straight to RC output with no regard to RC-min, max, anything. (Todo: See if elevons work in the mode where you fly without elevon mix on Tx and Ardupilot does all)
2) If the Rx was never heard from, the firmware assumes minimal channel value, hardwired to 900 us. The HAL layer does this. Maybe it shouldn't really; the mimimum enforcement doesn't quite belong there.
1+2) So servos get a 900 if powering up without a radio signal - with the FrSky and with all my receivers anyway. With the Spektrum, I don't know, never had one.
I heard stories that eventually the whole RC input output in Ardupilot should be cleaned up. That will be a pretty tough job...
If you always have the Tx on while booting up you should be okay for now.
Regards
Soren