# Calibrating 3pi to drive straight without sensor feedback

My 3pi has slightly mismatched motors and setting both motors to move forward at the same speed always causes the 3pi to veer to the right. For example, In a run of 20cm, it can veer as much as 7.5cm off heading. The tires, motor shafts, and running surface are clean and the robot has done this since I pulled it out of the box 2 weeks ago.
The degree to which it veers is not a constant difference between motors, nor is it directly proportional to the speed at which the 3pi is run. So I am not able to compensate for the difference by increasing the right motor speed by a constant offset:

``set_motors(speed,speed + offset); // eg. offset = 10``

I also cannot compensate by increasing right motor speed by a percentage of the current speed:

``set_motors(speed, speed * offset); // eg. offset = 1.08 to increase by 8%``

I will be adding PID control which will allow my 3pi to correct itself and drive perfectly straight with sensor feedback; however, I anticipate the requirement to run the 3pi in a straight line for periods when the sensors do not see anything so it appears my only option is to generate a look-up table with calibration values. The table may provide me with an alternate proportionality (exponential?); although, once the table exists, I would of course not waste cycles with unnecessary math.
I also have a design which will allow me add encoders to the 3pi, but do not have spare i/o pins on this version.
I was hoping the constant voltage to the motors would provide more consistent motion, but of course the veering is only consistent at a single speed. I may also have to create another table to enable accurate 90º and 180º turns at various speeds.
Have others experienced this same issue? Am I missing alternatives to a calibration table?
Thanks,
Z

Hello.

I don’t think you’re missing a simple alternative. In general, going straight is difficult, especially without encoders.

- Jan

I had the same problem. My motivation was a bit different, I wanted to calculate position by dead reckoning while following a line (to solve looped mazes).

There’s no alternative to calibrating the motors. Their speed response is non-linear with the applied speed setting, especially at lower speeds. Once I had them calibrated I found that the distance/speed/time relationship is consistent to within about 1-2%, which is good enough for what I wanted.

I also found the problem you did. I was able to calibrate it out, by adding a “swerve factor” for reach speed range (16 ranges of 16 speed settings each). The result isn’t perfect, but it is good enough. To get a better result you would have to continuously vary the swerve correction in a kind of pwm. At some point life is just too short.

John