Category: Max’s Status Report

This week I worked on the Bluetooth interface for the RPi.

As it turns out, Bluetooth supports a mode in which it behaves like a serial port — something I have experience working with. After some minor consternation in setting that up, I was able to get a simple two-way serial program working in Python which forwarded data to a phone and received commands back from it.

Along the way, I made an important compromise which simplified implementation: I manually paired the phone to the RPi rather than automatically. As it turns out, pairing is only really accomplished with the bluetoothctl CLI, which I couldn’t figure out how to automate nicely. Pairing only needs to happen once per device, so this doesn’t impact our testing.

At the end of the week, I handed the device off to Nick after verifying that he could access the RPi over WiFi.

This week is spring break, and so I won’t be doing any major work; I’ll probably be acting as remote tech support if something with the RPi doesn’t work for Nick, who may be working over break.

After break, I’ll work out any discovered issues with the device and begin work on data collection when we have the infrastructure to support it.

Currently on-track.

This week I collected the necessary bits and got the RPi/IMU set up, as well as placing the order for the battery. It turns out that the manufacturer of the IMU addon board has their own demo code which manages their subset of I2C cleanly — this was much easier to use than the full smbus suite.

The data rate defaults to 100Hz which should be fine for us. The chip also exposes an interface to calibrate the accelerometers, but that’s only for adjusting the resting measurements. We can’t count on the orientation of the device to remain constant, so we probably won’t care to use the feature.

As of now, the RPi is configured to run headless (i.e. only talked to over wireless SSH), so it’s not going to do much more than sit in my room where it knows the WiFi password. Next steps are to set up Bluetooth and to see if there’s a better way to talk to it — preemptively adding WiFi networks by SSID/key is obnoxious.

Our Gantt chart has this as the first of two weeks for bringup, so the project is still fully on-time.

The main goal for this week was finalizing design & obtaining the rest of the parts for the portable system. While I do have all parts picked out and most in hand, I missed the window to order the battery for the device. However, that shouldn’t be a problem since we have a couple of weeks before we anticipated having a mobile hardware platform.

I looked over the available libraries for our two main interfaces (Bluetooth and I2C) and came to the following conclusions:

Bluetooth:

The pybluez Python library explicitly supports Raspberry Pi, which should make bringup that much easier. The Bluetooth Low Energy support is listed as “Experimental”, but we don’t need to make use of any of the fancier features, so it shouldn’t be an issue. Also, our power budget is seeming more and more generous now that we’ve decided on a 3000mAh battery.

I2C:

The smbus2 Python library is pure Python, so it should simplify setup. While it does not seem to support the full System Management Bus protocol (a derivative of I2C), the implemented features easily cover our use case (reading and writing from registers at low speed).

Both solutions are Python since we would like to be able to do our ML on the RPi, and Sojeong/Jacob are more comfortable doing that in Python than C, which seemed to be a more obvious choice for interfacing over I2C/Bluetooth.