[Solved] Understand IMU Instantiation

GoPiGo
, ,
1

[SOLVED] The axis remap invokes config-operation modes.

I needed help understanding the initialization process of an EasyIMUSensor object.

Specifically why the chip is configured twice?

pi@Carl:~/Carl/Examples/imu/di_BNO055/tests/instantiation $ ./create.py
create.py: Example instantiating a Dexter Industries IMU Sensor on GoPiGo3 AD1 port.
EasyIMUSensor().__init__() exec
InertialMeasurementUnit.__init__() exec
BNO055().__init__() exec      <-- This is the first configuration of the chip
_config_mode() exec
set_mode(0) exec
_operation_mode() exec
set_mode(12) exec
BNO055.__init__() complete
InertialMeasurementUnit.__init__() complete

_config_mode() exec             <---- why second time
set_mode(0) exec
_operation_mode() exec
set_mode(12) exec
EasyIMUSensor().__init__() complete
create.py complete

On the face, it looks like the DI
easy_inertial_measurement_unit.EasyIMUSensor()
is a subclass of the
inertial_measurement_unit.InertialMeasurementUnit()
which instantiates a
BNO055.BNO055() object
saved into the InertialMeasurementUnit() class variable self.BNO055

The init() methods look like this:

Imu= EasyIMUSensor()

EasyIMUSensor.__init__():
    super(self.__class__, self).__init__(bus = bus, mode = mode)

InertialMeasurementUnit.__init__():
    self.BNO055 = BNO055.BNO055(bus = bus, mode = mode)

BNO055.__init__():
    self._mode = mode
    _configure_mode()  calls set_mode(OPERATION_MODE_CONFIG)
.
.
.
    _operation_mode()  calls set_mode(self._mode)

I did find an interesting stack exchange discussion: “In no circumstance should you do the following, …

super(self.__class__, self).__init__() # Don’t do this. Ever."

It looks like this is a left over from Python2 compatibility. In Python3 the thinking is:

    super().__init__(bus = bus, mode = mode)