GoPiGo3 Not Driving Straight

My GoPiGo3 robot consistently turns left. When calibrating the straight line distance of 6 ft it makes a large arc of over 90 degrees (1/4 or a circle). If the robot were to drive a distance of about 18ft it would make a complete circle and end back where it started. This is repeatable on all surfaces (carpet, concrete, linoleum, etc.) so wheel slippage is not the issue. I have reviewed the Oct. 21, 2021 GoPiGo3 Documentation and assume a should be able to adjust the left and right wheel speeds to correct this. Hoping someone can direct me to a solution or calibration procedure to correct this.

When using steer command, setting left wheel to 100 and right wheel to 28 makes it drive straight. Also noticed earlier posts with trim command but cannot find that for this version, was it removed?



That’s a huge difference!

I can’t imagine what would cause that aside from:

  • You have two different motor types on the same robot (6 tick and 16 tick encoders), as there are two motor versions.

  • There’s something seriously mechanically wrong.

If you don’t see anything obvious, and if anyone else here doesn’t have a better idea, you may wish to check with

Please let us know what happens if you do.


Is there any way, by simple visual inspection, to determine the motor type - 6 or 16 ticks/revolution?


1 Like

Agree fully with @jimrh suggestion to contact It will be helpful if you can tell them your serial number by running the troubleshooting app or by running the Read_Info example:

$ python3 ~/Dexter/GoPiGo3/Software/Python/Examples/ 
Manufacturer    :  Dexter Industries
Board           :  GoPiGo3
Serial Number   :  BA93EB4F514E3437324A2020FF040B1F
Hardware version:  3.x.x
Firmware version:  1.0.0
Battery voltage :  8.883
5v voltage      :  5.071

Additionally you may want to include a photo of your encoder sensors. They should be close but not touching the encoder disks:

Prior suggestions to folks reporting “Not Driving Straight” issues have included:

  • Be sure the motor cables are inserted fully. (Unplug/reinsert carefully)
  • Check to be sure that the encoders sensors are positioned very close to, but not quite touching the spinning magnet on the back of the right motor.
  • Ensure the wheels are not pushing the spacer into the motor body.

Out of curiosity sake, not to diagnose your issue, if you have a chance I would be interested in what the following report on your bot:


cat /etc/os-release

uname -a

grep dtparam /boot/config.txt


ls ~/Dexter

more ~/Dexter/Version   (file may not be found)

more /opt/Sam_Dev/webapp/version.txt   (file may not be found)

more ~/Dexter/gpg3_config.json   (file may not be found)
1 Like

Thanks for the information all. Verified assembly and checked for any binding issues and everything is OK. Encoder sensors do not touch wheel and are all gapped equally around wheel. Data and S/N information is attached along with some distance and encoder reads while commanding the robot to random distances. The encoder counts are very close to expected values calculated from the wheel diameters.

What I am really looking for is a way to modify source code for now and hard code the motor speeds into the program to finish a couple of assignments. Not ideal but would get me what I need until I have time to do more investigation. I am newer to Python and am not always sure where or how to get the programs doing what I want. If anyone has a suggestion for how to program the .steer function and set to 100 and 28 as the robot drives a specified distance I would appreciate the help. GPG Data_SN
GPG Encoder Experiment

1 Like

Looking at that table there is no good reason for your robot to be swerving so badly, unless you have different versions of motors, or there is something seriously wrong with the 'bot.

Try this:
Change the number of ticks to “6” in /home/pi/Dexter/gopigocfg.json (spelling of name may not be exact, but you will find it.)

See if it swerves to the right the same way and if the speed offsets are similar but reversed.

If that is true, you have a mismatched set of motors.

Then, if this is urgent, get right on the horn with and have them ship you a matched set of motors.

I myself have heard of the “trim” feature but have never had to use it.

Again, the formal support, (@cleoqc), will be able to provide the best help.

How many sensors per magnet are on each wheel?

I PM’d Nicole (cleoqc) and asked her to pop over because you are in a bind and on a tight deadline.

Have you e-mailed them yet?

There may be a way to independently limit the rotational speed of each wheel while the drive-a-distance API is operating.

This program proves the concept, but on my bot it does not stop properly - press control-c if bot is running away or stops but one motor is still humming


#!/usr/bin/env python3

# File:

# Purpose:  test if set_motor_limits() constrains drive_cm()

from easygopigo3 import EasyGoPiGo3

# instantiate bot object
egpg = EasyGoPiGo3()

# set left and right rotational speed limits 
# equivalent to egpg.steer(left_percent=100,right_percent=28)
desired_speed = 300  # DPS  (this is the egpg.DEFAULT_SPEED)
left_limit = 100 # percent
right_limit = 28

left_speed = int( left_limit * desired_speed  / 100 )
right_speed = int( right_limit * desired_speed / 100 )

egpg.set_motor_limits(egpg.MOTOR_RIGHT, dps=right_speed)

# Now try driving a set distance
distance_cm = 200

print("Driving {} cm with L/R limits {}/{} DPS".format(distance_cm,left_speed,right_speed))

    egpg.drive_cm(distance_cm)  # default:  blocking=True
