Today we tested the fiber optic gyroscope for the first time in the pool.
Gyro Integration
The gyro requires a 1000Hz square wave as a trigger signal, and communicates using the RS-422 standard. Denton and I wrote Python code to send the trigger signal and parse the received data. The data was publishing at 800-900 Hz, had many unexpected fluctuations, frequently experienced checksum errors, and wasn’t as accurate as expected.
The manufacturer said that a software-generated trigger signal wouldn’t be precise enough for the most accurate results. They instead recommended a hardware-generated trigger signal, created by a microcontroller or FPGA.
We decided to use the Peripheral Arduino to generate the trigger signal. Arduinos aren’t designed to communicate via RS-422, so we purchased a TTL to RS-422 module to convert Arduino serial outputs into RS-422 format. However, the module didn’t appear to work – even though it received the trigger signal from the Arduino, the module didn’t send the signal to the gyro.
Instead, I found that since the Arduino only needs to send the trigger signal (it doesn’t receive the gyro data; that goes directly to the computer), the signal is simple enough that the Arduino could send it as per the RS-422 specification without needing any extra hardware. I used a hardware timer built into the Arduino to generate two 1000Hz square waves where each wave always has the opposite value – if one is high, the other is low, and vice versa. The two square waves were sent directly to the RX+ and RX- pins on the gyro, and this successfully triggered the gyro to send data with precise timing.
The gyro data is processed using PySerial and published to ROS topics. ros2 topic hz indicated the publish rate was 998-1000 Hz, proving that the trigger signal had very precise timing. It also fixed the other issues observed previously – there were no unexpected fluctuations, no checksum errors, and the data was very accurate.
I added an error correction constant to the gyro code; see the Appendix for more details. And I updated sensor fusion to not fuse the IMU’s angular Z velocity and instead fuse the gyro’s angular Z velocity.
Gyro Pool Testing
It took a few hours for electrical and mechanical to finish integrating the gyro into the robot and prepare the robot for the pool test, so we got to the pool at around 2:30 PM. We used all the time we had to test the gyro and sensor fusion.
After getting to the pool, we realized that the robot didn’t have the large buoyancy blocks it needs above the marker dropper and DVL; they were taken off to work on the stack and left at the Foundry. We added buoyancy blocks we had available at the pool to get the buoyancy to be similar to what we had at the last pool test, but since we didn’t have the original blocks, it wasn’t the same as before; the robot wasn’t perfectly level. Nevertheless, we proceeded, as the tests we planned didn’t require a perfect buoyancy.
We made the robot do a simple depth hold. The robot held its position for 7-8 minutes without any noticeable yaw drift.
We then did several tests where we started the robot in a corner of the pool, moved it by hand to the other end of the lane, and returned back to the same corner in the same orientation. We found that the yaw value in state drifted by 2-3 degrees and the X and Y positions drifted by 0.5 – 1 meters.
Summary
The gyro has clearly eliminated short-term yaw drift, as shown by the depth hold. So, for example, we can do the coin flip by simply rotating the robot back to its original yaw; we don’t need to correct it with CV.
When the robot moves long distances, state is more accurate than it was before. However, it isn’t accurate enough to dead reckon to faraway targets precisely. For example, we can’t dead reckon from the gate to the octagon or vice versa.
Appendix
The gyro measures angular velocity with respect to an inertial (non-accelerating) frame of reference. Even if the gyro isn’t moving with respect to the surface of the Earth (ex. sitting still on a table), it’s still experiencing acceleration from cosmic forces, including the rotation of the Earth about its own axis, the rotation of the Earth about the Sun, the rotation of the Sun around the Milky Way, and the movement of the Milky Way towards the Andromeda galaxy. The latter three forces are extremely small. However, the rotation of the Earth about its own axis does have a significant impact on the gyro’s output. So, even if the gyro is just sitting still, it consistently reports a slightly positive angular velocity.
The robot’s state is measured relative to the surface of the Earth. So, we need to remove the effect of cosmic forces from the gyro’s output. We had the gyro sit still for five minutes, computed the accumulated angular error, and divided by the elapsed time to obtain the error in degrees per second.
We subtracted this value from the gyro’s angular velocity. The gyro still accumulates some error due to changes in temperature, EMI, and inaccuracies within the sensor itself, but we observed this was less than 0.0005 degrees per minute, which is negligible.
This error value must be recomputed if we take the robot to a location with a different latitude, such as Irvine, CA, as the latitude impacts the amount of angular velocity contributed by the rotation of the Earth to the gyro’s output.