You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An annoying issue I am running into with my Create 1 is that at low speeds angular velocities, the odometry does not register that the robot is turning. After thinking about this for a while I realized this is because of the incremental nature and low resolution of the angle sensor field.
Since this field only has a resolution of 1 degree, and it is polled and reset to 0 every 15 ms, this means that any rotational speed below 67 deg/sec appears as no movement, assuming the value is rounded down. I haven't measured exactly, but this seems to match the behavior I have noticed.
Another side effect of this issue is that the odometry reading can drift significantly even at higher speeds, because of the rounding of the angle. In the worst case, this could mean that the heading is drifting 67 or 33 deg/sec, depending on whether the angle is rounded down or to the nearest whole number.
There are a few ways I can think of fixing this problem. Sampling at a lower rate would reduce the minimum speed at which rotation can be measured, but it really doesn't solve the problem. Another way to mitigate the problem is to integrate the wheel velocities, but this has its own issues. For one, the Create only exposes its requested wheel velocities, but these might be close enough to the actual velocities to make an improvement over the current situation.
I am really starting to see why the Turtlebot includes a gyroscope, and I might investigate this as another solution.
I'll test out a few solutions and submit a PR if I can make any improvements.
I just realized I created this issue on the wrong project...
I did some more testing and discovered that this appears to be a bug in the Create 1 firmware, as the distance field, which I would expect to have the same problems, seems to work correctly. If the robot has moved less than 1 mm since the last polling time, the distance field will 0, but internally it still keeps track of the distance travelled and will correctly report movement once the distance gets large enough.
The angle field, on the other hand, gets reset to 0 internally each time it is polled. This means that if the robot is rotating at less than 33 deg/sec (0.5 deg per 15 ms) the angle field is always 0. The angle appears to be rounded to the nearest whole number.
Yes, iRobot has documented this firmware bug related to Angle and Distance. Unfortunately, they no longer support firmware upgrades from what I understand.
I think it will involve some serious changes to libcreate if we wanted to decrease the polling frequency. We could either request pausing/resuming the data stream as a means of throttling updates, or move away from the data stream feature and just make a separate queries at some interval.
If you'd like to continue the discussion, open another issue here.
Activity
lopsided98 commentedon Jun 28, 2016
I just realized I created this issue on the wrong project...
I did some more testing and discovered that this appears to be a bug in the Create 1 firmware, as the distance field, which I would expect to have the same problems, seems to work correctly. If the robot has moved less than 1 mm since the last polling time, the distance field will 0, but internally it still keeps track of the distance travelled and will correctly report movement once the distance gets large enough.
The angle field, on the other hand, gets reset to 0 internally each time it is polled. This means that if the robot is rotating at less than 33 deg/sec (0.5 deg per 15 ms) the angle field is always 0. The angle appears to be rounded to the nearest whole number.
jacobperron commentedon Jun 28, 2016
Yes, iRobot has documented this firmware bug related to Angle and Distance. Unfortunately, they no longer support firmware upgrades from what I understand.
I think it will involve some serious changes to libcreate if we wanted to decrease the polling frequency. We could either request pausing/resuming the data stream as a means of throttling updates, or move away from the data stream feature and just make a separate queries at some interval.
If you'd like to continue the discussion, open another issue here.
Fixing odometry angle issue by adding analog gyro on Cargo Bay pin 4
Added ability to set gyro_offset and gyro_scale parameters
Added gyro_offset and gyro_scale parameters for tuning