Eliminating encoder error when autonomously navigating

asked 2020-08-19 12:11:05 -0500

mertwlf gravatar image

updated 2020-08-19 18:20:18 -0500

So ı am doing an internship, and we are trying to eliminate encoder motor step calculation errors when autonomously navigating an environment with a robot. The robot is jumping on the map visualization software (rviz) because the encoder errors in the robot's motor stack up over time and amcl and encoder data dont match each other.

Because of the pandemic, ı can't access the robot and conduct a test and share its data with you, but ı will try to explain what my supervisor told me about this issue. So when autonomously navigating in an environment, robot uses its encoder data from its two motors as odometry. and it also has a LIDAR laser sensor and using that it gets another location data from amcl topic. The encoders from the robot have a percentage of accuracy error, and when the robot is used longer those errors stack up and become significant enough to cause problems. when the location data coming from encoders and amcl are diffrent, robot seems like its jumping on the map in rviz. We want to fix this issue.

We've been thinking that, amcl topic estimates and corrects robot's location using premade map from gmapping and momentary laser sensor readings. So, If we could publish that data (amcl) directly to any topic we want to, we could possibly solve the jumping issue by giving priority to amcl data over encoder data to correct encoder errors. But there is a problem, amcl topic in ROS only publishes to /tf topic and then the tf topic publishes the data to /move_base which makes the robot go to wherever the user wants in the map.

tf topic subscribes(receives data) from many topics, so we cannot determine which data belongs to /amcl topic from the /tf topic. how could we publish data from /amcl directly to any topic that we would want?(like directly to /move_base topic maybe). I don't have any information about this (ı am not too experienced in ROS) and could not find any resources about it on the internet neither.

Our solution might not be a correct solution or even "a solution" at all, so if you have an alternative solution to this ı would gladly listen to your solution as well.

For those nice people who are willing to answer, if you can explain as simply as possible it would be utmost appreciated.

edit retag flag offensive close merge delete

Comments

You could potentially remap/tf coming out of AMCL to something else (ie: private to the node). That should give you the possibility to do something with the output before relaying it to the global /tf topic.

It's unclear to me what you actually want to do though, so this could be an xy-problem.

gvdhoorn gravatar image gvdhoorn  ( 2020-08-19 13:49:56 -0500 )edit

so ı want amcl's location data to have priority over the robot's motor encoder data and correct it once a specific amount of time (lets say 10 seconds). to do that i have to access the amcl data and use it ı think.

this idea is not mine ı have to say, my supervisor came up with this and told me to research if anyone has done something like this or maybe an alternative solution if ı can find. Which ı cant. That's why ı asked this question. sorry if it is confusing. ı tried to explain it better, ı hope that its more clear what the problem is now.

mertwlf gravatar image mertwlf  ( 2020-08-19 14:59:03 -0500 )edit

so ı want amcl's location data to have priority over the robot's motor encoder data and correct it once a specific amount of time (lets say 10 seconds).

This sounds like something robot_localization could help with.

gvdhoorn gravatar image gvdhoorn  ( 2020-08-20 02:30:36 -0500 )edit

.

tf topic subscribes(receives data) from many topics, so we cannot determine which data belongs to /amcl topic from the /tf topic.

There should only be one source for the MAP<--ODOM frame TF. That is AMCL in your setup. If you have more than one, then you should revisit the configuration. ODOM jumping could be caused by more than one ODOM source - this seems possible if you have a misconfigured robot_localization system running. Otherwise you may simply be having issues with the system that is issuing ODOM from the HW. Maybe it is really inputting ODOM data that is jumping around, and that should be your focus I think.

billy gravatar image billy  ( 2020-08-22 13:34:20 -0500 )edit