Mindboards

I have made comparison about regulation time in NXT firmware:
http://ni.fr.eu.org/lego/regulation_time/

I still need to change the speed computation algorithm to be able to activate a smaller regulation time as default.

Wow, the difference is staggering! Nice bit of research

- Xander

Hi,
Interesting. I'm not very familiar with the implementation of the PID controller in the firmware (reading the Lego code tends to give me a headache!), but here are a couple of random thoughts based on your results....
1. The new output looks to me like it is over damped. For an ideal PID controller you would expect some amount of overshoot.
2. Have you tried the higher sample rate when using very slow motor speeds? Depending upon how the controller works the number of tacho counts obtained when you increase the sample rate may be so small that you can no longer get good readings for things like the differential term.

Andy

gloomyandy wrote:Interesting. I'm not very familiar with the implementation of the PID controller in the firmware (reading the Lego code tends to give me a headache!), but here are a couple of random thoughts based on your results....
1. The new output looks to me like it is over damped. For an ideal PID controller you would expect some amount of overshoot.

The graphs show regulation with the default NXC PID parameters, they can really be increased now that regulation time has been reduced. Unfortunately, PID parameters range is too small (255 is maximum value, divided by 32 in firmware (why?!?)).

gloomyandy wrote:2. Have you tried the higher sample rate when using very slow motor speeds? Depending upon how the controller works the number of tacho counts obtained when you increase the sample rate may be so small that you can no longer get good readings for things like the differential term.

I just tried OnFwdReg(OUT_A, 1, OUT_REGMODE_SPEED) and it looks nice. I suppose this is not a problem because the differential is done on position error (even in original firmware), not speed error.

Anyway, I will ask for help to find if people are having problems with the shorter regulation time.

Indeed, 100ms per iteration is really slow! Even a simple control loop in NXT-G can execute over 10x this fast. This explains how the simple go-straight My Block that my FLL team made this year, which is very simple and P-only (not PID), seems to outperform the standard Move block on robots of all types that we have tried (e.g. all wheel sizes) without even tuning it. So, another option is always rolling your own motor sync.

-- Dave

very interesting !
Do you want to test with others firmware (nxc, robotc, lejos) ?
Alban

The leJOS regulation loop already runs with a sample period of 4ms...

Andy

schodet wrote:[
Unfortunately, PID parameters range is too small (255 is maximum value, divided by 32 in firmware (why?!?)).

Very interesting. Seems surprising that Lego didn't find this improvement during the work they did to increase the speed on the 2.0 firmwares.

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?

Ron.

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?

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.

John Hansen

schodet wrote:I have made comparison about regulation time in NXT firmware:
http://ni.fr.eu.org/lego/regulation_time/

While I've never come across this regulation time and other firmware internals, I've made some tests and graphs myself. Lots of pictures in here: http://www.mindstorms.rwth-aachen.de/tr ... MotorTests
If anybody needs more details to a picture, feel free to ask.