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?
Agree fully with @jimrh suggestion to contact support@modrobotics.com. 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/Read_Info.py
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:
whoami
cat /etc/os-release
uname -a
grep dtparam /boot/config.txt
groups
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)
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.
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 support@modrobotics.com 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.
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
File: test_drive_with_limits.py
#!/usr/bin/env python3
# File: test_drive_with_limits.py
# 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_LEFT,dps=left_speed)
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))
try:
egpg.drive_cm(distance_cm) # default: blocking=True
except KeyboardInterrupt:
print("\nCntl-C detected - stopping bot")
egpg.stop()
print("Done")
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)
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.
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.
/K
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.
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.
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…)
I just wanted to put the guy wise to the fact that he might want to check that. : I even sent the file for him to check. If his S/N is there, then we can worry about editing it.
