Compass_robot and IMU calibration

gopigo3
project
pending
imu

#1

Hi guys at Dexter Industries!

I am currently running into some difficulties with the compass_robot.py example and I’m not sure how to proceed with fixing these errors. I’m using the new raspbian for robots with stretch support and it is a GoPiGo3.

[Errno 5] Input/output error
Rotate the GoPiGo3 robot with your hand until it's fully calibrated[robotControl] thread couldn't be launchedTraceback (most recent call last):


The GoPiGo3 is not yet calibrated  File "/home/pi/Desktop/GoPiGo3/Projects/CompassRobot/compass_robot.py", line 366, in <module>
    Main(trigger)

  File "/home/pi/Desktop/GoPiGo3/Projects/CompassRobot/compass_robot.py", line 347, in Main
    with Input(keynames = "curtsies") as input_generator:
  File "/usr/lib/python3/dist-packages/curtsies/input.py", line 73, in __enter__
    self.original_stty = termios.tcgetattr(self.in_stream)
termios.error: (25, 'Inappropriate ioctl for device')
>>> IMU sensor is not reacheable or kill event was triggered
[orientate] thread couldn't fully start up

Additionally, so I can use calibration outside of compass_robot.py, does the line

compass = imu.BNO055.get_calibration_status()[3] 

(line 119) only return the calibration status of the magnemeter or the entire IMU? if just the magnemeter what is the code for the other components?

Lastly, will there be any problems if I use a second IMU to help reduce static? something the tune of:

imu1 = inertial_measurement_unit.InertialMeasurementUnit(bus = "GPG3_AD1")
imu2 = inertial_measurement_unit.InertialMeasurementUnit(bus = "GPG3_AD2")

#Do things with both later.

I would presume not, but would like to be sure there is nothing in the back end that will muddy this.

Thank you very much!
Jim


#2

Hi @jspagnol,

We’ll have this project tested and then come back with an answer to you. Until then can you tell us more information on how you’ve wired the IMU to the GoPiGo3?

Lastly, will there be any problems if I use a second IMU to help reduce static? something the tune of:

Using a second one is redundant as one IMU is already precise enough to do most of what you want. Probably adding another one will get you even worse performance because you’d need to double the bandwidth and number of operations for such a thing.

Thank you!


#3

Hi @jspagnol,

I used the latest Raspbian For Robots (which is built on Stretch), a GoPiGo3 and a DI IMU Sensor along with Python3. This is what I got:

Now, there’s clearly something wrong with your configuration. Are you certainly using the latest version of Raspbian For Robots? Even if you are not using the latest you can run the following 2 commands and you’ll have everything you need updated:

curl -kL dexterindustries.com/update_gopigo3 | bash
curl -kL dexterindustries.com/update_sensors | bash

Thank you and let us know how it goes for you!


#4

Hi @RobertLucian!

I’ve tried every conceivable combination of which I2C port on the board and on the IMU. I’ve also tried switching out the IMU for others (i have 3 at my disposal atm). So I think it would be at the software level.

I am very sure that I am using the latest Raspbian for Robots and did run the updates with no change.
Having played about with it some more today. Removing the “GPG3_AD1” from the IMU constructor did allow the IMU to connect and calibrate, but still got the following error:

Traceback (most recent call last):
  File "/home/pi/Desktop/CompassRobot/compass_robot.py", line 366, in <module>
    Main(trigger)
  File "/home/pi/Desktop/CompassRobot/compass_robot.py", line 347, in Main
    with Input(keynames = "curtsies") as input_generator:
  File "/usr/lib/python3/dist-packages/curtsies/input.py", line 73, in __enter__
    self.original_stty = termios.tcgetattr(self.in_stream)
termios.error: (25, 'Inappropriate ioctl for device')

Which appeared directly after the text from the “with IMU Sensor” in the picture provided.

I have been attempting to use the Euler readings from it as well. While this compiles and returns values I do get some odd readings every once and a while. Notably values off by 15+ degrees, values over 360 and values that are + or - 2000 which I imagine is some sort of error call?

My final plan in all of this is to use the magnetometer to help compensate for the euler values drifting.

Thank you very much,
Jim