The documentation and software for GoPiGo3 is built around the following:
- Wheels are “nominally” 66.5 mm
- Motors have a 1:120 gear reduction ratio
- The magnetic encoders are “incremental” type (can tell direction of rotation but not absolute position)
- The encoders output 6 counts per motor shaft revolution
- Both the GoPiGo3 and EasyGoPiGo3 APIs read the encoder hardware in encoder counts
- All GoPiGo3 and EasyGoPiGo3 APIs communicate in whole integer degrees (2 encoder counts)
For drive_inches() in the distances 21, 42, and 63 inches, my GoPiGo3 will consistently under-shoot the distance by 4%, day in and day out (around 2.5 inches in 5 feet).
My GoPiGo3 can be “calibrated” to drive with an “drive-to-drive consistent” 0.2% accuracy, by decreasing my_EasyGoPiGo3_instance.WHEEL_DIAMETER by 4%, at the start of the day (1/8 inch error after ten repetitions of driving 5 feet).
My measurements have also shown that a single calibration can achieve a “session and session-to-session consistent” 0.8% accuracy (1/2 inch error in 5 feet, with 1/8 inch drive-to-drive repeatability).
I am not complaining! On the contrary, this result has elevated my pleasure in owning a GoPiGo3 based robot . I feel a desire to learn how to use “smart” programming to create reliable robot behaviors.
Having a degree in Mechanical Engineering, and 50 years experience with motors, sensors, electronics, and software, I am aware of some of the opportunities for variance between a system design and the reality of the commercially viable product. I wish I could determine what is the mechanism that requires “fooling” the system with a 4% smaller wheel diameter than my actual measured wheels. (My wheels measure 66.5 and 66.8 mm at their largest point, and the value that achieves the best accuracy is 63.8 mm.)
Summary: The GoPiGo3 achieves very impressive drive-for-a-specified-distance accuracy.
My test code is on github: wheelDiaDriveTest.py