I'm estimating the localization of a differential drive robot through odometry, using the values from encoders mounted in rear wheels.
However when moving the robot, comparing my odometry with ground truth or odometry sensor from USARSim, the results are not near, sometimes deviating 1 m in a travelled distance of 5 m, and the angle also when there is rotation.
Is there something one should consider about the implementation of encoders of USARSim, to be able to calculate odometry?
Perhaps i'm missing something although I've checked many times the configuration files of the robot and odometry formulas and looked at the implementation of the Odometry sensor.
Can someone please share some insight into this?
Have you checked the noise value? The default under the USARSensor.Encoder section of UDKUSAR.ini is set to be 0.005. I realize that this seems small, but it is added every tick of the simulation. I would try setting your noise to 0 and then repeating your experiments to see if your sensor provides a better match to ground truth.
Yes, the noise value was set to 0 in the relevant files. I have verified that ground truth gives the real "world" coordinates of the bot. And the Odometry sensor(the one from USARSim) gives the location relative to the PlayerStart. But this is not an issue, because one could put the PlayerStart at (0,0), and both Odometry and Ground Truth would give the same values.
However, the entire pose from this Odometry sensor, not just x,y but also theta is different from that of Ground Truth(when the simulation just starts).
Unfortunately, my implementation of odometry(which is based on calculations from encoders values from USARSim messages- and not a sensor) there must be something wrong in it, and couldn't find what it might be,
Also i have plotted the values for ground truth and odometrys(for comparison with ground truth- which values are accurate) in the representation of a map. Ground truth never failed in the sense that it pointed almost all the time to the location the bot was supposed to be at a particular time.
In the trajectorys which were plotted at the same time i could see that although if a trajectory would end where it started(referring to G.T.), odometry eventually would end where it started(i could not observe the full trajectory because it was headed outside the map). So perhaps one could assume that Odometry sensor is giving the right values, but in the wrong direction(the initial angle is not right).
About my attempt to get odometry values from encoders right, perhaps if those encoders values were multiplied by a constant or something like that.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.