heading_robot.py uses the Dexter Industries Inertial Measurement Unit (BNO055 chip)
in IMUPLUS mode (Fusion from Gyros and Accelerometers only, no magnetometers) to
orient the GoPiGo3 robot with respect to the orientation when the program is started as 0 degrees.
cd ~
curl -LJO https://github.com/slowrunner/Carl/raw/master/Examples/imu/di_BNO055/headingbot/headingbot.tar.gz
tar -xzvf headingbot.tar.gz
cd headingbot
Usage:
Mount Dexter Industries Inertial Measurement Unit Point-up, chip to front
Connect IMU to GoPiGo3’s AD1 port
Orient GoPiGo3 to some reference such as floor board joints or taped line on floor
./heading_robot.py
Press arrow keys for shortcut to 0, 90, 180, 270
or enter a direction such as 45, then press return
Watch for robot to complete re-orienting
Check what heading the robot “thinks” it is pointed (IMU heading)
Optionally press “f” key to make robot move forward, press “Space” key to stop
Press ctrl-c to exit
Notes:
Initial orientations will be close to the measured heading,
but eventually will show effect of IMU drift.
IMUPLUS mode is used because the motors, encoder magnets, and indoor magnetic fields
wreak havoc with the IMU in NDOF mode
Bloody Hell!  Right smart job you did there. . .  You do realize that I’ve got my eye on this for after I get my Remote Camera Robot project finished?  I can see that helping hugely with autonomous robot navigation.
Â
Is there a way to change the port?  AD1 is already in use by Charlie’s bumper.
Â
Is there a way to disable the “direction I’m pointing right now is 0° mode?” What if I want true headings?
Â
And did I forget to mention that this is one jaw-dropping piece of work?  I should be a fly on your wall when you’re coding. . .
PORT = "AD1" # Use "AD1" or "AD2" for clock-stretching software I2C
What is true? True North? Not interested. You could use NDOF mode and calibrate, and add your declination - you’re on your own. You could also use DI compass_bot.
Just thought of another way - point him to your true North before you start heading_bot.py
Like I told you before - just bang Charlie into a wall, call safe_resetBNO055(), and that is ZERO! Very stable, doesn’t drift, not influenced by calibration, or clumpy molten magma.
In your case, you have a fixed point of reference - Carl’s dock.  Even if Carl’s dock moves, the dock is always his standard 0 - 0 - 0 reference point.
In my case, there is no fixed “zero” point. I just plop Charlie down on the floor, fire him up, and send him on his way. When done, I bring him back, pick him up, turn him off - (or plug him into ground-power for dev work), and put him away so the granddaughters don’t trip over him.
What I was hoping to do was to be able to tell Charlie to “go West” or “turn 90 degrees”, and have that be what happens.  I don’t expect “west” to be exactly 270.00000 degrees true - if I need that kind of accuracy I have a Dexter GPS module I can hook up to him - but then again, I’m not sure he’s ready to go outside just yet.
What I would like to see is “reasonable” accuracy - if I tell him to make four 90° turns, I’d really like him to end up where he started, not in St. Petersburg or Vladivostok. (or, in a totally different part of the carpet, headed off to who knows where.)  Maybe not decimal accuracy as to absolute direction, but a reasonable repeatability with respect to the four cardinal points and specified turns.  Magnetic variation, deviation, declination, discombobulation and all that? Not so important.  He’s not flying trans-Atlantic. . . .
Then again, maybe I can find a sheet of Mu-metal and make shields for the motor/encoder pairs? Â I wonder, do they need to be grounded to provide magnetic shielding?
Actually, you don’t need compass bot’s complexity. I wish DI had built a layered set of examples, instead of going straight from “read the sensor” to “multiple threads with command and data queues implementing a dynamic stimulus-response feedback loop”.
You don’t know how many times I’ve said that with my project!
I’ve gotten to the point where I can read the status of a plugged in joystick, but I haven’t been able to get the dynamic data yet.  All the online examples do this in the context of writing a game - and the actual “read the dynamic data” is buried under layers and layers of game logic.
The on-line spec’s?  Compared to some of those, DOD MIL-883 specifications read like a third-grade story book!
Spoken like a true software maven!  As for me, the mechanical adjusters for Carl’s eyes would be infinitely easier - that darned remote robot code is going to be the death of me yet!
You can always give up and switch to the “old remote robot” which used two buttons in a phone browser. Left: turn left. Right: turn right, Both: Go Forward.
(or, in a totally different part of the carpet, headed off to who knows where.)  Maybe not decimal accuracy as to absolute direction, but a reasonable repeatability with respect to the four cardinal points and specified turns.  Magnetic variation, deviation, declination, discombobulation and all that? Not so important.  He’s not flying trans-Atlantic. . . .