RGBD + Lidar for SLAM and autonomous navigation

[Blupon]

Hi !

I'm an intern working on a robot designed to compete at the ERL Emergency Robots.

I chose to work with rtabmap_ros since it offers software adapted to outdoor navigation (stereovision)  and obstacle avoidance (so, first of all, thanks for this nice piece of software ! ).

Still, I'm having difficulties using the launch file available on ROS wiki - Setup RTAB-Map on Your Robot !, the one that uses hector_mapping to generate odometry thanks to lidar collected data.

I'm aware of a very similar post existing on this forum, but I couldn't solve my issues thanks to the information it holds.

Hardware

At the moment, I'm trying to obtain SLAM and autonomous navigation with a lab made robot that is equipped with:
   - an Asus Xtion RGBD camera
   - a hokuyo UTM-30LX lidar

Since the robot is homemade, I have designed an URDF (zerobin link) to publish:
   - base_footprint
   - base_link
   - laser_link

which seems to be working (the TF appear as expected in RVIZ when I launch everything).

Edited demo_hector_mapping.launch

Here is the launch file I'm using for rtabmap, where, as told in the very similar post, I edited the following information:

          param name="scan_topic" value="/scan"
 
          <remap from="scan" to="/scan"/>
          <remap from="rgb/image"       to="/camera/rgb/image_rect_color"/>
   <remap from="depth/image"     to="/camera/depth_registered/image_raw"/>
   <remap from="rgb/camera_info" to="/camera/rgb/camera_info"/>

 roslaunch sequence

Here are the different shell commands I'm using to launch everything, with the logs associated with it:

1. roslaunch openni2_launch openni2.launch depth_registration:=true
       
      logs here

2. rosrun urg_node urg_node

      logs here

      This is to get the /scan from the LIDAR, the ERRORs shouldn't be the real problem since the laser scan appears (though being slow) in RVIZ

3. roslaunch erl_ugv_description beta.launch

     launch file here
     logs here

     the ERROR shouldn't be problematic, according to this ROS Q&A

4. roslaunch rtabmap_ros demo_hector_mapping.launch rtabmap_args:="--delete_db_on_start" rviz:=false rtabmapviz:=false

       launch file is the demo_hector_mapping.launch I edited as said earlier
       logs here

       NB: rviz and rtabmapviz are set to 'false' because I launch RVIZ on a remote PC

Once all of these have been launched, I can obtain the following view_frames frames.pdf :



There are several laser static tf because I think the one from my urdf is useless, one of them (if I remember well) is named in order to comply with rtabmap_ros need (as asked for on rtabmap ROS wiki), the last one...well I don't exactly remember
for what node I made a tf with such a name but I keep it just to be sure not to break something !

So now, my so-called question:

    - why isn't rtabmap working ? I don't have a /map, nor a TF(/map -> /odom), nor the points clouds.
    - is rtabmap_ros supposed to provide the TF( /odom -> /base_footprint) in this configuration ? because I'm lost on what node is supposed to give it, since here, we expect odometry from hector_mapping.


Thanks !

[matlabbe]

Hi,

According to this post, hector_mapping will publish /hector_map -> /scanmatcher_frame. rtabmap will publish /map -> /scanmatcher_frame. In the log where rtabmap is started, there should be more log messages from rtabmap, is this the complete log? If rtabmap doesn't receive any inputs, it should output warnings on the terminal (on ros kinetic or latest source version).

Here is the tf tree with demo_hector_mapping.launch:

$ roslaunch rtabmap_ros demo_hector_mapping.launch
$ rosbag play --clock demo_mapping_no_odom.bag
$ rosrun tf view_frames

cheers,
Mathieu

[Blupon]

Hi,


Thanks for your answer. Yes, that was the complete log.


Since I was trying this on ROS Indigo, I'm going to try it again on ROS Kinetic, I'll keep the forum posted !

[Blupon]

Hi !

 RTABMap launching fix

