NXT Motor Behavior with different Power Levels

[tcwan]

Hi,

I was experimenting with the NXT Motor on my Tribot using the Lego battery pack. When I tested my NXT motor, I removed the wheel so that it was not loaded. However, I noticed that if I dropped the Power Level to less than 60, the motor will stop turning and emit a high pitched whine. Is this supposed to be normal? I'm wondering if absolute power levels of less than 60 is actually usable on the NXT.

By searching this forum, I found a reference to Philo Hurbain's webpage, the first graph on the page which has a curve in Pink (with square markers) seem to match my observations http://www.philohome.com/nxtmotor/nxtmotor.htm. I can't get the other curves which has linear response for each specified power level.

I should note that this testing was done using NxOS, which does not implement any PID control for the motor, so the power level given to the NxOS motor driver will be the actual value sent to the AVR.

So for correct operation of the NXT motor with different power levels, would a more advanced scheme be needed? What is meant by the term 'Power Control?' Incidentally, what would be the output parameter of a PID controller in this case? Is it Power Level or RPMs?

[Disclaimer, I only have a basic (conceptual) understanding of PID control]

[linusa]

When I tested my NXT motor, I removed the wheel so that it was not loaded. However, I noticed that if I dropped the Power Level to less than 60, the motor will stop turning and emit a high pitched whine. Is this supposed to be normal? I'm wondering if absolute power levels of less than 60 is actually usable on the NXT.

Well, the high pitched whiny noise IS normal. However, with an unloaded motor, I'd have guessed it only occurs for powers < 30 or so. 60 seems high to me (I also did a lot of tests using the LEGO battery pack and no load, but years ago).

By searching this forum, I found a reference to Philo Hurbain's webpage, the first graph on the page which has a curve in Pink (with square markers) seem to match my observations http://www.philohome.com/nxtmotor/nxtmotor.htm. I can't get the other curves which has linear response for each specified power level.

If you can reproduce Philo's curve for unloaded uncontrolled motors, than everything is ok!

I should note that this testing was done using NxOS, which does not implement any PID control for the motor, so the power level given to the NxOS motor driver will be the actual value sent to the AVR.

That explains it. Without "power control" (or "speed regulation", as LEGO calls it), you don't get nice linear "power to speed" behaviour. What you however should get is a linear "torque to power" function, where power is the percentage of the LEGO firmware (i.e. PWM value?). Unfortunately, Philo didn't do a plot for this one.

So for correct operation of the NXT motor with different power levels, would a more advanced scheme be needed? What is meant by the term 'Power Control?' Incidentally, what would be the output parameter of a PID controller in this case? Is it Power Level or RPMs?

Power control, or speed regulation, is a controller which tries to hold a constant speed setpoint. So it will adjust the power level to reach this speed. If you block your motor by hand, power will increase. I wrote a bit about speed regulation here: http://www.mindstorms.rwth-aachen.de/do ... ol.html#18 , which bases on how the LEGO firmware handles this stuff.

So in this case, output is clearly power level, and input is RPM: feedback is RPM (the currently measured speed), and set point is speed (the desired speed).

If you want to experiment with the LEGO firmware: Inside the IOMap there is a register/value called "ActualSpeed". In reality, this is the firmwares applied power level in %. So if you specify 50%, the LEGO firmware might in reality output 55%, or 70% under heavy load. This real power level is what is written to "ActualSpeed".

You definitely need some advanced controller (such as PID) to get a nice constant speed, or a linear "power level to speed" function.

