Expose individual wheel distances and velocities. #19
Conversation
| return totalRightDist; | ||
| } | ||
|
|
||
| float Create::getLeftWheelVel() const { |
There was a problem hiding this comment.
Note that according the Create OI Spec this will report the requested velocity, not a measured value. I would rename this function to getRequestedLeftWheelVel() if you'd like to have that information (same for right wheel). If you want the measured velocity you can compute it above in the onData() function after computing the wheel distances and using dt.
|
Thanks for the PR! See my comments above. I'll have some time next week to test things out before merging. I remember having issues with the Create 1 reporting bogus values for Distance and Angle. I think this issue was fixed with a firmware update (which apparently iRobot no longer supports). What firmware version are you using? |
|
I originally implemented these methods by dividing the distance by dt like you suggested, but I found that this value was really noisy and fluctuated to the point of probably not being very useful. Some kind of filtering might help, but since the Create accelerates pretty quickly, and therefore the requested velocity is usually pretty close to the actual velocity, it probably isn't worth the effort unless someone has a real use for it. If this is okay with you, I'll just rename the methods to reflect what they actually do, and continue to use their values for the JointState message velocities in ca_driver. I have never checked what firmware version my Create has, but the odometry appears to be working correctly, except that very slow rotations are not reported. |
|
Looks good to me 👍 Can you squash those two commits into one and then I'll merge. Maybe it's the fast sample time (15ms) that is causing noisy velocity measurements. |
| @@ -149,6 +151,9 @@ namespace create { | |||
| } | |||
| } // if CREATE_2 | |||
|
|
|||
| totalLeftDist += leftWheelDist; | |||
| totalRightDist += rightWheelDist; | |||
There was a problem hiding this comment.
It may not be a serious issue, but there is potential for a wraparound here if someone is running the robot for the long term resulting in a negative distance.
You can disregard this issue for now, since the same problem exists in the global pose of the robot.
There was a problem hiding this comment.
Since these are floats, the value wouldn't wrap around, it would just become +/- infinity. The bigger issue here is loss of precision. I did some quick tests and it looks like the precision (theoretically, I don't know how precise the measurements actually are) would get to about 1 mm after the robot travelled around 10 km. It wouldn't actually overflow unless it drove beyond the edge of the galaxy.
… distance calculation for the Create 1.
Adds new getters for individual wheel distances and velocities. This also fixes the existing wheel distance calculation for the Create 1, which was not done correctly. This has been tested on the Create 1, but should work fine on the Create 2 also, as the code for calculating the wheel distance is very simple and was already in place.
This change is required to support AutonomyLab/create_robot#26