Gyro might not be functioning properly

[Zacharyprime]

The gyroscope is reading out precise values now. There is a small accuracy problem but the pull request I created solves it to the point where the gyroscope is usable. The patch name is ZacharyGyro-Patch-A.

Sometimes there is a spike in the data that I can't find the source of and when integrating the data to get absolute position there is a +/- 10 degree inaccuracy that can be minimized slightly by adjusting sample frequency.

For botball purposes, I think it will work.

[Zacharyprime]

I wanted to add clarification to the current state of the issue.

The output of the gyro has spikes that happen seemingly at random. They also are not regular. For example, the output shown at the bottom required me to run the program 3-4 times before it showed a problem.

I still haven't found a identifying pattern to the behavior, the only information I've found is that it's been the high register that is incorrect in every test I've done (resulting in a large spike since it's most significant). The odd part is that the IMU isn't read via a bus like you would expect a bit flip error like this to happen, it's done using SPI communication...

I do believe it would be possible to move the IMU to be handled by the Pi (just like all the non-analog devices). This would require an expensive rework and would need to be packaged with other major design changes to be worth it. I wouldn't be surprised if the STM32 was the cause of the issue, since moving the SD reader and USBs to the Pi fixed similar data corruption issues too.

The "angle" number is a trapezoidal sum with the data filtered using a time-domain high pass filter (there may be a moving average filter, I don't remember if I had it enabled that run).

Edit: There is probably a moving average filter, just by looking at those numbers

Here is a schematic of the IMU in case anyone does not have it:

The firmware and libwallaby code seem fine to me, the schematic also doesn't show anything that would cause this error (in theory since this is EAGLE), maybe there is a manufacturing issue or something? I'm at a loss of ideas at this time.

[Zacharyprime]

The firmware was missing a setup process which I added. I also modified libwallaby to reflect the firmware change.

You can apply it to your wombat by doing an online update. You need to have wombat.bin for flashing instead of wallaby_v8.bin Here is the spreadsheet for the experiment data from my tests on the gyro after this fix: https://docs.google.com/spreadsheets/d/1fwIDw7y76WylASVldnxO-bq3UiNzY-dxusHyrINDscI/edit?usp=sharing

For the Velocity Test, I ran the robot at a specified gyroscope value, basically making a program that turns the wheels so that the output of the gyro is a constant. Then I let the robot make X number of turns and timed how long it would take to do that many turns with a stopwatch. That gives me what it's actual angular velocity is. Then the graph is showing the relationship between that physical rotational velocity that was measured and what the gyro reported.

The (trapezoidal) Integration Test is a little messier, I turned the controller with my hands to a specific angle while my program was calculating the integral of the gyro data in real time. Then at the end of the program it would print what the result of the integration was. Using that, I showed that there is a correlation between the integration and how much I turned the controller with my hands. It doesn't matter that my hands will have not been spinning at a constant speed in this case because integrating the value of gyro_z already accounts for that. When I actually tried to get a demobot to go to a specific angle with this integration, it was accurate but not precise. There was an error of +/-20 degrees. The motor test was my next attempt at making an accurate method of using the gyro, but then I had to work on other things.

The motor test was just me using that data to make an equation that tells me the exact motor values that would give a specific rotational velocity for that robot. Then I could have the program that targets the specific speed start at an approximated motor speed and then adjust from there rather than adjusting from 0 speed. I really should have done this using mav and not motor but the principle would still apply.

[Zacharyprime]

As far as I can tell, the gyroscope is outputting correct data, but when I tried to integrate the data to make a gyroscope function, it was not precise. I ran some experiments to try and figure out what exactly is causing the inaccuracy, but every experiment I run shows that the data is good. My current thought is maybe the sample rate isn't set high enough, but I've been working on higher priority tasks so I haven't looked into the sample rate yet. https://docs.google.com/spreadsheets/d/1fwIDw7y76WylASVldnxO-bq3UiNzY-dxusHyrINDscI/edit?usp=sharing

The "Linear Speed Test" tab contains my data from the best experiment I ran.

[Zacharyprime]

I was looking around for something else and found this. https://invensense.tdk.com/download-pdf/migrating-from-mpu-9250-to-icm-20948/

I need to check what is actually on the board because I thought we used the 6050, but my documentation says we are using the 9250. I am probably just mixing up another project I used the 6050 for, I trust the documentation more than my gut in this case.

[Zacharyprime]

Braden and Noble (botball team) have worked on this quite a bit. If @bmcdorman could fill in where we are at on this.

I believe they found something with the sample rate. Whatever the problem is I am very confident it will have to be a time dependent issue like sample rate or execution timing because the data I've collected shows that the Wombat Gyro is accurate with an R^2>0.99. (Note: I gathered this data a long time ago)

For this experiment I basically setup a loop that the motors would adjust their speeds to hit a target gyroscope value, then I calculated the angular velocity using a stopwatch and counting the time it took to spin a given number of times.

For this experiment, I set the MAV speed then measured the steady state gyroscope output. The data becomes more unstable at the ends because the motors are not as accurate at those velocities.

The main reason I am showing these particular experiments is that it shows that the values are at least accurate. However the factor that is removed in all my experiments is precise timing because designing timing experiments can be tricky. The experiments get good data because the effect of time is minimized in both experiments.

Integration however is very sensitive to timing...