ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

ROS odometry problems w/ Videre Erratic robot

asked 2011-12-01 14:34:40 -0600

this post is marked as community wiki

This post is a wiki. Anyone with karma >75 is welcome to improve it.


I'm somewhat new to ROS, and robotics in general. Recently I've been trying to set up a Videre Erratic robot equipped with a Hokuyo URG-04LX laser rangefinder for navigation and object recognition. While using slam_gmapping, I noticed there seemed to be some major odometry issues (most evident while turning) that were interfering heavily with building a coherent map, and searching about the problem told me that I should run a test by rotating the robot while the fixed frame in rviz is set to /odom. Apparently the laser scans are supposed to form a crude but legible map, but these were the results:





So yeah, for some reason the laser scan map seems to be rotating as well (when it's not supposed to be, right?) This also mirrors what happens when I turn in place while slam_gmapping is running. This is done using the bare minimum necessary to get a working odometry test: launching erratic_player, running rviz, and then turning the robot (using erratic_teleop, my own basic code, and just manually turning it all led to the same results.) Everything is being done through SSH, but the same problem persists if running directly as well. Here's my erratic_base.launch file:


<node pkg="tf" type="static_transform_publisher" name="link1_broadcaster" args="0 0 0 0 0 0 base_footprint base_link 100" />

<node pkg="tf" type="static_transform_publisher" name="link2_broadcaster" args="0 0 0 0 0 0 base_link laser 100" />

<node name="erratic_base_driver" pkg="erratic_player" type="erratic_player" output="screen" >
    <remap from="odom" to="odom"/>
    <remap from="battery_state" to="battery_state"/>
    <param name="port_name" type="str" value="/dev/ttyUSB0"/>
    <param name="enable_ir" type="bool" value="False"/>
    <param name="odometry_frame_id" type="str" value="odom"/>

<group ns="hokuyo">
    <param name="calibrate_time" type="bool" value="false" />
    <param name="hokuyoLaserModel04LX" type="bool" value="true" />
    <param name="min_ang" type="double" value="-2.08621" />
    <param name="max_ang" type="double" value="2.09234" />

<node name="hokuyo" pkg="hokuyo_node" type="hokuyo_node" respawn="false" output="screen">



Is there any way I can fix this?


edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2011-12-02 01:33:35 -0600

this post is marked as community wiki

This post is a wiki. Anyone with karma >75 is welcome to improve it.

I am running into the same problem, though I am using a skid steer bot. For skid steering, odometry is not very reliable by itself when turning, especially since the wheels slip differently on different surfaces.

I think (hope) using robot_pose_ekf to get a better odom estimate will help. Or, since you already have a laser, try the laser_scan_matcher

edit flag offensive delete link more


laser_scan_matcher seemed to help a lot; it's working pretty great now. Thanks!
SriK gravatar image SriK  ( 2011-12-04 07:43:14 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2011-12-01 14:34:40 -0600

Seen: 541 times

Last updated: Dec 02 '11