Radio input only for about half move of the stick.

[GoogleCodeExporter]

Arducoper ACM

What steps will reproduce the problem?

For all channels except Throttle, stick input only work for about half the 
total stick range.

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

Expected output is linear output on all the stick range.

What version of the product are you using? On what operating system?

ACM 2 latest beta

Please provide any additional information below.

Testing done on the ground with servos in the 50 Hz loop.

Radio or PWM output test show linear output on all the stick range. The problem 
does not come from the radio side.

Original issue reported on code.google.com by olivier....@helidream.fr on 23 May 2011 at 9:00

[GoogleCodeExporter]

one solution for resolve this:

change in your radio setting the EPA (end point ajustement) at 50% and you will 
use all the stick range

regards

Original comment by trix4...@hotmail.com on 23 May 2011 at 11:06

[GoogleCodeExporter]

Definitely not the right solution as you loose resolution and smoothness doing 
this. I think it's better to modify the ACM code.

Original comment by olivier....@helidream.fr on 23 May 2011 at 12:03

[GoogleCodeExporter]

The PWM output for Roll, Pitch, and Yaw are fixed at +/- 450 PWM. That's 
slightly more than 100% range on most radios and we never use the full range 
for output. Please run the setup routines and confirm your radio setup using 
test radio. Also note that the PWM signal is not a standard signal that a servo 
can read. Only ESCs can read the signals. It's outputting near 200hz rather 
than 50Hz. 
Channels 5, 6, 7, 8 are available as output at 50 hz. See radio.PDE for use.

Original comment by jasonshort on 23 May 2011 at 3:51

• Changed state: WontFix

[GoogleCodeExporter]

I think we didn't talk about the same thing.

Radio setup and test has been done. I get for all channel PWM = 1100 - 1900 us 
(with some very small differences).

This translate to -4500 to + 4500 in radio test. So all is ok here.

The problem is with outputs : for channels 1,2 and 4, there is no more output 
change when the stick is pushed after +/- 200 us.

This mean that about half of the stick range is lost.

Ch3 don't show this input range reduction.

If all the stick range were used for CH1,2 and 4 (-400 / +450 us instead of 
-200 / + 200 us), we would have a better precision for roll, pitch and yaw 
ouputs.

Original comment by olivier....@helidream.fr on 23 May 2011 at 4:46

[GoogleCodeExporter]

Sounds right to me. You cant send so much power to the motors. Have a look at 
the equations in motors quad. If you need more power to rotate the copter, up 
the KP value for roll and pitch. 

Original comment by jasonshort on 23 May 2011 at 4:51

[GoogleCodeExporter]

I understand that. But if power changes needs to be limited, it should be 
limited at the output side not at the input side or you loose control 
resolution (and human resolution as well).

Limitations and scaling should be placed on outputs. I will check the code to 
see how the scaling is done.

Original comment by olivier....@helidream.fr on 23 May 2011 at 4:59

[GoogleCodeExporter]

I think you're fundamentally misunderstanding how this works. Your radio input 
is used to give the desired roll angle. Not directly as output. If you want 45 
degree roll you'll get it. (except when aerodynamic effects act on the copter 
during fast flight)
Look in attitude.pde and check out what's going on. The input defines a roll 
error. The error becomes the power used to rotate the craft using the PID 
equation. P is the most relevant here. 

Original comment by jasonshort on 23 May 2011 at 5:11

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ok i understand the error concept. But i still don't understand why i'm wrong.

When i push the roll stick to the max, i get 45 degree input error.
I can effectively check this in radio test, i get +4500 input for roll channel.

If the model is on the ground, this error stay at maximum = +4500.
Then PID is applied, and give the output correction. output = error * PID

Now i push the stick only to about half range. So that i got +2250 radio input. 
The error angle is now 22.5 degree. But the outputs are still the same. There 
is no difference in output value when input change from +2250 to +4500. Why ?

(i checked this with servos, i moved the servo output in the 50 Hz loop for 
this test).

This mean that the stick range from +2250 to +4500 is vasted. I get the same 
response from outputs if i push the stick midrange or fullrange.

I'm investigating in the code but i'm still a bit lost. Is there a code 
schematic where we can see signal processing blocs ? Without this it is not 
easy to master the code. Quite complicated even if it is very well structured.

Original comment by olivier....@helidream.fr on 23 May 2011 at 10:18

[GoogleCodeExporter]

The copter rotates around it's center of gravity. It's not like a servo.  If 
the copter is at a 45° angle and our input error == 0, we don't want any PWM 
added to the motors beyond throttle. We add or remove thrust to rotate the 
copter, not to make it go to a specific angle in space.

We limit our error to prevent run-up of our I-term and to cap our P term 
output. It does not effect the velocity of rotation of the craft at all. It 
simply makes it more predictable. It's a very common strategy to PID control 
loops. If the copter is greater than 25° in error we don't really care. We 
just need to know which direction to turn. As we get closer than 25° we get 
errors that do matter. 

Original comment by jasonshort on 23 May 2011 at 10:23

[GoogleCodeExporter]

You are right Jason i was wrong.

If i manually tilt the APM board 20 degrees, i can get the full stick range 
working.

I didn't saw the -2500 / +2500 error limiting in the code.

error       = constrain(error, -2500, 2500);

Sorry.

Original comment by olivier....@helidream.fr on 23 May 2011 at 10:48

[GoogleCodeExporter]

No problem. I wish this was simpler. It certainly would be easier to debug! I 
learned the code by reverse engineering Jose's code. I created a math model in 
an app called Soulver, but any tool would do. That helps you introspect the 
values as it works. I may make a visual tool in Flash to explain it more.
Best, 
Jason

Original comment by jasonshort on 23 May 2011 at 10:51

[GoogleCodeExporter]

Good idea, perhaps a good visio drawing could be a good start (and less work) ?

Original comment by olivier....@helidream.fr on 23 May 2011 at 11:10