conflict odom frame when mapping

[thanhthtran]

Hi, it is me again. I try to do the mapping by using the gmapping or hectormap for the exploration task. However, when i try to run mapping task, A strange things happen for the position of the robot regards to the map as in the picture belows:

Would you have any recommend steps that i could use the mapping by my own ros package please

[thanhthtran]

I think it happens because the mir also always public to default map inside the mir 100. Do you have any idea how i can dissable it please? I need to do the research purpose

[mintar]

You can remove the map -> odom_comb TF frame by adding - odom_comb to the remove_frames parameter list:

https://github.com/dfki-ric/mir_robot/blob/54be543600058477268c93f4be25f51050749de4/mir_driver/launch/mir.launch#L23-L32

You can disable the map topic from the MiR by changing these lines to something like <remap from="map" to="unused_map_from_mir" />, and the same for the map_metadata topic:

https://github.com/dfki-ric/mir_robot/blob/54be543600058477268c93f4be25f51050749de4/mir_driver/launch/mir.launch#L39-L40

[thanhthtran]

Hi, it does not work when i try to remove the odom frame in the launch file as you Mention :( There is the translation and rotation from map->odom at the begining of mapping process ( it should be 000 000).

[thanhthtran]

Do you know how would i stop using the map frame from the mir and replace with my own map frame for mapping ( gmapping) and localization (amcl). I see that the map frame always from the mir

[mintar]

You are right, removing the map frame doesn't work like that. I'll investigate this tomorrow or later this week.

[mintar]

I have created a pull request that adds the option of disabling the map: #6

To test it, please clone the pull request branch into your catkin workspace like this:

git clone -b disable_map https://github.com/mintar/mir_robot.git

Then build as normal and launch the driver as follows:

roslaunch mir_driver mir.launch disable_map:=true

Now, the map topic and map -> odom_comb TF transform should be gone. Please report back if it works.

[thanhthtran]

Hi, sorry for lat response. The mir robot in my working lab is not available until Saturday. I would report back to you asap. Thank you

[mintar]

I just verified this on our own MiR robot and merged the PR. After building mir_robot from source, you can now run it like this:

roslaunch mir_driver mir.launch disable_map:=true

... and both the /map topic and the map -> odom_comb TF transform are gone.

[christenbc]

hello there! I was testing the new version of your package using roslaunch mir_driver mir.launch disable_map:=true while using gmapping and the problem persist.
ç
In addition, if I use /scan as source of gmapping the result is terrible in comparison with using only one laser scanner (either /f_scan or /b_scan), not sure why, maybe you know the reason behing.
Here a sample, left with /scan, right with /f_scan in the same plase:

[mintar]

hello there! I was testing the new version of your package using roslaunch mir_driver mir.launch disable_map:=true while using gmapping and the problem persist.

You mean, the map frame is still published? That shouldn't happen. Are you sure that you're using the newest version from source? Better uninstall the binary version, so that you don't accidentally use it:

sudo apt remove ros-kinetic-mir-robot

In addition, if I use /scan as source of gmapping the result is terrible in comparison with using only one laser scanner (either /f_scan or /b_scan), not sure why, maybe you know the reason behing.

That shouldn't happen. Can you record and upload a rosbag with the following topics, while you're doing the mapping?

- scan
- f_scan
- b_scan
- tf
- tf_static

BTW: I've tested my software with version 1.9.13 of the MiR robot software, but you're using 2.x (as seen from your screenshots). So it's possible there are differences, but I believe they shouldn't be that big.

[christenbc]

The MiR package is installed only in the source, not in binary. And the /map is not published anymore but in /map_mir so there is not conflict with the /map that publishes gmapping.
The map frame does not look to be published anymore by using:
roslaunch mir_driver mir.launch disable_map:=true
rosrun tf tf_monitor

RESULTS: for all Frames

Frames:
Frame: /back_laser_link published by unknown_publisher Average Delay: -4.26853 Max Delay: 0
Frame: /base_footprint published by unknown_publisher Average Delay: -4.14904 Max Delay: 0
Frame: /base_link published by unknown_publisher Average Delay: -4.26848 Max Delay: 0
Frame: /front_laser_link published by unknown_publisher Average Delay: -4.26904 Max Delay: 0
Frame: /imu_link published by unknown_publisher Average Delay: -4.26891 Max Delay: 0
Frame: /odom published by unknown_publisher Average Delay: -4.32968 Max Delay: 0
Frame: bl_caster_rotation_link published by unknown_publisher Average Delay: 0.0309036 Max Delay: 0.0876441
Frame: bl_caster_wheel_link published by unknown_publisher Average Delay: 0.0309049 Max Delay: 0.0876454
Frame: br_caster_rotation_link published by unknown_publisher Average Delay: 0.0309055 Max Delay: 0.0876459
Frame: br_caster_wheel_link published by unknown_publisher Average Delay: 0.0309061 Max Delay: 0.0876464
Frame: fl_caster_rotation_link published by unknown_publisher Average Delay: 0.0309067 Max Delay: 0.087647
Frame: fl_caster_wheel_link published by unknown_publisher Average Delay: 0.0309073 Max Delay: 0.0876476
Frame: fr_caster_rotation_link published by unknown_publisher Average Delay: 0.0309079 Max Delay: 0.0876481
Frame: fr_caster_wheel_link published by unknown_publisher Average Delay: 0.0309085 Max Delay: 0.0876485
Frame: imu_frame published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: left_wheel_link published by unknown_publisher Average Delay: 0.0309092 Max Delay: 0.0876491
Frame: right_wheel_link published by unknown_publisher Average Delay: 0.0309099 Max Delay: 0.0876498
Frame: surface published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: us_1_frame published by unknown_publisher(static) Average Delay: 0 Max Delay: 0
Frame: us_2_frame published by unknown_publisher(static) Average Delay: 0 Max Delay: 0

All Broadcasters:
Node: unknown_publisher 137.068 Hz, Average Delay: -3.2565 Max Delay: 0.0876472
Node: unknown_publisher(static) 1e+08 Hz, Average Delay: 0 Max Delay: 0

Anyways, I still can find on RViz, so somehow saves the frame from the default /map from the mir.
That is the problem. I reopened RViz several times to be sure.
Here I attach the launcher of the gmapping:

<launch>

  <arg name="scan_topic" default="/scan" />

  <node pkg="gmapping" type="slam_gmapping" name="slam_gmapping" output="screen">

    <param name="odom_frame" value="odom"/>
    <param name="base_frame" value="base_link"/>
    <param name="map_frame" value="map"/>

    <!-- Process 1 out of every this many scans (set it to a higher number to skip more scans)  -->
    <param name="throttle_scans" value="1"/>

    <param name="map_update_interval" value="5.0"/> <!-- default: 5.0 -->

    <!-- The maximum usable range of the laser. A beam is cropped to this value.  -->
    <param name="maxUrange" value="5.0"/>

    <!-- The maximum range of the sensor. If regions with no obstacles within the range of the sensor should appear as free space in the map, set maxUrange < maximum range of the real sensor <= maxRange -->
    <param name="maxRange" value="10.0"/>

    <param name="sigma" value="0.05"/>
    <param name="kernelSize" value="1"/>
    <param name="lstep" value="0.05"/>
    <param name="astep" value="0.05"/>
    <param name="iterations" value="5"/>
    <param name="lsigma" value="0.075"/>
    <param name="ogain" value="3.0"/>
    <param name="minimumScore" value="0.0"/>
    <!-- Number of beams to skip in each scan. -->
    <param name="lskip" value="0"/>

    <param name="srr" value="0.01"/>
    <param name="srt" value="0.02"/>
    <param name="str" value="0.01"/>
    <param name="stt" value="0.02"/>

    <!-- Process a scan each time the robot translates this far  -->
    <param name="linearUpdate" value="0.1"/>

    <!-- Process a scan each time the robot rotates this far  -->
    <param name="angularUpdate" value="0.05"/>

    <param name="temporalUpdate" value="0.1"/>
    <param name="resampleThreshold" value="0.5"/>

    <!-- Number of particles in the filter. default 30        -->
    <param name="particles" value="10"/>

<!-- Initial map size  -->
    <param name="xmin" value="-10.0"/>
    <param name="ymin" value="-10.0"/>
    <param name="xmax" value="10.0"/>
    <param name="ymax" value="10.0"/>

    <!-- Processing parameters (resolution of the map)  -->
    <param name="delta" value="0.02"/>

    <param name="llsamplerange" value="0.01"/>
    <param name="llsamplestep" value="0.01"/>
    <param name="lasamplerange" value="0.005"/>
    <param name="lasamplestep" value="0.005"/>

    <remap from="scan" to="$(arg scan_topic)"/>
  </node>
</launch>

(with one laser scanner)

Here is the rosbag
2018-12-07-12-01-53.zip

[mintar]

A few comments:

• Your tf_monitor output shows a delay of -4.3 seconds. This is much too high, it should be as small as possible (definitely below 0.3 seconds). Please synchronize the system time, as described in the README, from the device that is running gmapping (not your smartphone). You probably have to do this once a day.

• Your odometry frame seems to be called odom. In my version of the MiR software, it's called odom_comb. Maybe it's a change from MiR software 1.9 to 2.0 .

• The frames published by the robot state publisher (right_wheel_link etc.) are jumping around. No idea why, I'll have to investigate.

Could you record a rosbag of the same topics as before while you're driving around, but:

• don't disable the map (i.e., run roslaunch mir_driver mir.launch disable_map:=false)
• don't run gmapping

[mintar]

Regarding the jumping frames: Are you perhaps running two instances of the robot_state_publisher? For example, are you running roslaunch mir_description mir_debug_urdf.launch or something like it?

[christenbc]

Regarding the jumping frames: Are you perhaps running two instances of the robot_state_publisher? For example, are you running roslaunch mir_description mir_debug_urdf.launch or something like it?

No, just roslaunch mir_driver mir.launch disable_map:=true

Your tf_monitor output shows a delay of -4.3 seconds. This is much too high, it should be as small as possible (definitely below 0.3 seconds). Please synchronize the system time, as described in the README, from the device that is running gmapping (not your smartphone). You probably have to do this once a day.

I managed to launch gmapping correctly even with this delay, there is no TF OLD data error with this difference. And since I have to synchronize manually, I cannot afford lower than 0.3 s of difference everytime I try to sync.. Is there any command to do it automatically?

Could you record a rosbag of the same topics as before while you're driving around, but:

don't disable the map (i.e., run roslaunch mir_driver mir.launch disable_map:=false)
don't run gmapping

2018-12-13-14-30-23.bag.zip

[mintar]

I've just pushed a commit. Can you try if your problem is solved with the latest version of the software?

Regarding gmapping: I've tried it with the /scan topic, and it indeed doesn't work; you'll have to use the f_scan or b_scan topic instead.

[christenbc]

Regarding gmapping: I've tried it with the /scan topic, and it indeed doesn't work; you'll have to use the f_scan or b_scan topic instead.

Do you think it might be some problem regarding the TF of these sensors in the URDF file? Maybe a misalignment in the TF values is producing that problem.

I've just pushed a commit. Can you try if your problem is solved with the latest version of the software?

Yes, problem solved. Thank you very much for the quick answers.

[mintar]

Do you think it might be some problem regarding the TF of these sensors in the URDF file? Maybe a misalignment in the TF values is producing that problem.

No, that's not the problem. The TFs for the laser scanners don't come from the URDF, they come directly from the MiR, so they are using the calibrated values from the MiR. Also, I've looked at your rosbags, and there seems to be only a very minor misalignment, if at all.

The timing offset is also not the problem; I've manually corrected this in the rosbag, and the problem remains.

By looking closely at the rosbags, it seems that gmapping builds the initial map from the first laser scan it receives (let's say the front scanner) and then attempts too hard to match the second scan (from the back scanner) to features from the first scan. Because there is not enough overlap between the scan areas, gmapping found some false matches during this first alignment, which results in a misaligned map with duplicate walls. I guess gmapping is simply not meant to be used with data from two separate laser scanners. Better just use one.

Yes, problem solved. Thank you very much for the quick answers.

Nice! I'll close this issue then.