First of all, the failure to launch rtabmap seems to be due to one boolean in the demo_hector_mapping.launch:

use_sim_time should be set to False, and not True, as it is with the launch file available on the wiki tutorial page.

 Wrong TF tree in view_frames on Kinetic, but not Indigo

After correcting the use_sim_time boolean, I could see a strange difference when launching rtabmap on Indigo and Kinetic using:

- the same modified demo_hector_mapping.launch
- the same URDF descriptor
- the same launch file for the URDF/robot description with robot_state_publisher
- the same launching sequence:
    1. roslaunch openni2_launch openni2.launch depth_registration:=true
    2. rosrun urg_node urg_node
    3. roslaunch erl_ugv_description beta.launch
    4. roslaunch rtabmap_ros demo_hector_mapping.launch rtabmap_args:="--delete_db_on_start" rviz:=false rtabmapviz:=false

 Results for Indigo

rtabmap launch complete log here

We get:

- [GOOD] the expected tf tree using the command line view_frames (see image below)
- [BAD] a lack of topics we get in Kinetic, including /rtabmap/cloud_ground and /rtabmap/cloud_obstacles. I thought those would need a dedicated nodelet launch in the demo_hector_mapping.launch (like the one you suggest here), but it doesn't since on Kinetic those topics are published without any addition to RTABMap launch file.

 Results for Kinetic

complete rtabmap launch log here

We get:

- [GOOD] topics we couldn't get in Indigo, including /rtabmap/cloud_ground and /rtabmap/cloud_obstacles
- [BAD] a totally wrong (and unexpected) tf tree thanks to the command line view_frames (see image below). I say unexpected because the link between /base_footprint and /base_link is defined by the URDF and does work/exist on the Indigo computer trial.




The only other difference I can think of is an error associated with joint_state_publisher dying for some reason when I launch beta.launch, responsible for the robot description (but again, this shouldn't be a real issue according to this ROS Q&A). I only get this error on the Indigo laptop, not on Kinetic (where the tf tree is wrong).

 Additional question

- How to check that RTABMap actually uses lidar odometry to build its map ?
- I could read several [INFO] [ <TIME> ]: Creating 1 swatches shell messages when RTABMap was running, what does that mean ?
- According to your first answer, RTABMap could not work the same way depending on the ROS distribution in use, where can I find details about those possible differences ? (especially between Indigo and Kinetic in my case )


Thanks for your dedication & answers !

[matlabbe]

Hi,

Yes, use_sim_time=true should only be used with a ros bag (for which we should use the clock in it).

rtabmap and rtabmap_ros binaries have not the same version on Indigo and Kinetic, so output topics may differ. Not sure yet if I will update Indigo binaries yet, to not break systems/robots still on Indigo. However, it is possible to build latest code from source on Hydro/Indigo/Jade/Kinetic (Lunar not tested yet) so that rtabmap works exactly the same on all platforms. For your test on Kinetic, the lack of TF published by the robot_state_publisher is a problem maybe with the URDF not compatible both at the same time with Indigo and Kinetic. It is not rtabmap related, there a is related migration instructions on this page for Kinetic about that.

The map (grid_map) is created with laser scans if parameter "Grid/FromDepth" is false. For convenience, when subscribing to a laser scan, if Grid/FromDepth is not set, it is automatically set to false, you should see this warning:

[ WARN] [1501592218.499590190]: Setting "Grid/FromDepth" parameter to false (default true) as 
"subscribe_scan" or "subscribe_scan_cloud" is true. The occupancy grid map will be constructed from laser 
scans. To get occupancy grid map from cloud projection, set "Grid/FromDepth" to true. To suppress this 
warning, add <param name="Grid/FromDepth" type="string" value="false"/>

On Indigo binaries, there were two output topics: "proj_map" and "grid_map", the second was created from laser scans.

For the "Creating 1 swatches", don't know what it is. You can use rqt_console to see which node is printing this.

cheers,
Mathieu