MicroDozer Fall 2019 – Telemetry From the IMU

Sending Orientation Values to the Arxterra App

Author/s: Clare L.
Verification:
Approval:

Introduction

The IMU designed by Bosch [1] is composed of an accelerometer, magnetometer and gyroscope. With code provided by Adafruit [2], you can get pitch, roll, and yaw directions in degrees in a 360 degree sphere. The goal was to have the values send to the app for the user to see as the robot was being controlled.

Starter Code

This code [2] was used to pull x, y, and z orientation values from the BNO055 IMU.

Sending Data to Arxterra App

Code was written to send data to the Arxterra app, but not for controlling the direction:

The code would not have been able to be written without the code that is available in the Arxterra telemetry section, on which there is an example of sending data to the app.

Angles from the BNO055 were sent to the Arxterra app. In developer mode, when trace was turned on, I was able to see the hex representations of the angles of the robot, or the IMU, as it was being moved around. When I moved the IMU around, the telemetry data appeared in bursts of five or six lines or more. The code reads the IMU, initiates control of the motors, and sends the x-y-z orientation data to the app. The addresses for x, y, and z, respectively, were 0x40, 0x41, and 0x42 as seen in lines 17 through 19.

The custom command types that were available in the app were: Boolean, byte, unsigned byte, short, unsigned short, heading/separator. I didn’t want to use signed byte, because I needed a range of numbers that reached at least +180, -180 degrees. Data from the IMU with the code I had were none of these, so I converted them to signed integers so I could use the short option (signed integers) with the line: int16_t x_reading = (float) event.orientation.x; (appropriately for each direction) so that the code was reading float data and casting to integer data. My range was -32768 to 32767, and the command widget used was slider/stepper.

Below is what I saw on my phone:

Telemetry packet data here always starts with CA. Next, you can see a few “03”s which is the packet length of the data. In the last line as an example, you can see the 40: this is the telemetry ID 0x40 – this one corresponds to the x-direction orientation data that was assigned in line 17 in the code above. Where you see 41 or 42, those correspond to data in the y- and z-directions, respectively. The next two bytes are the data: 00 D7, which is equal to 215 degrees in decimal form. The last byte, 5E is the LRC (longitudinal redundancy check), which is explained in full detail here: https://www.arxterra.com/arxterra-bluetooth-wireless-communication/.

Conclusion

Given more time, I would have analyzed the hex data more. Some of the values were as high as FF FD as an example, which corresponds to a value much higher than +360 degrees or -360 degrees. There is more troubleshooting to be done with the data that was sent, and may be an issue with the casting in the code, converting integer to float.

[1] https://cdn-shop.adafruit.com/datasheets/BST_BNO055_DS000_12.pdf

[2] https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/arduino-code