Tag: status report

I was finally able to figure out what was wrong with saving calibration status. Now I’m able to calibrate, power off, then upload to see fully calibrated accelerometer and gyroscope. However, there is a slight hiccup that the magnetometer does not save calibration and I’m not quite sure why that is yet. Calibrating it only involves slightly moving the sensor, so even though it starts at 0 when restoring calibration, it easily reaches 3 (fully calibrated) with minimal motion. In the context of our device this shouldn’t be an issue but I will look for some fixes next week just in case. All of my sensor testing was done with an Arduino, but I just cleared our ESP to work the same way with our scripts. Because we chose an Adafruit ESP with a screen as our secondary component, I also was working on displaying battery status when the device is on. There isn’t as much documentation on how to do this as I was hoping, so it’s not working quite yet but with a bit more research I should be able to reflect the message on the screen (for now it successfully prints in the basic serial monitor). I also began to work on the final presentation and develop the physical build of the sensor. Lastly, I spoke with the team about how we’d want to represent the balance metric and we decided on graph variation that will maintain a steady state until it senses a tilt, in which the output should move in either +y or -y to indicate imbalance (fairly basic).

I am a bit behind on some of the testing procedures due to setbacks in the data department, but it shouldn’t be too hard to catch up after completing the device assembly.

So, briefly, next week I’d like to: attempt to resolve magnetometer not restoring calibration, debug battery visual appearing on ESP screen, and engage in some of our testing procedures.

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.