AMCL doesn't cope well with drift
Bug #669304 reported by
Steven Martin
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Collaborative Mobile Robotics |
New
|
High
|
Unassigned | ||
Bug Description
After significant testing the AMCL configuration/
I have tested a variety of parameters but have not been able to achieve reliable operation when combined with autonomous path planning. When driving manually without significant rotation it seems to work pretty well. However when using the navigation stack the repeated rotations of the robot (could be attributed to poor local path planning) cause the robot to become lost in the environment. Another possible cause could be attributed to the limited range of the laser scanner as compared with the parameters which are tuned for the PR2
Documentation is not particularly useful in understanding the significance of each of the parameters.
| Changed in cmr: | |
| importance: | Undecided → High |
| milestone: | none → 0.2 |
Revision history for this message
| Steven Martin (steven-martin-qut) wrote | #1 |
To post a comment you must log in.
So I looked into this a bit more and it appears that the iCreate does not have any wheel encoders. Which explains a lot of what I am seeing. It just assumes that it is moving at the commanded speed which it is given. This however will vary with battery voltage and the surface which is it driving on. This is particularly bad for slow speed rotations.
Possible solutions.
- Combine commanded speed with laser scan matching (kalman filter) to produce better result for odometry (really this is what AMCL is meant to do)
- Develop a better model for the odometry taking into account the voltage, current draw and possibly online calibration from laser scanner.