Category: Meadow’s Status Reports

Since the last status report I’ve worked extensively trying to get calibration to save on the sensor, but due to the lack of documentation it has been difficult to make work. I’ve found a couple resources of claims to have done so, but even running these examples explicitly doesn’t result in a saved calibration. But I will continue to try methods in the coming week in case I can fix the issue. Aside from that, I’ve discussed the physical build of the hardware portion with Jason and we’ve come to a general consensus on it. We’re currently waiting for a key part for that, but after arrival we should be able to go to TechSpark and assemble holdings for the parts on our barbell clip. Finally I started exploring how to transmit our hardware data to the user in a presentable and easy to understand manner. Although we’re using Jamshed’s app for this, I wanted to be able to test ways to display things like balance before integrating it into the app. We were never going to use a full Arduino for the final build and our new ESP32 models arrived (what we will be using), so I got started on the setup between the new ESP32 and the BNO055 sensor using our existing Arduino script in the IDE. In short, I added the ESP32 as a board in Arduino so we can run our script in the same way, just with the right components. There’s an Arduino IO site that I also began setting up so I can try experimenting with sending the data that comes from my script into visual feedback, similarly to how it should be in our app. I think I’m a bit behind on having the sensor features working well enough to be sent directly to the app, but hopefully I can close some of those gaps in the coming week and a half before the final presentation. So, next week I hope to figure out the best way to display balance to users and make sure that Jamshed is able to read the values output by the BNO into his app in the same way we see them printed from my IDE.

This week I wanted to work on the calibration (such that it doesn’t have to be recalibrated after disconnecting), investigating the velocity, and figure out how to plot the serial data. Jason offered to manage the plotting, so I focused on the first two tasks. I was able to generate velocity in all 3 directions, but due to the difficulty of plotting data, I have not yet verified their accuracy (but they seem close to reasonable). Figuring out how to save the calibration status has taken longer than I was hoping and I think I need to do some more reading on how calibration gets stored before success. But so far, I (at least suspect) can calibrate the sensor and load the new values into a register on the sensor, however, I haven’t been able to check that the values stay the same upon rebooting yet. So I think I’m halfway there. This shouldn’t be an issue for our upcoming demo since we can just keep the sensor connected and calibrating is a quick process. Next week I plan to work with Jason on integrating the plotting software and validating my values. I’m also hoping that in the coming few days I can figure out what I’m missing with saving calibration, but here is what my serial monitor has been looking like after the initial calibration.

First we see the sensor at rest (there are a few offsets that will be adjusted later):

And here we have with some random movements (i.e. up/down, side/side, figure 8’s):

This week I learned more about how to interact with the BNO055 and the necessary code. I managed to calibrate the acceleration that was posing issues from last week and successfully configured the x, y, z acceleration and rotations about the x and y axis. The setup is stable and my output values are consistent every time. It seems easy to visually confirm the accuracy of the orientation angles, but I will confirm them with a protractor or something later. I’m unsure about the accuracy of the acceleration values because they seem to lag in changing (or not change at all) for a variety of short movements. However, this may just be an inability to comprehend what these values should be reporting. So far I’ve been analyzing this data straight through the Arudino IDE and using its serial plotter and monitor. These will not be sufficient to test against the ground truth (mostly because the plotter is pretty frugal),  so I was trying to find a reliable serial plotter software to run my experiments. But I couldn’t find one that works. Still looking for that fix. Unfortunately I was unable to test against ground truth for this reason and it will have to be postponed another week. But the sensor readings have made reassuring progress! Next week I want to implement the feature to save calibration status so I don’t have to redo it every time I want to test something and I want to figure out the plotting software situation to challenge the sensor accuracy. I also need to look into getting sensor velocity; I was under the impression this sensor calculated its own velocity (part of the reason we chose it), but we have yet to find documentation on this.

