trim_radio() can read incorrect values

[GoogleCodeExporter]

trim_radio() is the power up function to store trim values from the radio (it 
assumes sticks are centered, and assumes radio is on!).

With RX constantly powered up and emitting good values, trim_radio() does not 
receive *stable* values immediately after hardware reboot or hardware power up. 
This causes incorrect trim values to be stored after a reboot, now and again.

This may or may not happen with other RX models (I tested with Spektrum) or 
with other power up sequences (for example, powering up radio and hardware at 
the same time) however it appears that ArduPilotMega does not wait for receipt 
of stable and plausible channel values before storing them as trim.

What trim_radio() should do is read the radio repeatedly with a delay each time 
through until
a) values have become stable (min/max for each channel is nearly the same over, 
say, 500ms)
b) values are not indicative of no connected RX, or an RX that has not yet 
bound and is thus not emitting any PWM yet.

That way trim_radio() will block until a good radio link is detected, and the 
user has stopped moving sticks, before storing trim values and proceeding.

Original issue reported on code.google.com by justinbe...@gmail.com on 5 Sep 2011 at 2:49

[GoogleCodeExporter]

Trim_radio() is called after the IMU calibration, which takes more than a 
second.  I am aware that RC values from the PPM encoder are typically unstable 
at startup, but only for a period well under a second.  We have not had any 
issues as you described since locating trim_radio() in its present location in 
the startup algorithm.  Please describe the conditions causing bad values.  

I can see how this can occur with HIL simulation as the IMU calibration is 
skipped.  If HIL is part of the condition set causing the issue try adding 
#define GROUND_START_DELAY 1 to your config file and let me know if that 
resolves the problem.

Blocking algorithms as you describe have proven highly undesirable from a user 
support perspective.   While it would seen intuitive that the system should not 
"fully arm" (or whatever) till everything is really nominal, in reality what 
happens is that we get flooded with user support requests because users don't 
understand why the startup wont complete when some condition is out of bounds.  
We have removed almost all blocking conditions from startup, per Chris A's 
request (who gets saddled with most of the user support requests), and probably 
don't want to add any back. 

Original comment by dewei...@gmail.com on 12 Sep 2011 at 1:44

[GoogleCodeExporter]

Original comment by dewei...@gmail.com on 9 Jan 2012 at 4:30

• Changed state: WontFix