I put some links (you know Philo's already) here: http://www.mindstorms.rwth-aachen.de/tr ... rInternals .

[linusa]

And if you want a visual example, how such a regulation might look, consider this graph: http://www.mindstorms.rwth-aachen.de/tr ... orking.png . Some different units on the y-axis are scaled so it all fits into one plot, don't worry about it.

The motor's current position is in blue, but that doesn't need to concern you. What's regulated in this case is speed (so yes, it's some sort of "speed regulation"). You can see the desired speed setpoint in black with dots. Orange dots is the current speed feedback, measured on the NXT (the thin red line is the same speed, calculated on a computer afterwards and much smoother). The interesting bit is the green line with dots: It's the current power output level. As you can see, it's jumping around wildly, caused by the PID-controller (actually, it's only a PD-controller), to get the desired speed!

Another example is this picture: http://www.mindstorms.rwth-aachen.de/tr ... Nicely.png It doesn't have the black and orange dots on it, but what's happening is this: During a controlled slow down, I manually grabbed the motor by hand, at about 1.5 seconds. You can see the speed (thin red line) immediately went down to almost 0. The motor controller "realized" this and tried to overcome the load, applied by my hand. It increased the power level from about 50 to ca. 70%. I soon released the motor (about 0.2 seconds later), and the power level adapted again.

[tcwan]

Power control, or speed regulation, is a controller which tries to hold a constant speed setpoint. So it will adjust the power level to reach this speed. If you block your motor by hand, power will increase. I wrote a bit about speed regulation here: http://www.mindstorms.rwth-aachen.de/do ... ol.html#18 , which bases on how the LEGO firmware handles this stuff.

So in this case, output is clearly power level, and input is RPM: feedback is RPM (the currently measured speed), and set point is speed (the desired speed).

Thanks so much! I understood the explanation the first time I read it
Is there a way for me to recommend that this thread be made 'sticky'? Linus gave a good overview of the whole topic with lots of references.

By the way, in John Hansen's book the NXC Quick Reference in Appendix A shows the output functions as accepting Power levels as a parameter.
What is the mapping between the specified power level and the speed (set point)? Is it arbitrary?

[linusa]

By the way, in John Hansen's book the NXC Quick Reference in Appendix A shows the output functions as accepting Power levels as a parameter.
What is the mapping between the specified power level and the speed (set point)? Is it arbitrary?

NXC's motor functions accept "power level in %", interpreted by the LEGO firmware. I'm very sure NXC doesn't modify these values, just passes them on (it all boils down the the firmware opcodes SetOutput, or at least setting values inside the Output IOMap).

If you want to get behind this "abitrary" mapping between power and speed, then look at Philo's plots! If you see a straight line there, then that's your linear function.

In theory, these experiments would have to be done for every single firmware version, but in practice I think the parameters haven't been touched (at least not since Firmware 1.05).

[gloomyandy]

Hi,
You may also want to take a look at the PWM control mode being used. Basically this controls what the PWM driver does during the "off cycle" of the control period. In FLOAT mode the output is not connected to the battery at all, in BRAKE mode it is connected to 0V. This setting has a huge impact on the power curve. I seem to remember that in FLOAT mode the minimum power required for the motor to start moving is approx 50% (possible more depending on the motor), in BREAK mode it is much lower, 8% or so. It looks like you are operating in FLOAT mode....

Not directly related to the above, but if you are interested in Lego motor control you may find the following worth reading...
http://www.gloomy-place.com/lejosmotor.htm
http://www.gloomy-place.com/images/lejospid.pdf
These mainly detail the development of the leJOS motor driver, but first also covers some of the characteristics of the Lego driver. Oh and the experimental driver described in the first link is now the released version in leJOS 0.9.0

Andy

[linusa]

Hi,
You may also want to take a look at the PWM control mode being used. Basically this controls what the PWM driver does during the "off cycle" of the control period. In FLOAT mode the output is not connected to the battery at all, in BRAKE mode it is connected to 0V. This setting has a huge impact on the power curve. I seem to remember that in FLOAT mode the minimum power required for the motor to start moving is approx 50% (possible more depending on the motor), in BREAK mode it is much lower, 8% or so. It looks like you are operating in FLOAT mode....

Oh yes, VERY good point and overlooked by me. There's a thesis from ETH Zürich (I think it was with a pre-release NXT version, late 2006?) on the NXT. They compared the affect of the BRAKE bit, and came to this conclusion: BRAKE consumes a bit more power when enabled, but leads to more precise motor movements. That's why I always enable it and I've not used the motors without it ever since.

Not directly related to the above, but if you are interested in Lego motor control you may find the following worth reading...
http://www.gloomy-place.com/lejosmotor.htm
http://www.gloomy-place.com/images/lejospid.pdf
These mainly detail the development of the leJOS motor driver, but first also covers some of the characteristics of the Lego driver. Oh and the experimental driver described in the first link is now the released version in leJOS 0.9.0

Definitely recommended reading, great articles, thanks Andy! Those are already included in my "NXT Motor Internals" link section.

[tcwan]

Hi,

These mainly detail the development of the leJOS motor driver, but first also covers some of the characteristics of the Lego driver. Oh and the experimental driver described in the first link is now the released version in leJOS 0.9.0

Andy

Thanks!
I noticed that LeJOS is released under the MPL. Would it be possible for me to port it to NxOS which is released under GPL?
(Obviously it won't be a direct port).

Edit2: Andy was right. when I toggled the BREAK/FLOAT setting, PWM values worked all the way down to 10%.
However, I'm now confused with the definition: In the Hardware Developer Kit, under the section "Data Sent from the ARM7 Microcontroller",
Output Mode is defined as "Holds the output mode that can either float or break between PWM pulses. 0x00 means break and 0x01 means float".
I checked the motor setting code in NxOS, if it the output mode is set to '1' for the motor, it will work down to 10%.
Similarly, for Stopping, the output mode is set to '1' for the give motor. Is the documentation incorrect?

[linusa]

However, I'm now confused with the definition: In the Hardware Developer Kit, under the section "Data Sent from the ARM7 Microcontroller",
Output Mode is defined as "Holds the output mode that can either float or break between PWM pulses. 0x00 means break and 0x01 means float".
I checked the motor setting code in NxOS, if it the output mode is set to '1' for the motor, it will work down to 10%.
Similarly, for Stopping, the output mode is set to '1' for the give motor. Is the documentation incorrect?

In the Bluetooth Developer Kit, Appendix 2 Direct Commands, for SetOutputState, page 6, it says you have to set bit 0x02 to "use run/brake mode instead of run/float mode in PWM".
Not sure if that helps you, but I always got the feeling that BRAKE is something you "have to enabled", i.e. default off.

[tcwan]

In the Bluetooth Developer Kit, Appendix 2 Direct Commands, for SetOutputState, page 6, it says you have to set bit 0x02 to "use run/brake mode instead of run/float mode in PWM".
Not sure if that helps you, but I always got the feeling that BRAKE is something you "have to enabled", i.e. default off.

Ah, good. That gives me a place to check in the NXT Firmware code
(I'm more familiar with the Direct Command processing part of the NXT Firmware than the other parts).

Code: Select all

In d_output.r:
#define   INSERTMode(Motor, Mode)       if (Mode & 0x02)\
                                        {\
                                          IoToAvr.OutputMode |=  (0x01 << Motor);\
                                        }\
                                        else\
                                        {\
                                          IoToAvr.OutputMode &= ~(0x01 << Motor);\
                                        }

So, from this I believe that the description in the Hardware Developer Kit is incorrect, the definitions have been reversed.