This week I validated the real time streaming from the sensors after our new wires came in. I worked on calibrating the sensor, but came across some difficulties on how to so based on the Adafruit documentation. However, I managed to find a way to calibrate them after research on the device and  looking through sample code. I managed to calibrate 3/4 metrics reported from the sensor, but was unable to calibrate the acceleration vector, thus was unable to compare readings to a ground truth context for now. I have since found a method that should work to calibrate acceleration from the BNO055 GitHub and will verify this in the coming week. For next week I plan to solidify the calibration status on the sensors and become more comfortable with how to program what we want the sensor to do. Then I will begin some initial tests comparing the sensor to ground truth.

I am slightly behind from figuring out the calibration issues and haven’t been able to test the sensors on a barbell yet, but aside from this, other aspects seem to be on schedule. However, testing the sensors on a barbell goes hand-in-hand to comparing the sensor data to the ground truth model, which is expected to be done next week.

Most of the work for this week was spent on the design report and fleshing out details for our device that weren’t set in stone or coming up with implementation plans. The rest of the week I used to set up the BNO055 with Arduino and confirmed real time data output along with minor power supply research. Having a sensor set up with Arduino instead of only the ESP32 will help with parallel testing and allow me to work on the sensor data and power independently from the Bluetooth communication. Testing was not consistently successful, however, due to losing contact in the sensor inputs from loose wire connections (no solder yet and waiting on STEMMA QT cables). For next week, as the cables arrived during break, I want to ensure reliable data output and move to confirming accuracy with ground truth comparisons and work on calibration if there are mismatches.

So far things seem to be on schedule.

This week I gained more understanding on the ESP32 and the BNO055 and its setup process, along with part characteristics through research, prior to Jason physically testing the sensor. Even though he got some readings out of it, I found that pairing the BNO055 with an ESP32 is not reliable, per a warning from Adafruit. I took to looking for other microcontrollers compatible with the sensor in case there’s a more efficient option that offers more of our requirements than an Arduino (which we initially planned to test with). A different IMU was ordered to see how it compares to our BNO055, which will be tested after it arrives. I ordered a part that should help make testing the sensor easier for next week and eliminate some human error. I’ve also been looking into how to make our testing more functional by creating a (very) basic prototype to attach on a real barbell.  Because we know that the sensor is outputting values and have a script ready for more testing, next week I plan to investigate the sensor readings and check accuracy/plan for calibration and potentially perform more dynamic testing to simulate our use case instead of basic hand movements, should we manage to create the necessary mobility.

Progress feels on time.

This week I dove more into IMU investigation and learning which specs to look out for to find a model that fit the requirements of our design. Jason and I ended up settling on an Adafruit BNO055 due to its accelerometer range and ease of orientation data collection. It seems to have all the tricks we’re looking for with a design that won’t compromise any of our needs. We placed an order for a few of them and aim to test their functionality after arrival. As these are meant mainly to get a feel of what to look out for in hardware implementation, I plan to look into a few more IMUs and begin researching more about complementary parts we’ll need for the BNO if we continue strictly with this model. Lastly, I dedicated time to collaborating with my group on the design presentation and fleshing out the content and delivery of our information. So far we are still on track from previous week’s expectations.

As the first proper week working on our project after solidifying a concept, I spent time with my group brainstorming the necessary materials and requirements needed for our device. I aided in the research and design of our proposal presentation, making tweaks from the abstract and honing in on what we wanted our use case to accomplish. I worked with Jamshed to provide Jason mock-presentation feedback before the proposal presentation. A lot of the work time this week was spent generating a better idea of what our project seeks to accomplish and how we can implement it, which became clear in our proposal slide deck. On my own time I began reading up on devices on the market that provide the metrics we want to implement in the barbell sensors and if they should be feasible to integrate into our design.

In the coming week I hope to composite a list of IMUs and individual accelerometers, gyroscopes, etc. that compare their features and see which parts meet our use case requirements. After deciding and collaborating with Jason (as the other hardware member) I would like to place orders for the ones we deem best. Finally, since the design proposal is coming up I will collaborate with my group to develop a concrete plan with corresponding slides outlining what we plan to achieve.