18-500 Capstone

This a log of Reed Chan's weekly status updates for Team B2: 'Sole Mate'; Spring 18-500 Capstone.

Weekly Status Report

May 4, 2018

This week's Python script calculates the slope of the surface based off of the combined IR sensor data and the IMU data. It also includes a function that will batch process an input array to correct for offsets in the IR sensor's mounts and another function that corrects the IMU data (since we mounted the IMU upside down). The slope detection appears to work after I corrected the data, but Nihar and I noticed that the calculated slopes were off for the data sets that were taken on a hill. Upon closer inspection, the IMU data on the hill was drifting and failing to correct itself, even when the IMU was resting on level ground. Aside from feature detection, we worked on and practiced for the final presentation.

Next steps:

• Collect addition data (with different runners)
• Increase accuracy of slope detection (try to account for IMU drift)
• Start working on the final report
• Make the poster

Weekly Status Report

April 26, 2018

I updated the Python scripts to match the updated MATLAB scripts. Over the weekend, we met up and Nihar and I created another Python script to process the IMU data. We realized that the IMU was drifting while running so we applied a high-pass filter to the data. We also implemented a basic linear interpolation function so we can get IMU data points that line up with the IR sensor data points. I later verified that it works as expected by comparing the output to the output from the numpy.interp function. Afterwards, I have been working on combining the IMU data and the IR sensor data to determine the slope of the surface. Nihar and I worked out how to do this on Monday and I've determined how to do this for the different combinations of the sensors and the ground.

Next steps:

• Programatically determine the slope of the surface based off of the combined IR sensor data and the IMU data
• Collect addition data (with different runners)

Weekly Status Report

April 18, 2018

Connor and I wrote some MATLABscripts and functions to process the data from the IR sensors all at once. We applied a moving average with a window size of 25 samples to smooth the data. We then took the first derivative of the data, manipulated it a bit according to some conditions, added it all together, and further applied some conditionals in order to indicate when we thought a step was happening. Overall, we look out for zero-crossings that have been prefaced with positive values in the first derivative data. However, since smoothing the data introduces a delay, we indicate that a step occurred a little earlier than when the first derivative data would indicate that it happened. A step is not instantaneous so we opted to make it a square wave as well.

I went further and adapted the MATLAB scripts and functions into a Python script that uses the Python 'NumPy' and 'Matplotlib' packages to do the same thing. This will be helpful if we opt to do the post-run processing on the Raspberry Pi's without having to generate code that can run on them (since MATLAB code does not run on a Raspberry Pi). An example of the output visuals from running one of our data logs through the script can be found below.

Next steps:

• Determine the orientation of the IMU given its output orientation values from the program
• Determine how to extract information from the data (e.g. determine the slope of the ground from IMU and IR distance sensor data)
• Pair IMU data with IR sensor data indicating when steps are occurring and determine if interpolation is necessary
• Refine timestamps for the data so they're all in the same format

Weekly Status Report

April 12, 2018

Connor and I looked into the IMU and the program that we are using to get data from it. We were able to determine how the program configured the IMU, what the program's options were, and how to interpret some of the resulting data. The IMU's accelerometer and gyroscope are configured with an output data rate of 1.66 kHz, but the program's functions for reading and outputting the data also included calls to usleep(20 * 1000) or set a timerfd's period to 20,000,000 ns so the max theoretical sample rate of the program was only 50 Hz. With the help of a Python script, I determined that using --mode raw (which calls stream_raw_values) the empirical sample rate was 35-40 Hz whereas the other output modes had an empirical sample rate between 48-50 Hz. Changing the values of the usleep call or the timerfd's period did not appear to affect the empirical sample rate.

This may be an issue in the future as we begin to collect data with the IR distance sensors, the load cell, and the IMU simultaneously. A potential workaround would be configuring the I2C bus with a faster clock speed to ensure that all of the sensors can function together.

Next steps:

• Simultaneously collect data from all of the sensors mounted on a shoe
• Determine how to process the IMU data (e.g. moving average or moving median for a LPF)
• Determine how to extract information from the data (e.g. determine the slope of the ground from IMU and IR distance sensor data)
• Determine the orientation of the IMU given its output orientation values from the program

Weekly Status Report

April 5, 2018

I was able to figure out what I was doing wrong with the Python 'Matplotlib' package and I was able to plot the data that we collected last week. I was also able to combine this with NumPy and SciPy to create a lowpass filter that I plan on applying to the IMU data. For now, this means that we can programatically process and visualize the data rather than having to manually handle everything in Excel or in Google Sheets. While not strictly necessary, I would like to change it so that we can process and visualize the data while the data collection is happening rather than having to wait until each data collection run is done. This would approximate our end goal of providing user feedback while the sensors are in use.

Next steps:

• Figure out what data we need from the IMU and how to process it (e.g. determine the slope of the ground when combined with the data from the IR distance sensors)
• Determine the sample rate of the IMU and the desired cutoff frequency so we can design a lowpass filter to reduce its noise
• Determine if we need to calibrate the IMU
• Update our product/software requirements as we continue to determine which sensors are usable

The image below is a plot of the configurable Butterworth lowpass filter that I created using SciPy and a plot of the channel 0 (so either the front or heel IR distance sensor) data from the ADC that takes in the input from the IR distance sensors. The plots were generated using Matplotlib.

