regulation time

First experiments

Regulation time, in the NXT firmware, is the time interval at which the firmware checks the motor speed and change the output power. The LEGO firmware use a 100 ms regulation time, this means that it control the motor speed 10 times a second.

That is not much, at maximum speed, the NXT motor can turn 100 degree in this interval! Therefore, I made a modification in the firmware to use a smaller regulation time: 10 ms. This results in much more reactive regulation, with less oscillation.

I tested this with the RotateMotor NXC function and default NXC PID parameters. This function applies the requested motor power until the limit angle is reached, then it tries to stop the motor by activating speed regulation at speed 0. This means that in the following graphics, speed regulation is only activated after the red line (tacho count) reached the cyan line (limit).

Here is NXC line:

RotateMotor (OUT_A, 100, 360);

Here is the resulting motor movement with regulation time at 100 ms:

The green line shows the power applied to the motor. The steps show the 100 ms regulation time. Now with regulation time at 10 ms:

This clearly shows that lower regulation time gives better motor regulation. This is also clear without measure: Video with 100 ms regulation time, Video with 10 ms regulation time.

Also, having a shorter regulation period permits to have higher PID coefficients and therefore faster response.

So why did LEGO choose a regulation time that long? If you look at firmware sources, you see that the same interval is used for speed control. This means that if no other change is done, regulated speed can go from 0 to 10 instead of 0 to 100. This would be a big loss of granularity. Therefore, to reduce the regulation time, the speed computing should also be changed.

Impact on another regulation method

I am also working on a new regulation method where the motor position is always controlled by a position regulation, and a smaller regulation time is a must. Here is this new method output with regulation time at 100 ms:

And now at 10 ms, much better:

Now with speed regulation

The speed unit used in firmware is degree per 100 ms. In the original firmware, this is done by updating the current position every 100 ms, by adding the current speed.

To reduce the regulation interval, current position should also be updated more often, using the same period than the regulation. The chalenge here is to keep the same unit (degree per 100 ms) and the same control interface. This means that the speed can no longer be considered to be an integer (for example, 45 degree per 100 ms translates to 4.5 degree per 10 ms).

Here is the original algorithm:

on regulation update:
    add speed to current position

Here is the new algorithm which keeps fractionnal part in another variable (here, the number 100 is the old regulation time, on which speed unit is based):

on regulation update:
    add speed * regulation_time / 100 to current position
    add speed * regulation_time % 100 to fractionnal part
    if fractionnal part > 100:
        add 1 to current position
        substract 100 to fractionnal part
    else if fractionnal part < -100:
        substract 1 to current position
        add 100 to fractionnal part