Hi
We're working on a project and a part of it is to make the robot turn a certain angle. When the robot is fully charged the code works perfectly but when its 75% charged it doesnt. The encoder value isnt reached. We browsed around on the forum and saw people have the same problem but haven't been able to solve it. Can any1 help us out?

the code looks somthing like this

[/code]

I'd like a little more info. In particular.

Are you trying to turn a large or small number of degrees? Is it more or less than 45 degrees?

If you change the motor speed from '-50' to '-100' does the code now work?

If you lift the robot into the air and try the program (or at least the turn function) do the motors turn OK to the expected locations. YOu can check the value of the motor encoders with the Debugger "NXT Devices" window. What this is doing is checking the performance of the motors with a much reduced friction/drag co-efficient.

Is the problem that it doesn't move at all or that it does move but the error is large? I suspect that it is the second type. If so, here's what may be happening:
1. The control algorithm uses a PID algorithm to (hopefully) smoothly move the motors to stop at the target encoder position.
2. The algorithm reduces the power level to the motors as it gets close to the target so that it should not overshoot the target.
3. If in state (2) and the firmware detects that the motors are not moving and the target is reasonably close it gives up thinking "this is the best that I can do". The logic is that the motors are not moving and a much higher power level needs to be applied to get them moving and overcome the initial static friction; this is likely to cause the motor to overshoot the target; since the motor is reasonably close to the target it simply ends.
4. Most of the time tuning the PID algorithms were performed with fully charged batteries and a lightly loaded robot. The parameters selected may prove to be too small to correct from lower battery levels and/or robots with lots of friction.
5. Another potential problem is that if the load (friction) on the two motors is not equal. Say for example one wheel is binding against axle for lots more friction and not the other one.

Let me know about the above. Meanwhile I will set up a test condition of low battery and heavy load and see what I can find.

I can confirm that there are many problems I also got using
nMotorEncoderTarget in my navigation program.

I finally replaced all that code and wrote my own algorithms which are working absolute correctly down to fractions of a cm after many meters of going and turning.