RC4 output driven beyond endstop on ArduPlane startup

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Start Arduplane without an RC signal at the RC receiver.
2.Monitor RC4 output using Planner Status tab on the Flight data screen.

What is the expected output? What do you see instead?

I expect to see RC4 produce the RC4_TRIM value output (as contained in the 
EEPROM), as happens for RC1 and RC2 outputs. RC3 goes to the RC3_min value.

Instead, the output is shown as 0, and the servo is driven hard over. If the 
mechanical setup doesn't allow for the full servo travel then the servo will be 
stalled.

If I start the AP up with the receiver getting a signal then the servo isn't 
driven hard over, I suppose because the mux has passed control of the servo 
directly to the receiver. A couple of times I saw the RC4 output shown as 0 
until I switched out of manual mode but I couldn't reproduce this behaviour. 
Once it started updating the status display is showed something around the PWM 
output I would expect from the receiver.

I don't know whether my RC receiver produces PWM output before it receives a 
signal. It's an Orange 2.4 FAAST compatible 8 ch receiver.

What version of the product are you using? On what operating system?
AP 2.26 as downloaded by Planner 1.0.99

Please provide any additional information below.

I also see the RC1,2 outputs go well past the limits programmed into the EEPROM 
if I switch to stabilize or FBW and put the aircraft into extreme attitudes. 
E.g. I saw numbers over 2000 when the RC1 and RC2 maxes are 1792 and 1797 resp.

The min and max RC1 and RC2 values were generated by the transmitter with the 
elevon mix active, so should represent the full elevon servo travel.

Original issue reported on code.google.com by philcole...@gmail.com on 2 Dec 2011 at 8:34

[GoogleCodeExporter]

On the startup with the RC signal present - if I start with any mode other than 
manual selected at the transmitter the rudder servo will be overdriven.

The overdriving happens after AP has gone through the its init sequence, just 
after the second elevon servo wiggle.

Original comment by philcole...@gmail.com on 2 Dec 2011 at 4:23

[GoogleCodeExporter]

Looking at the RC outputs with a scope while the APM starts, I see the first 
four channels all start at 1.5 ms after reset. After the initializing is done, 
I see the channel 2 servo wiggle. At that time, RC4 goes to 0.9 ms.

This is with the RC transmitter set to select stabilize mode via the RC8 input 
while the APM is booting. After switching to manual and back, the RC 4 output 
goes to 1.5 ms. 

Original comment by philcole...@gmail.com on 14 Dec 2011 at 9:07

[GoogleCodeExporter]

V2.27 alpha still does it.
Looking back I see that I didn't mention that all this is with elevon mixing 
enabled and working correctly.

Original comment by philcole...@gmail.com on 24 Dec 2011 at 8:33

[GoogleCodeExporter]

I've pushed a fix to 
http://code.google.com/r/philcole1234-wip/source/detail?r=502563160362c6b1e3bf44
8ef6d5c183032fca00

Revision: 502563160362 

Since the elevon mode takes up all the config switches I don't have an answer 
for reversing the rudder channel except to use the EEPROM. I have yet to test 
whether EEPROM reversing on the rudder works.

Original comment by philcole...@gmail.com on 27 Dec 2011 at 11:40

[GoogleCodeExporter]

Reversing from the EEPROM works.

Original comment by philcole...@gmail.com on 28 Dec 2011 at 8:29

[GoogleCodeExporter]

V2.28 Still has this issue.

Original comment by philcole...@gmail.com on 29 Jan 2012 at 4:10