Posted on

Max’s Status report for 4/18

This week I worked with Jacob and Soejong on porting/integrating the SVM to the RPi and separately worked with Nick on getting a mobile Bluetooth app online.

The SVM is running nicely on the phone and seems to be working as expected with the IMU data — I have it reporting results in realtime over Bluetooth to the generic Bluetooth serial terminal app from before. Before running in realtime, I determined that each inference takes about 13ms which is well within acceptable bounds — right now, we’re checking a 1s window once a second. Determining power draw/battery life probably won’t happen since our battery has disappeared (somewhere in mail system, not on route to me), but I might be able to work something out.

On the app front, I was able to run an older, native version of Nick’s app, so he has a working environment. That uses a native library, so the biggest hurdle (getting arbitrary native code working) is done.

Posted on

Max’s Status Report for 4/11

This week (and weekend) I spent far too long trying to get a simple Bluetooth app working. Some combination of my unfamiliarity with the Android ecosystem, Java, Javascript, JSX, and the toolchains used to work with all of those led to a lot of time and no real progress. I asked Nick to take a look at it, but the environment he’s been using (Expo) doesn’t seem to be compatible with the sort of device-native code needed by the various Bluetooth approaches I’ve tried.

In order to make real progress, I’ll ignore that for now (other than working with Nick as needed) and get to running the SVM on device — that should be much smoother.

Posted on

Max’s Status Report for 4/4

This week I brought up a fairly robust simple two-way messaging system between an Android phone and the device. This has error handling and retry logic to make sure that it doesn’t get confused/softlocked due to a flaky connection — having a means to power cycle it without pulling the plug or sshing in is nice.

This was all done on the device’s end; I used an existing app for the Bluetooth serial handling on the phone. This upcoming week, I’ll work on a basic React Native app to work as an example receiving end of the interface in lieu of directly integrating with Nick’s work.

In parallel, I’ll work to get the fall detection SVM running on the RPi. this shouldn’t take much effort, but it may reveal performance issues. If all goes well, I should be able to get the realtime detection working on the IMU data and/or record data to test.

Posted on

Max Lutwak Status Report for 3/28

Other than working with the team on refocusing, I didn’t get much done this week — the RPi and IMU showed up in the mail from Nick on Friday.

This week I’ll be figuring out & writing a simple app and the RPi Python code to talk to it over Bluetooth. This will constitute the interface between the hardware subsystem and the app/ML.

Once I have that data connection working, I’ll start collecting data to send to Sojeong and Jacob.

Posted on

Max’s Status Update 3/22

This week I mostly worked on figuring out how to proceed with the rest of our team.

It turns out that there isn’t an easy way to get the parts for another setup — Adafruit and similar companies are shut down and Amazon has shipping dates for late April at the soonest. Because of this, we’ll have to keep working with the one device.

I also spent some time this week troubleshooting some issues Nick was having with connecting to it over different networks.

For our SOW, we decided to split the major parts of the design into separate goals to avoid needing access to the device, but we didn’t fully specify the end products. This week I’ll decide on concrete goals for demonstrating the hardware side’s functionality (and probably get Nick to mail the rpi since the Bluetooth interface will be on the hardware end).

Posted on

Max’s Status Report for 3/7

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.

Posted on

Max’s Status Update for 2/29

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.

Posted on

Max’s Status Update for 2/22

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.

Posted on

Max’s Status Update for 2/15/2020

This week we narrowed down our hardware platform to a specific model RPi (Zero W) and picked out a plug-in accelerometer from the 18-500 inventory. I picked up the parts at the end of the week. Still need to get some components (portable power source, some means of attaching it to a person), but those won’t be necessary until we have a system working. Next task is to setup an OS and figure out how to talk to the IMU over I2C.