# load wheel diameter & wheel base width
# should there be a problem doing that then save the current default configuration
try:
self.load_robot_constants()
which is called when a user instantiates an easygopigo3.EasyGoPiGo3 class object:
So there is the question to track down: “Does Bloxter use a GoPiGo3 interface / driver that loads the config file?”
I don’t know anything about Bloxter, but if it is possible to see the underlying code generated, perhaps you can see if it is instantiating an EasyGoPiGo3() python class via import easygopigo3 (easygopigo3.py) or import GoPiGo3Scratch (GoPiGo3Scratch.py) ?
Which then begs the Musical Question: Where is it? Can I simply copy over my existing calibration data from R4R?
Oh, another thing about calibration. . . . .
I was reading another post about this guys robots, some of which had a noticeable “skew” to one side or the other, and another poster talking about the accuracy of the calibration. (IMHO when you need decimal precision in robot positioning, maybe the GoPiGo isn’t for you? )
Examining the wheels, motors, encoders, etc - I noticed that there was a definite “step” in the motor’s travel caused by the field magnets, armature, and magnetic flux paths - and there were six distinct steps.
Oooh! Cool beanies! I discovered something new to share!! (Not that a 60° rotary step at 120/1 would amount to a hill of beans. . .)
Then. . . . Well wadda ya’ know? Good 'ole @cyclicalobsessive beat me to it in one of his many - very intelligent - posts. I guess I gotta get up earlier in the morning if I’m going to have any chance against him!
Au contraire! This is the secret of the known universe. Six times one-twenty divided by two makes two pies. (And that hill of beans is only 0.290 mm, but you will always be fed two hills of beans.)
As to your other question - “Your mission, should you choose to accept it, …”