Mindboards

Is it just me, or have the two mindstorms education kits I've worked with been defective?

Both of them have had "problems" with the battery. While it charges fine, the robot always acts "hyper" when the battery is fully charged. That means the motors will all run a good bit faster when it is fully charged. For me, I'm testing the robot most of the day trying to fix all the bugs, and that means the battery has a chance to run down. With the final product, I want it to be going a certain speed and it can't be going too fast. But if I change the motor's power in the program when it's fully charged, it'll be going too slow when the battery level is down to about 8.5%. So, as a review, when the battery is fully charged the engine goes too fast. The only way to solve it is to run the battery down to 8.5%, and to work with it at that level, because that's where it was when I stopped programming for the night. But then again, the engines will go too slow at, say 4%. Also, the motor has to be going fairly fast, because it's powering a turntable which is kinda top heavy. I'm using the rechargeable lego battery.

I guess I just want to know if anyone has experienced this before and if there's any way to fix it.

legostormrobot wrote:Is it just me, or have the two mindstorms education kits I've worked with been defective?

Both of them have had "problems" with the battery. While it charges fine, the robot always acts "hyper" when the battery is fully charged. That means the motors will all run a good bit faster when it is fully charged. For me, I'm testing the robot most of the day trying to fix all the bugs, and that means the battery has a chance to run down. With the final product, I want it to be going a certain speed and it can't be going too fast. But if I change the motor's power in the program when it's fully charged, it'll be going too slow when the battery level is down to about 8.5%. So, as a review, when the battery is fully charged the engine goes too fast. The only way to solve it is to run the battery down to 8.5%, and to work with it at that level, because that's where it was when I stopped programming for the night. But then again, the engines will go too slow at, say 4%. Also, the motor has to be going fairly fast, because it's powering a turntable which is kinda top heavy. I'm using the rechargeable lego battery.

I guess I just want to know if anyone has experienced this before and if there's any way to fix it.

Umm, this is normal. When the battery is fully charged, just off the charger, your battery voltage will be significantly higher than after a couple of hours of use. You can use a software PID loop to help the motors maintain their target speed, but as the batterys get lower that will be less effective.

I too have seen this problem, with both the older gray batteries and the new white batteries. I'm building
dancing robots, and between motor variations, and battery type and charge variances, it is hard to keep
the dancers in sync. You don't mention what language you're using. In NXC, you can read the battery voltage.
I read the voltage at the start of each run, but currently just display it to the screen. I find the first run
after recharging is the most unpredictable. After that I get many runs that are consistent, so, for now, it is
not a major problem.

Also, I think there may be some variation in sensor response right after recharging, although I have not
done any controlled experiments to confirm this. It may just be sensor variation between robots. Has
anyone seen sensor (light or color) variation versus battery charge level.

An idea that I'm considering is at the start of the program, read the voltage level, and use this as a
factor, in the code, for motor power. This may prove necessary if I have the robots do a more
complicated dance. I haven't thought this completely through, but it would be something like the
following. Suppose the current code is: motor_power = .8;
new code would be: motor_power = .8 * (fully_charge_voltage / current_voltage);

Yeah, it is normal, the motor speed depends on how much power is left in the battery. It doesn't matter if it is normal or rechargeable batteries, you will run into the same issue.

tabbycatrobots wrote:An idea that I'm considering is at the start of the program, read the voltage level, and use this as a
factor, in the code, for motor power. This may prove necessary if I have the robots do a more
complicated dance. I haven't thought this completely through, but it would be something like the
following. Suppose the current code is: motor_power = .8;
new code would be: motor_power = .8 * (fully_charge_voltage / current_voltage);

In my experience, the voltage tends to higher than it actually is when the NXT have been turned off for a while. After a little bit of use it falls to the 'real' voltage, which could trick your program if it only measures at the beginning.
I also suggest the use of a PID controller and then use the worst performing case to be the target. The PID controller will try to change the motor power to keep the target speed, without making assumptions on how for example battery voltage affects the speed.

I select a lowish battery power to suit the type I am using, usually about 7 volts for NiMH cells.

I then factor the applied voltage % by measuring the actual voltage and comparing it with the reference voltage (relay volts in this case) -

"relay_power = 100*relay_volts/BatteryLevel(); // Factor down voltage
if (relay_power > 100) { relay_power = 100}; // % has to be <=100 "

This ensures that the reference voltage is used until the battery drops below that value.

This is not exact because the NXT uses PCM instead of analogue voltages, but it seems to work quite well.

I'm using NXT-G. I've done a lot with it, and I've never seen anything that reads the battery level. Otherwise I would use it to control the motor power... I'll just program it for use with full power and recharge the battery every once and awhile. Looks like I should try to get into NXC!! Is there a specific program to use to program with it?

Oh, and also, the computer software doesn't give me an accurate reading of the battery level. It is almost ALWAYS in the 8.3-8.6 range, even after fully charged or even when used for a LONG time.

In NXC the current battery level (in millivolts) is returned by BatteryLevel().

Level of 8 volts is returned as 8000.

For NXT-G there is a myblock created by Guy Ziv years ago which does the same thing, copy attached.
Found this as an example of how it can be used.

Hey all,

Battery voltage is different than battery power. Battery voltage does not decrease lineally as your battery is used up, and is dependent upon battery chemistry. You can read the voltage of the battery, but as certain motors turn on/off and draw more or less current, this will fluctuate the battery voltage, and this fluctuation can vary depending on how much charge is left in the battery cells. In general, the voltage of a battery cell remains fairly elevated and then drastically drops off when the battery is nearing depletion. Since this is an unreliable way to keep track of battery life, a lot of battery operated devices use what's called "coulomb counting" or other ways to determine battery sate of charge levels (SOC).

I'm not too sure what the LEGO "Check battery level" returns, but I assume it employs a more advanced technique to battery level monitoring than just reading the voltage levels. Using this feature is a good way to allow your NXT to understand its state of charge. The problem is that LEGO motors usually run in what is called "open loop" - where the NXT does not pay attention to the motor position.

Inside the LEGO NXT, there are rotary encoders which operate similar to the ones described here:
http://www.robotappstore.com/Robopedia/Rotary-Encoder

These encoders allow the NXT to keep track of the motor angle, but only when you program it to do so. This is evident when you select the "degrees" selection in the pull down menu under duration. When you regulate two motors together, the NXT is also using the information from these encoders to keep track of each motor's position and pair the two together. Without these selections however, the NXT is not keeping track of what the motors are actually doing, and thus remains "open loop". The only way to properly solve this battery / speed issue is to incorporate an aspect in your program that keeps track of motor position and adjusts the speed, or power based on this feedback.

One other idea is that you could build a "calibration" procedure into the beginning of your program that times the speed of a test motor movement, and then adjusts the power. I am not familiar with any easy way to accomplish a true PID loop (as mentioned above) with the NXT, however maybe someone could shed some light on that.

Hope this helps!