imu_rate vs imu_sample_rate

[msmcconnell]

What is the proper usage of the imu_rate and imu_sample_rate variables?
imu_sample_rate changes the hardware configuration, so I would expect imu_rate to be the reporting rate of the ROS driver. However, if I set imu_rate to 50 and imu_sample_rate to 100 the reported values seem to double from what is reported when both parameters are equal. For exampl if the parameters are (100,100) I might get a yaw rate of 1.0 but if the parameters are (50, 100) I get a yaw rate of 2.0. Is this expected behavior?

I am using a Novatel PwrPak7 with SPAN configuration with STIM300 Imu

[pjreed]

imu_sample_rate should match your device's internal sample rate. It does not change the device's configuration; it needs to be set to whatever is pre-configured on the device. The default value, -1, will auto-detect it if the device is recognized; there's a list of known devices in novatel_gps.cpp. It looks like the sample rate for a Sensonor STIM300 is 125. There's no need to set this parameter unless you know your IMU is running at a non-standard rate or you're trying to use an unsupported IMU. This value has no effect on the publish rate; it's used to scale the magnitude of the velocities and accelerations that come from the device, because the Novatel reports values with units of rad/sample and m/s/sample but the ROS Imu message is supposed to use units of rad/s and m/s^2.

imu_rate is used to set the period of CORRIMUDATA, INSPVA, and INSPVAX logs on the Novatel device. The driver will publish Imu messages as fast as those arrive, so it should be the same as your desired publish rate. This doesn't need to be the same as imu_sample_rate, and according to Novatel's documentation, if this is less than the sample rate, it will accumulate samples in order to match the requested interval.

Personally, I would set imu_rate to be either the same as imu_sample_rate or a divisor of it, which is kind of awkward since not a whole lot of things divide evenly into 125. In your case, I think I would set imu_rate to 125 and leave imu_sample_rate unset (so it will default to -1 and auto-detect the right sample rate, which should be 125).

[msmcconnell]

It seems I misunderstood the imu_sample_rate variable then. I tried setting my imu_rate to 125 and imu_sample_rate to -1, but discovered that the driver will not output any IMU data in that case. However, if I set the imu_rate to 100 it outputs as expected. Do you know why that might be?

[pjreed]

It's possible something is going wrong that's preventing the driver from auto-detecting the IMU type. After it's done configuring the device (novatel_gps.cpp:1485), it writes log ramimuxa, which should cause it to log a RAWIMUXA message; the code at novatel_gps.cpp:1355 should run when it receives that log, and it will print an INFO message if it identifies the IMU type or an ERROR message if it fails.

So, things to check are:

1. If you can manually run log rawimuxa on the device, what does it print? If this returns an error, or if the returned IMU type is not in the table in the code, it won't be able to identify it.
2. Does the driver log a messages when it starts up indicating that it found or did not find the IMU? If you don't see either of those, the log rawimuxa command may have not caused any output at all for some reason.

In the meantime, the STIM300 is supposed to run at 125 Hz, so try manually setting that for both imu_rate and imu_sample_rate.

[msmcconnell]

According to the logs the IMU is being detected correctly as STIM300 and the imu_sample_rate is being set to 125. But for some reason setting imu_rate to 25 or 125 will result in no output. However, setting imu_rate to 50 or 100 will work just fine. Is there a particular reason you recommended using some fraction of the IMU rate as opposed to 100 or 50?

[pjreed]

Hmm, it seems strange that 25 or 125 wouldn't work... but if 50 and 100 work, that's probably fine. I feel like if the IMU is running at 125 Hz and the Novatel is publishing logs at 100 Hz, if you were to plot those values on a graph, you'd see some discontinuities in the output at points where the Novatel ends up aggregating multiple logs together, although that may not actually matter in practice.