Mindboards

ronmcrae wrote: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?

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

afanofosc wrote: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?

afanofosc wrote: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 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.

va-bloom wrote: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.

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 wrote:I have uploaded a work in progress 1.29i-d1d1374 version...