Motor rotation errors

[mcsummation]

During one phase of Odin's initialization, it:
1) resets the rotation counter on motor B;
2) backs up until the color sensor detects BLACK;
3) grabs the rotation sensor value;
4) coasts motor B;
5) waits until motor B is not moving;
6) reads out the current rotation value;
7) goes forward the distance read in step 6;

The rotation counter at the end of step 7 is never 0. Never, ever. It varies, somewhat, with the power levels going both directions, but is never 0. It varies from 4 (power = 10) to 80 (power = 40). And it is always overshoot.

I've even put in long waits, seeing if that would help. It didn't.

The error is real, because the robot always stops beyond where it started.

Anyone have any suggestions? I've developed a work around. But, I would prefer to have the motor stop at 0.

Code: Select all

    // Back up to the long line.
    SetSensorColorFull(S3);
    ResetRotationCount(OUT_B);
    Wait(10);
    RampUp(OUT_B, 30, 180);
    until (1 == SensorValue(S3))
    {
        ContinueRun(OUT_B, 30);
        Yield();
    }
    fDistance1 = MotorRotationCount(OUT_B);
    SetSensorColorNone(S3);
    Coast(OUT_B);
    WaitUntilStopped(OUT_B);
    Wait(1000);

    NumOut(0,LCD_LINE2,fDistance1); // distance measured to line
NumOut(0,LCD_LINE3,MotorRotationCount(OUT_B)); // to be moved
    // Drive forward that same distance it backed up.
    RotateMotor(OUT_B, 30, -MotorRotationCount(OUT_B));
    WaitUntilStopped(OUT_B);
    Wait(1000);
NumOut(35,LCD_LINE3,MotorRotationCount(OUT_B)); // residual angle - should be 0.
    // Because the residual angle is never 0, adjust the measured distance by that amount.
    // So, the distance will be from HERE to the line.
    fDistance1 -= MotorRotationCount(OUT_B);
    NumOut(70,LCD_LINE3,fDistance1); // New distance to line

WaitUntilStopped is a routine I wrote, copied from John's code in the RampUpRampDown routine:

Code: Select all

void WaitUntilStopped(byte output)
{
    // Wait until the motor has stopped turning.
    long rc = MotorRotationCount(output);
    long oldrc = rc+1;
    while (oldrc <> rc) {
        oldrc = rc;
        Wait(100);  // adjust this wait time to see what impact it has on accuracy.
        rc = MotorRotationCount(output);
    }
}

Is the encoder used by RotateMotor somehow disconnected from the value returned by MotorRotationCount?

[h-g-t]

Presumably, because the motor is set to coast, the momentum of the robot keeps it moving and the motor turning.

Have you tried setting it to brake? You can always set it to coast or off once movement has ceased.

[pepijndevos]

I don't know, but you could try to supply a badasss D value to the PID controller of the motor, or use absolute rotation encoding, which I heard is more accurate.

[mcsummation]

Presumably, because the motor is set to coast, the momentum of the robot keeps it moving and the motor turning.

Have you tried setting it to brake? You can always set it to coast or off once movement has ceased.

It is set to coast, so it doesn't jerk to a stop. Then, the code waits until the rotation stops, then waits 1 second. By then it should be stopped. Going back, it does the RotateMotor, then WaitUntilStop, then waits another second. Methinks the robot/motor is actually not moving before I read out the rotation sensor.

I'm not trying to be a smart aleck. I just think I've done what's reasonable to get the thing stationary before doing things.

I've done this testing because it wasn't doing the right thing. This video shows the process. It's the first "back to the line" that has the problem. It has to come out to the original starting point or the correction calculation on the other end doesn't work right.

Edit: I put in an Off(OUT_B) after the motor had, supposedly, come to a stop. I did this on both ends. It appears it now has a very small residual angle - less than 3 degrees, usually 1. So, my compulsive "easy start/easy stop" appears to have been the culprit.

[afanofosc]

The firmware does not use MotorRotationCount for tachometer limited movement. It uses MotorTachoCount. You may want to output both to the screen to see if they differ.

RotateMotor, by default, will not return until the motor is completely stopped so I don't really understand your code. A custom function instead of RotateMotor may be better for your particular application. You may want to examine a decompiled .rxe from the NXT-G program that Philo wrote to see how it uses the setout opcode to control the motors. It is not the easiest thing to sort out but I have great confidence that you could figure it out. You might also check with Ron McRae who, I believe, has an NBC implementation of the Move block (which he created from a decompiled NXT-G program).

If you want to look at the firmware code for motor control you can find it in d_output.c and d_output.r in the enhanced NBC/NXC firmware source code repository:

http://mindboards.svn.sourceforge.net/v ... c?view=log

http://mindboards.svn.sourceforge.net/v ... r?view=log

See also the cOutputCtrl function in c_output.c file for a better understanding of how the values you write to the output module IOMap structure determine what the output module does with the motors:

http://mindboards.svn.sourceforge.net/v ... c?view=log

John Hansen

[mcsummation]

h-g-t nailed the problem. I had coasted the motor, waited until it stopped, but did not brake the motor. It appeared to drift some, even after the long wait, because of the weight of the robot. I put an Off immediately after the WaitUntilStopped and the error went to something very small, now typically +/- 1, which would be in the margin of error.