Weekly Status Report

March 29, 2018

I was able to use an existing program from Pololu to get data from the IMU. On Monday, while I was installing some Python packages to help perform some processing of the IMU data, somebody gained access to my Raspberry Pi Zero W and changed the password. I later received an email from CMU's Information Security office notifying me that it had been suspended from the network for "scanning for SSH scanning (TCP 22) against external IP addresses starting at 2018-03-28 11:02:53 " and that is likely the result of default credentials on a Raspberry Pi device. Sadly, I ended up having to re-flash my microSD card with Raspbian for the third time. The one good thing is that I discovered that I could generate a Wi-Fi Protected Access pre-shared key (WPA-PSK) using wpa_passphrase and that I could hash my password for connecting to CMU's Wi-Fi network on campus using echo -n plaintext_password_here | iconv -t utf16le | openssl md4.

Once I got my Raspberry Pi Zero working again (and its CMU network access restored), I was able to return to installing the Python packages. Installing SciPy took a while because it requires NumPy and the version of Raspbian that I flashed has the package index found at https://www.piwheels.org/simple as an extra index. It's meant to save time since it has Python Wheels (a ZIP-format archive with a specially formatted file name and the .whl extension) so you don't have to compile the packages on a Raspberry Pi. However, their NumPy Wheel was compiled with a missing dependency so I had to resort slowly building NumPy myself with pip3 install -U --no-use-wheel numpy. The SciPy Wheel seems to be fine though since it installed without a problem once NumPy was installed properly.

Besides that, we met up and we were able to verify that Nihar's Python script can be run headless. I put on the prototype that Nihar, walked around to gather some data from the IR distance sensors, and then we moved the data log file off of his Raspberry Pi to begin some preliminary processing. I used the Python 'Matplotlib' package to plot a subset of the data, but it didn't match up with what we saw when we plotted it in Excel.

Next steps:

• Figure out what data we need from the IMU and how to process it (e.g. reducing noise)
• Figure out how to use NumPy, SciPy, and Matplotlib to process and visualize the data
• Update our product/software requirements as we continue to determine which sensors are usable

Weekly Status Report

March 22, 2018

Unfortunately, my Raspberry Pi Touch Display's connector, which works with my Raspberry Pi 3B, isn't compatible with the Raspberry Pi Zero so I was unable to configure the Raspberry Pi Zero as I had planned. To make things worse, I ran into a setback this week when I was configuring my Raspberry Pi Zero to test the IMU and its I2C interface. My Raspberry Pi Zero froze while running the raspi-config command so I had to backtrack. I ended up having to re-flash the microSD card with Raspbian. Luckily, I figured out how to connect the Raspberry Pi Zero to CMU's Wi-Fi network on campus while I was editing the /etc/wpa_supplicant/wpa_supplicant.conf file. I was able to get Connor's Raspberry Pi Zero connected to the network by editing the file on his microSD card too.

In the meantime, Connor has been working to transfer data over Bluetooth between a Raspberry Pi Zero and either a laptop or a phone. I've looked into it a bit and it seems we can use either the standard Python 'socket' module with code that's similar to 349's PID controller lab's Python networking portion or we can use the PyBluez package. Neither option stands out since they both appear to lack documentation. For now, we've found some documentation for the PyBluez package, but we still need to look through some of the examples and actually work it out ourselves.

Next steps:

• Test libraries to collect data from the IMU
• Update our product/software requirements as we determine which sensors are usable
• Test transmitting and receiving data over Bluetooth between a Raspberry Pi Zero and another device

Weekly Status Report

March 8, 2018

We worked together as a team to redirect traffic from the link on the capstone page to this Google Site instead. We also worked together to come up with our design proposal after accounting for some of the changes suggested by the professors.

However, there's one thing that's holding us back at the moment. We only have a single USB to TTL Serial cable so we have to pass it around to get the Raspberry Pi Zero W's set up. That, in addition to our toolchain issues, makes it hard to work together. I was able to get my Raspberry Pi to connect to my apartment's Wi-Fi network before, but it's not so simple when it comes to the Wi-Fi network on campus. None of us have much experience using just a terminal to connect to a Wi-Fi network and the campus' network complicates things with the need to authenticate with our Andrew ID. After I finish my midterms this week, I plan on connecting my Raspberry Pi to my personal Raspberry Pi Touch Display and taking it onto campus to see what I can do.

From there, it's a simple matter of enabling I2C using the raspi-config command. I have already flashed all of the microSD cards with Raspbian Stretch and it already has the python3-smbus package installed. I also need to check for the RPi.GPIO Python package as well. We are considering using piezo buzzers in place of the OLED display for runner feedback. They're light enough that the user shouldn't be affected by them.

Next steps:

• Set up Raspberry Pis so we can connect to them via SSH (highly preferable to relying on the USB to TTL Serial cable) and work together while on campus
• Set up and collect data from the IMU, the IR distance sensors, and maybe the load cell
• Update our product/software requirements as we determine which sensors are usable
• Look into step-up boards/voltage regulators/boost converters from SparkFun, Polulu, etc. so we can use lighter LiPo batteries to power the hardware