Battery life of "idle" NXT?

[soylentred]

I'm looking to make a robot that basically sits and waits for input. For example, if the only sensor plugged in is the touch sensor, and assuming the unit has standard 1.5v alkaline batteries (or lithium), how long could it last?

I'm thinking that the highest power consumption might be the ARM7 processor, unless the chip itself has some kind of idle or sleep function built-in. I wasn't able to find any power consumption specs of the ARM. Also, the screen also consumes power, but again I'm not sure how much, and whether displaying nothing on the screen makes any difference.

Any ideas?

[nxtreme]

I pulled out my multimeter and did some tests for you. When first turned on, the NXT uses between 60-80 mA for the first couple seconds. After that, it hovers right around 50 mA (Bluetooth turned off and no program running) or with Bluetooth turned on, it oscillates between 60-90 mA at about 0.8HZ. When moving around in the menu (with BT turned off) the power usage blips up to around 55 mA briefly, then back to ~50 mA.

In other words, the NXT is not at all suited to low power situations. That is to be expected, with that much power under the hood (for a robotics toy at least).

Caution, "chanting and craving" below.

I prefer power efficient microcontrollers, the kind that will run off of the power provided by a couple LEDs (as miniature solar panels) and a couple thousand uF worth of caps as a backup power supply. The kind that will run all year off of three AA batteries, while datalogging temperature and humidity every five minutes. I think that TI is really ahead of the times, including FRAM in their new line of microcontrollers. I just hope the next Mindstorms is at least somewhat power efficient...

[timpattinson]

Try lowering the contrast of the screen, it reduces the voltage used to drive it.

[gloomyandy]

Interesting, some time ago I did some work on the leJOS firmware to reduce power usage. Here is a quote from my mail to the leJOS developer list...

At the moment when you start the NXT with no motors or sensors attached the power consumption is:
With Bluetooth off: 70mA
With Bluetooth on: 90/100mA (it fluctuates)
However if you run a program and then return to the menu program the usage is:
With Bluetooth off: 150mA
With Bluetooth on: 190/200mA

If I run the standard Lego firmware then the results are:
With Bluetooth off: 70mA
With Bluetooth on: 100/110mA

After digging around a little I found the main cause of the higher usage after running a program was the state that we reset the motors to. Basically we currently reset them into brake mode which seems to consume rather a lot of power (even with no motor connected). I would like to change this so that we use float mode. The downside of this is that the motors will turn freely when in the menu rather than holding position. Does anyone think this is a problem?

I've also been looking at changing the firmware so that when we have no runnable thread we put the Arm cpu to sleep. I have also changed the menu code so that it is no longer in a busy wait scanning the buttons. With these changes I get the following power usage:
With Bluetooth off: 50mA
With Bluetooth on: 70/80mA

The figures given above are measured with a (pretty good) fluke multimeter, with the NXT running from a freshly charged Lego battery pack. I assume the lower voltage of this pack may account for the difference in the measurements...

Andy

[nxtreme]

Try lowering the contrast of the screen, it reduces the voltage used to drive it.

I don't know about the LCD driver, but LCDs like the one the NXT has are usually very power efficient. I doubt you would save more than 3-5 mA at best though as I like to say, I'm no EE .


Very interesting measurements, gloomyandy. I must admit that my multimeter isn't as accurate as a Fluke would be, though I do know that my measurements will be accurate to within a mA or two. The measurements I find most interesting are snipped out below.

I've also been looking at changing the firmware so that when we have no runnable thread we put the Arm cpu to sleep. I have also changed the menu code so that it is no longer in a busy wait scanning the buttons. With these changes I get the following power usage:
With Bluetooth off: 50mA
With Bluetooth on: 70/80mA

These coincide fairly well with my measurements, if not exactly. I am running the enhanced firmware 1.31 from the 2011-03-16 NXC/NBC test release, though I'm not sure that'd make a difference. I've always thought it would be neat if the low power modes on the ARM could be used when appropriate, though that would take a lot of work. Thanks for sharing your results!

[soylentred]

The ARM has built-in sleep and other power savings modes. The problem might also be that if a program is running, and it's sitting in a loop, it's probably using 100% of the CPU. Ideally there should be a "wake" method, where the CPU can sleep and if anything comes through an input, it wakes the CPU and other components. This is normal on modern CPU's (think a PC in sleep mode until you press a key), but I don't know if this can be changed via firmware, or whether it's a design issue. On an x86 platform this would be handled by the BIOS.

As for the motors being in "brake" mode, apparently they use some kind of active braking, rather than a simple locking mechanism to lock the gears in place. Maybe they tried that and found it would break too easily when forced?

I think that they were more concerned about the battery life while the device is running, rather than idle. It's not a mobile phone, after all. But unfortunately, we can't have our robots "always on", which would make many designs actually practical (think of a motion detecting robot, or even the automatic toilet flushing robot!)

[soylentred]

I'm not too familiar with electricity maths.... how would one calculate the run hours then? Assuming a good quality alkaline may have up to 3000 mAh at a low drain, is that multiplied per battery, like the voltage?
Has anyone ran a multimeter to check the peak load when running 3 motors at 100% power, along with light and distance sensors?

As much as I'm trying to avoid wasting the money, I may end up having to buy 6 batteries and just test it the old fashioned way

[h-g-t]

Well, 3,000mah is measured in milliamp hours and refers to the worst of the batteries. Once that has died the rest it is game over.

Capacity = times x amps (roughly, since it is non-linear)

So if you are using 100 ma then expect 3,000/100 = 30 hours.
and " " " " 200 " " " " 3,000/200 = 15 hours
and so forth, etc.

Have you thought about using an external mains supply using some form of easily-detachable plug or contacts (magnetic perhaps) which the brick could use whilst idle then simply drive away from when the need arises?

In this context "some form of" means "I have no idea how to do that".

[soylentred]

Well, 3,000mah is measured in milliamp hours and refers to the worst of the batteries. Once that has died the rest it is game over.

Capacity = times x amps (roughly, since it is non-linear)

So if you are using 100 ma then expect 3,000/100 = 30 hours.
and " " " " 200 " " " " 3,000/200 = 15 hours
and so forth, etc.

Have you thought about using an external mains supply using some form of easily-detachable plug or contacts (magnetic perhaps) which the brick could use whilst idle then simply drive away from when the need arises?

In this context "some form of" means "I have no idea how to do that".

So it's not additive? If 6 batteries had 3,000 mah each, it's still 3,000 mah total?

I have looked at the external power supply, but the magnetic break-away sounds interesting. The best would be a "docking station", if you could program the robot to always return to the same exact position...

[linusa]

So it's not additive? If 6 batteries had 3,000 mah each, it's still 3,000 mah total?

It would be additive if you had the 6 batteries connected in parallel. Then you'd add up the capacity, but not the voltage. In most technical devices, such as the NXT, you've got the batteries connected in series. Then voltage adds up, but capacity stays the same. Disclaimer: Rules of thumb, real life stuff like internal resistance and self-discharge comes into play here)