New GoPiGo Pi B+ Dexter Raspbian Speed Difference with Older GoPiGo Pi B

We just bought two of the new GoPiGo 3 Pi 3B+ that shipped after the long wait when they were out of stock.
The standard speed of 300 on both the new Pi3B+ with Raspbian for Robots is significantly slower than a couple of 3 year older GoPiGo 3 with Pi3B rev1.2. turn_right(90), turn_left(90), spin, etc.
The older ones are pretty accurate without any calibration, the new ones aren’t even close.
Same Python3 scripts, all running updated current, recently installed versions of Raspbian for Robots, all batteries charged, switched batteries, checked encoder positions.


The new GoPiGo3 have 16 tick per rev encoders where the old had 6 ticks per rev.

The latest /Dexter software checks the serial number of the red board for “new GoPiGo3” and configures a JSON file appropriately. Performing the wheel diameter and wheel base calibration with the latest desktop control panel application will catch any new GoPiGo3 that aren’t in the 16 tick SN list.

Suggest running the desktop software update application and then rebooting and run the desktop control panel application.

BTW official support is now only via email to

@mitch.kremm or @cleoqc. May pop in here sometimes


I appreciate your quick reply. I did run the update again. No changes
Interestingly, the GoPiGo Calibration Panel doesn’t work. The GoPiGo runs Python 3.5. The panel py code uses f-strings, which weren’t used until Python 3.6.
I edited the code so it would run. It shows both of the new GoPiGo’s running at 6 ticks. I ran the calibration on both models, they both go the correct distance and spin. The new ones do it in half the time. I will email support.


If you need a real quick fix, I documented some code that will set the correct values after the instantiation:

Those Wheel Dia and Base are the calibrations for my “new GoPiGo3” on a smooth wood floor at 150 DPS. I run my bot at 150DPS when I need repeatably accurate turns, thus the set_speed(150) command; the key change is the ticks per rev and ticks per degree lines.


You could also try putting/editing:


{"wheel-diameter": 66.5, "wheel-base-width": 117, "ticks": 16, "motor_gear_ratio": 120}

The latest loads that file if present and sets the ticks per rev and ticks per degree correctly. I usually chmod 777 the file.

Line 354 of


As I remember, the new GoPiGo motor encoders have more “ticks” per revolution than the old ones, and there is a parameter in one of the basic include files that needs to be modified to work with the new encoders.

Otherwise, the robot will move slowly.

Let me see if I can find the reference for you. . .

Oh. . . @cyclicalobsessive replied before I was finished with the information I was talking about.

However, posting here first is still a good idea.


  1. Those of us who lurk here often do things and figure stuff out first.  Sometimes, depending on the issue, we might know something before the official channel does.

  2. While we’re on that subject, @cyclicalobsessive is a particularly excellent fountain of wisdom here and what he doesn’t know probably isn’t worth knowing.

  3. The Modular Robotics staff is both competent and responsive, but since the merger they’ve been a bit busy.  Add the pandemic into the mix and things get even crazier.  No fault of their own, but it just might take a little longer for them to get back to you.

  4. The other side of this is that there are a few of us who lurk these forums regularly.  It’s a better than even money bet that one of us will get back to you relatively quickly.  If we know, we’ll tell you.  If not, we’ll “@” in the person who is the official expert.

The Modular Robotics e-mail address is there for you to use, so use it if you wish as that’s the “official” support channel.  However, you may we’ll get a faster response here.

1 Like

I tried this and the other method you mentioned earlier. Both had the same results. The script may or may not execute. The wireless indicator light on the Red board will turn off when the script stops. As soon as I remove either method, the script executes without an issue.
My other GoPiGo roams around the house where ever it wants. Without the modifications, the new GoPiGo wanders around the house just fine, just very slowly.


Wow - that is mystery kind of behavior.

If you have the patience to try making sure you are using the latest gopigo3 and easygopigo3 modules, it would be interesting for you to download these two files to the directory of one of the scripts you want to test with, and execute the script from that directory so that it does not use the site-packages version which must not be the latest if the two methods did not change the behavior.

In the directory where your test script resides:



python3 <>

Please remind me,

Which version of Raspbian for Robots are you using?

Are you using Buster or Stretch?

Have you done an apt-get update and apt-get update on your 'bot?

1 Like

V 10

This version of Raspbian was modified by Modular Robotics on the Stretch Raspbian Build.
This version was updated on 17th of October 2020.
Start: Fri Oct 8 22:43:03 MDT 2021
End: Fri Oct 8 22:52:50 MDT 2021

I have not done an apt update and upgrade. Is that a recommended practice? The directions that I have seen say to only use the DI Update.


I forgot this, the script did run correctly once.


You may wish to try Buster without the Dexter upgrade.

Upgrading Stretch should not be an issue. Upgrading Buster may, or may not, bring in some regressions.

There were some, but that may have been taken care of - I haven’t had much time for my own 'bot recently as I have been working on a modification for the new batteries to make the charge indication work better.

Try it without, clone the SD card using the card duplicator, then try the upgrade.

1 Like

Jim, the issue is not the OS, it is that the version of the python2 and the python3 site-packages do not have the new GoPiGo3 serial number check and the encoder tick handling in the gpg3_config.json file.

I do not understand why performing the desktop Software Update did not update the site-packages, but my feeling is to keep the OS constant and only investigate the DI software.

(Performing the OS update at one point broke my sound output and text to speech, so I am very cautious with that.)


I appreciate everyone’s help. I figured it out. I was using Thonny to test and run the scripts. That always worked fine until the new GoPiGo’s. I put the json config file back, ran the scripts from the terminal, both of my robot buddies are now happily roaming around!
Thanks again!


Yeah! Great news. Hope to hear more about what your robots are up to after they “get out of quarantine”


I am a Computer Science instructor at Western Nebraska Community College in Scottsbluff, NE.
These are being used primarily for 4 students working on a NASA student fellowship this academic year. (and of course for my entertainment.) We are working toward streaming video, humidity, temp, barometer, air quality, etc sensors, GPS, etc. I bought a bunch of Dexter and Grove Sensors to work with. We built up our GoPiGo fleet over a couple of years, which is why we have some different models. We bought two of the new GoPiGo’s this year.
I do have to occasionally take time off from playing with my robot friends and do some teaching.


I will be very curious to hear how it goes with your I2C sensors. I have banged the bus hard with multiple I2C sensors and found soft failures (catch with try/except) must be tolerated, and occasionally hard failures that require full power down cold boots to clear (around 1-5 Million transfers, if detect sustained “Err no 5” will need to SMS someone to cycle the power!) Dexter/ModRobotics has not seen the hard failure errors - only I have.

BTW, If any of the sensors require clock-stretching I2C they must be connected to the AD1 or AD2 ports, not directly to the I2C sockets.

Also, you may want to have folks search this forum for tips on the Grove sensors that do not have exact match Dexter examples. I remember some DHT sensor questions and GPS sensor questions, but not the specifics.



AFAIK, Thonny defaults, out of the box, to Python 2 whereas Geaney defaults to Python 3.

Part of the issue might be the age of the operating system in use - if you copied directly over from the old systems, that might be a problem.

As a general rule, I recommend using the Latest-and-Greatest OS; Raspbian for Robots buster for advanced use and GoPiGo OS for less advanced students.

Here’s a thread I started.  It’s both long and gnarly, but there’s a lot of effort and research there if you are interested.

Good luck with your students and your 'bots!

Don’t forget to post about what’s happening!


The Raspbian for robots Buster is listed as being experimental](Download Dexter Raspbian for Robots from
Is this what you are suggesting I use and what you are using?

1 Like