Product Introduction

7. Power Limits
The above calculations of motor power could give values outside the allowed range,
possibly resulting in run-time errors or random motor commands. In general, a program
needs to do something about calculated values that may give unpredictable behavior.
Here’s a sample correction:
To allow spin moves (if the robot is capable), the low limit could be set to -100% (and
midPower is zero). To reduce the top speed, adjust the high limit (and possibly gain).
8. Motor Directions
The above pseudocode samples ignore the fact that most robots have opposite-facing
drive motors. Fortunately most programming libraries offer a single-line function to
always reverse one of the motors. This leaves the programmer free to concentrate on
code logic, without worrying about one motor always running ‘backwards’.
Which one to reverse? Old habits may dictate reversing, say, the right-side motor. But
the better approach is to first determine which motor naturally runs forward. Namely,
giving that motor a positive power value makes the robot drive forward. If it’s the left
motor, then the old habit works fine. But many motor axles run clockwise with positive
voltage, which (on the left side) often runs the drive train backwards. Your code would
need to use all negative values for driving forward.
So, identify which motor runs forward naturally. Use the auto-reverse function on the other
motor. You will save much stress and confusion by making the natural choice, rather than
debugging ‘double negatives’ under pressure. Positive is always forward. Make it so,
Earthling.
Also -- first make sure the declared LeftMotor is truly running the left-side motor. Make a
simple test program to verify this. Seems obvious, but you’d be surprised!