except KeyboardInterrupt:
    print("\nCntl-C detected - stopping bot")


I see your test was in inches - there is a drive_inches() method in the EasyGoPiGo3 class:

def drive_inches(self, dist, blocking=True):
        Move the `GoPiGo3`_ forward / backward for ``dist`` amount of inches.
        | For moving the `GoPiGo3`_ robot forward, the ``dist`` parameter has to be *positive*.
        | For moving the `GoPiGo3`_ robot backward, the ``dist`` parameter has to be *negative*.
        :param float dist: The distance in ``inches`` the `GoPiGo3`_ has to move.
        :param boolean blocking = True: Set it as a blocking or non-blocking method.
        ``blocking`` parameter can take the following values:
             * ``True`` so that the method will wait for the `GoPiGo3`_ robot to finish moving.
             * ``False`` so that the method will exit immediately while the `GoPiGo3`_ robot will continue moving.
        self.drive_cm(dist * 2.54, blocking)

1 Like

This data leads me to believe the issue is not with the ENCODER_TICKS differing. When the bot is driven straight, the encoder counts are equal.

For the steer(100,28) to cause straight path with both encoder counts being equal, the red board is setting the PWM for each motor to the rate that causes both motors to rotate at the same DPS and thus the path is straight and the encoder counts are equal. My guess: the motor power to speed profiles are different, but the gearing and encoder counts are the same.


I would beg to differ.

The bot may be commanded to drive straight, but it’s not moving straight.  In fact, it’s describing a quarter circle.

The six-tick encoder generates only 25% of the ticks per revolution that a 16-tick produces.  (Ok, be picky!  26.67% but 25% is close enough.

Therefore the 16-tick encoder has to move at 25% of the speed of the six-tick encoder to generate the same readings.

(Or, conversely, the six-tick motor has to move 75% faster to generate the same number of ticks.)

Translation:  One wheel driving consistently more slowly will cause the robot to describe an arc when commanded to move straight.

The only other possibility is a serious malfunction of the GoPiGo’s controller.

1 Like

Do we know it was going straight? That wasn’t clear to me. If this is just the distance driven, but it was really going in circles, then maybe @jimrh is right and there are two different encoders. Alternatively maybe a stray motor with different gearing got shipped somehow.

1 Like


As noted above, gopifun mentioned that when commanded to go straight, it describes an arc of about 90° which leads me to the conclusion that the most likely possiblity is a mis-matched set of motors.  Especially since the ratio of the encoder ticks is 3:1 comparing 16 tick motors to 6 tick motors.

A 3:1 ratio would describe an arc when commanded to go straight.  If the ratio of the wheel diameter vs tick ratio is “just right” then it is conceivable that it would travel almost exactly 90° with a 3:1 encoder ratio over the 6’/2m distance.

Of course there could be a problem somewhere else but, (IMHO), the motors are the most likely culprit.

Unfortunately, we do not know how to tell the motors apart by visual inspection.

Ultimately, this is a “Modular Robotics” issue.

Have you e-mailed

If not, do so quickly so they have time to help you.

Let us know what happens.

1 Like

Please clarify- are the table results for straight travel, or curved travel?


Let me rephrase that:

. . . are the table results for travel that you wanted to be straight but is curved as you mentioned in your original post?

Based on the table headings, I am assuming that you requested straight-ahead travel, but the travel is curved anyway.



Sorry I kind of left everyone hanging…things got a little busy. Worked with support and they determined it was the motors. They are sending a matched set with the 6-count encoders.

Thanks again for all the help! This is a great little robot and looking forward to diving in deeper when things slow down a little.


Really great to hear they got it sorted.

So as you understand it, you had one 16-tick motor and one 6-tick motor?


That is what Mod Robotics said it sounded like.


The only thing left is to make sure your bot isn’t on the list of those with 16 tick motors.

GoPiGo_list_of_serial_numbers.pkl.txt (32.5 KB)

This can be opened as a text file.

If the serial number of your GoPiGo is on this list, it will automatically assume you have 16-tick motors.

1 Like

If the user has not run the calibration application to save the correct ticks (and wheel-base-width, wheel-diameter) to ~/Dexter/gpg3_config.json, then …

That file is a pickle serialization - not simple to edit.

(I checked the list, and the OP’s serial is on the list. Wish support had sent two 16-tick motors…)


Never said it was. :wink:

I just wanted to put the guy wise to the fact that he might want to check that.&nbsp: I even sent the file for him to check.  If his S/N is there, then we can worry about editing it.

1 Like

Much easier to just run the calibration, than to

  • write a program that reads the list, deletes a SN if found, re-pickles the list,
  • submit a Git Issue to have that SN removed from the pkl file.
  • and still have to run the calibration program for fine tuning

And the file that actually gets used is apparently “hidden” under ~/Dexter/, I thought it might have been in the site-packages:

install_list_of_serials_with_16_ticks() {
    cp $GOPIGO3_DIR/Install/list_of_serial_numbers.pkl $DEXTER_PATH/.list_of_serial_numbers.pkl