Dead reckoning and voltage questions.

[todda42]

Hello all. I've searched around here and found a few posts dealing with what I'm after but nothing that dealt with it exactly. This is my first post and hopefully I'm not jumping in and asking about something that has been covered to death. I recently finished my first season coaching a new FLL team. I had no previous experience with Lego Mindstorms until we started on our project. I am not a stanger to coding, but I had never used NXT-G. I was very suprised at how greatly battery voltage affected the outcome of the program. Many of our programs relied on dead reckogning. It took me the longest time to figure out that the reason the program performed differently each time was the battery voltage. I had assumed since I had told it to move x degrees, it would move x degrees everytime regardless of voltage. Actually, turning is the very worst; as the volatge dropped, the turns all became progressively tighter. Once I figured out that volatge was the culprit we tweaked our programs for a target voltage and manipulated alkalines in and out to keep it there. This worked fairly well, but seems like a clumsy way to go. Obviously using sensors would be prefered, but this wasn't always an option. I'm curious if there is a difinitive thread or FAQ dealing with this issue? Is there a better way to program for dead reckoning? I saw some posts that mentioned using a motor block for each motor is prefered. Why is that? After finding the voltage problem I had hoped you could do some sort of case statement in software that would allow different turns based on voltage, but from what I know of NXT-G this doesn't seem possible. Any help on the subject of how to achieve the most accuracy when doing dead reckoning would be very appreciated.

Thanks,
Todd

[h-g-t]

If you need consistency, rather than maximum power, you could read the battery voltage and adjust the motor power % to suit.

In NXT-G you can use Guy Viv's battery block or BatteryLevel() in NXC.

Both return the current battery level in millivolts (i.e 7200).

Since the battery level is dropping all the time, you could decide on a reference voltage less than the maximum, say 7000mv. That is typical of a set of rechargables when run down.

motor_power = 100 * reference_volts / BatteryLevel(); // Factor down voltage
if (motor_power > 100) {motor_power = 100} ; // Must be <= 100

This would return the same power output as the reference value until the battery dropped below the reference.

This should work for the motors but not necessarily anything else you connect to. The pcm output means that it still puts out the available voltage (up to 9v) but for longer or shorter periods.

Don't understand why you are getting fewer rotation as the battery level drops though, my experience is that I always get the right number of turns, it just takes longer as the battery runs down.

The NXT monitors the number of turns to keep it correct, I usually use ResetRotationCount(OUT_A); or OffEx (OUT_A, RESET_ALL); to reset the motor counters before making a move.

[mcsummation]

I've been working on the programming of a dead reckoning robot - http://www.philohome.com/odin/odin.htm - (his robot design, my program). Because it always uses motor rotation, it seems to me to always get the same distance traveled, regardless of the battery voltage, all the way down to where I get the "Low battery" warning. Now, granted, this robot does not use 2 motors running at different rates to turn.

[aswin0]

As suggested above you better use the motor encoders to steer accurately. There are motor sensors in NXT-G that give rotation back.

[wrutiser]

Assuming you are working with the NXT-G visual environment, you may be able to compensate for the battery voltages effect on
turning by setting the steering via a wire to the motor hub.

I ran a bunch of experiments in an attempt to relate turning circle diameter to the steering setting but the data wasn't consistent. I didn't think of battery voltage. For one experiment, I recorded the wheel counts before and after a turn. The outside wheel was quite repeatable, the inside wheel much less so.

[todda42]

Thanks for the replies. I know it sounds counter intuitive, but if you have a NXT-G move block and you use the slider to control a turn, the turn will get sharper as the voltage gets lower. For FLL you are limited to stock NXT-G so I can't use any of the mentioned add-ons for FLL, but I can for my personal use. For the turns in question I have been using a motor block set to degrees and then set the slider for how sharp I want the turn to be. This is using two motors controlled by one block as motors B & C.

Todd

[pepijndevos]

I don't know if NXT-G synchronizes the motors when steering, but I can't think of anything that would cause different turns depending on the voltage, when relying on the tachos in the motors.

If that is the case, maybe you could brake one wheel and steer with the other using degrees?

[hassenplug]

Thanks for the replies. I know it sounds counter intuitive, but if you have a NXT-G move block and you use the slider to control a turn, the turn will get sharper as the voltage gets lower.

Todd, thanks for spending your time to coach FLL. (from a fellow coach) One fun thing about robotics is the interaction between hardware and software. This can provide quite a challenge when you go searching for a solution to a problem like this.

There are many things that can affect how a robot moves & turns. Consider this situation: when the batteries are strong and the robot makes a turn, the wheels can attempt to turn very fast, causing them to slip a little. As the batteries get lower, the motors no longer have the power to spin (slip) the wheels. The end result is the robot will travel a greater distance in the second case.

I think that behavior would be consistent with what you're seeing, right? So, it's actually a hardware issue. Evidence of this would be little pieces of rubber on the table.

A few things to have the kids play with (between now and next season):
1) Speed of the motors
2) Distance between the drive wheels
3) Balance of the robot
A) Mass between the wheels
B) Weight on the drive wheels vs on caster/slider wheels

Hopefully, that gives you something to work with.

Steve