WPILibPi Romi gyro calibration?

We just got a Romi yesterday and really amazed at how easy to get it set up and running with the simulator.

We’re using the sensors/RomiGyro code from the RomiReference example, and even after calibrating the gyros through the web UI the getRate() methods seem to have pronounced offset and the getAngle() methods drift when the robot is sitting still and level. The drift is modest for two axes but severe for the third. Has anyone else seen this behavior? I’ve been able to address somewhat by estimating new zero offsets and putting in romi.json manually, but these only seem to be read when the Romi is rebooted. Is there a way to force these constants to be reloaded without a full reboot?

Using the 2021.1.2 Kickoff along with the WPILibPi_image-v2021.1.1-Romi image.

Many thanks to all of the volunteers and mentors who put the WPILibPi stack & simulation extensions together. Absolutely game-changing for a programming subteam with no physical access to their competition robots this year.

1 Like

We found a bug in the calibration routine that led to slightly incorrect offset values. The fix is checked in but hasn’t been published yet. I’ll post an update here once we have a new version of the web service out, and you can use the web UI to update the service.

In the meantime, if you manually edit the /boot/romi.json file, you can use the Terminate button in the Romi tab on the Web UI to restart the web service. This will pull in the latest configuration values


Thanks so much for the fast response; we’ll be looking out for WPILibPi image updates and making good use of all the new 2021 sim, websockets & Romi efforts!

A new version of the Romi service has been published here: Release Romi Web Service 1.0.4 · wpilibsuite/wpilib-ws-robot-romi · GitHub

Download the .tgz file and use the web UI to update the service version. Ensure that you have the Pi set to “Writable” mode before doing the update.

Let me know if this makes things better!


The 1.0.4 web service update was completely smooth, and the zero offsets derived by the calibration process are now working much better. Thank you!


We were experiencing similar problems with the first Romi that we’d received (with a set of 6 more on their way, slated to arrive by Friday).

The 1.0.4 web service update certainly improved matters significantly (and thank you for that!), but we’re still seeing a noticeable drift in the readings that we’re getting back from the Romi (as reported both in the simulation environment and data received by our programs), even after recalibrating the IMU multiple times.

Are there other steps that we can/should be taking, or additional data that we can provide which might be helpful in tracking down what could be causing this?

How much drift are you seeing? The LSM6DS33 is a little noisy (somewhere in the range of +/- 0.85 deg/s). We do a little bit of filtering on the Romi side before doing the angle integration, but I can take a look and see what else we can tweak.

1 Like

I did one three minute run with the Romi stationary, observing the x, y, and z angles every thirty seconds.

time     x      y        z
30      0.1   4.8    0.7
60      1.3  13      1.0
90      2.1  17.7    0.6
120     3.4  23.3   -0.1
150     4.6  27.1   -1.0
180     5.5  27.0   -2.5

In less-carefully-controlled runs I’ve noticed the z angle go up to about +4 deg before turning around and going to -7 over several minutes.

I ran a simple static test. Basic conditions were as follows:

  • Robot was turned on, while resting on the floor.
  • IMU on the robot was put through calibration.
  • Ran a small sample application under the simulator, leaving the robot disabled (and unmoving).
  • Monitored the robot for about 80 seconds.

As can be seen in the recording available at https://youtu.be/vh74prZkn9I:

  • X-axis rotation reached -17.7 degrees
  • Y-axis rotation reached 1.1 degrees
  • Z-axis rotation reached -1.7 degrees

Again, the robot was placed on a stable, flat surface, calibrated in that position, and then monitored under the simulator without enabling/moving/touching it.

1 Like

So the good news is that it looks like the Z-axis (which is the one we care about in 99% of the cases anyway) is decently stable (a couple of degrees drift in a minute+ doesn’t sound too terrible for a low cost IMU).

The X/Y axes definitely seem noisier. On a couple of my test robots, I do see a little more drift on the X/Y (although not as bad as @chauser or @stmayhem). I’ll take a closer look at some of my other Romis and see if we can find a potential fix for this.