Regulation time

[afanofosc]

I just ran a few simple tests of my OutputOptions and they do not seem to be working. I could have sworn I tested the hold at limit option ages ago and had success with it but either I am misremembering or I did something different back then. Back to the drawing board, I guess.

John Hansen

[schodet]

I also wondered why that divde by 32 was there. When you reduce the regulation time to 10mS maybe the divde by 32 should change to divide by 3.2 (or even just integer 3?) to get similar results?

As this is a position control, I do not think the divider should be change (at least for P and I, I am less sure about D, any expert?)

[schodet]

Do you want to test with others firmware (nxc, robotc, lejos) ?

NXC firmware is almost identical for this point.

I do not known about ROBOTC motor control, this would be interesting.

leJOS seems to come with a really nice motor control.

[schodet]

Nicolas, could you elaborate on what you mean here:

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.

A long time ago I made a change to the enhanced NBC/NXC firmware to put the unused MotorPwnFreq field in the Output module IOMap to use. It stores the regulation ms time (default=100) and it you change its value using SetMotorPwnFreq(val) it will use the new value instead of 100ms. I don't really understand what you mean above so I am not sure if my changes are messing up the speed control or not. How would changing the regulation time from 100ms to 10ms make it so that the regulated speed could only go from 0 to 10 instead of 0 to 100?

In the LEGO firmware, position update according to speed is done at the same time as motor control (here).

This means that if you regulate at speed 54 per 100 ms, you have to regulate at 5.4 per 10 ms.

I have made this change here. This is a work in progress.

(license for lawers)

FYI, as I mentioned elsewhere, I added an Options field to the Output IOMap which lets you specify that you want the firmware to automatically OUT_OPTION_HOLDATLIMIT and/or OUT_OPTION_RAMPDOWNTOLIMIT (at 80% of the limit it switches from RUNNING to RAMPDOWN from the current power/speed value to a power/speed value of zero and when the limit is reached it should stop the motor without requiring any further motor commands and hold the motor at the limit position. In theory, anyway. I went through all that code today with a fine-toothed comb while updating to version 1.31 and it looks like everything is coded right but I could use some help testing to see if it actually works right.

I saw your HOLDATLIMIT and RAMPDOWNTOLIMIT options, but they are not doing what I want (precise control and consign change at anytime). HOLDATLIMIT is really nice to optimize RotateMotor though.

[va-bloom]

I am working on a project where the motor must move to follow certain coordinate profile and the position over-shot with default regulation is a killer.
If either of you guys come up with an improved firmware with tighter regulation, please add post with a link.

Thanks,
VA

[afanofosc]

I am working on a project where the motor must move to follow certain coordinate profile and the position over-shot with default regulation is a killer.
If either of you guys come up with an improved firmware with tighter regulation, please add post with a link.

Doesn't this depend a lot on how you write your program to control the motors? What language are you using? If you are using NXC then you have a ton of options for achieving very good position control/regulation. The firmware is certainly not perfect but the primary factor in how precisely the motors are controlled is how the motor control code is written in a user program.

John Hansen

[schodet]

I am working on a project where the motor must move to follow certain coordinate profile and the position over-shot with default regulation is a killer.
If either of you guys come up with an improved firmware with tighter regulation, please add post with a link.

I have uploaded a work in progress 1.29i-d1d1374 version here: nxt-firmware/binaries that you can try.

It still need tests and I have some improvements on my TODO list (for example, you can not have full power using just the proportional gain, I still need to write about it).

This new regulation algorithm just put the servo at the requested angle. Here is a really simple example program:

Code: Select all

void
PositionRotatePID (long angle, byte kp, byte ki, byte kd)
{
    SetOutput (OUT_A,
               OutputMode, OUT_MODE_MOTORON + OUT_MODE_BRAKE + OUT_MODE_REGULATED,
               RegMode, 4,
               RunState, OUT_RUNSTATE_RUNNING,
               Power, 50,
               TurnRatio, 0,
               TachoLimit, angle,
               RegPValue, kp, RegIValue, ki, RegDValue, kd,
               UpdateFlags, UF_UPDATE_TACHO_LIMIT + UF_UPDATE_SPEED + UF_UPDATE_MODE + UF_UPDATE_PID_VALUES);
}

inline void
PositionRotate (long angle)
{
    PositionRotatePID (angle, 96, 0, 32);
}

task main ()
{   
    /* Turn to 90 degree. */
    PositionRotate(90);
    Wait (1500);
    /* Go back to 0. */
    PositionRotate(0);
    Wait (1500);
    /* Turn to 90 degree again. */
    PositionRotate(90);
    Wait (1500);
    /* Now follow motor B. */
    while (1)
      { 
        PositionRotate(MotorTachoCount (OUT_B));
        Wait (1);
      }
}

[schodet]

I have uploaded a work in progress 1.29i-d1d1374 version...

Here is a video demonstrating the simple test program.

I would be interested to know if you can see the video in your browser, youtube really have complicated term of use... Firefox and Chrome should be able to display it, else, you can use VLC.