# nav2d - Problems getting it working on a real robot

Hi,

I'm trying to get nav2d to work. I have a launch file on my real robot which looks like:

<launch>
<node name="toeminator_ros_bridge" pkg="toeminator_ros_bridge" type="toeminator_ros_bridge_node"/>
<node pkg="tf" type="static_transform_publisher" name="static_transform_publisher3" args="1 0 0 0 0 0 1 base_link base_laser_link 100"/>
<node name="depthimage_to_laserscan" pkg="depthimage_to_laserscan" type="depthimage_to_laserscan" >
<remap from="image" to="/openni2_camera/depth/image_raw"/>
</node>
<node name="openni2_camera" pkg="openni2_camera" type="openni2_camera_node" />
</launch>


and a launch file on the PC to do all the nav2d work which looks like:

<launch>
<!-- Some general parameters -->
<param name="use_sim_time" value="false" />
<rosparam file="$(find nav2d_tutorials)/param/ros.yaml"/> <!-- Start Stage simulator with a given environment --> <!--node name="Stage" pkg="stage_ros" type="stageros" args="$(find nav2d_tutorials)/world/tutorial.world">
<param name="base_watchdog_timeout" value="0" />
</node-->

<!-- Start the Operator to control the simulated robot -->
<node name="Operator" pkg="nav2d_operator" type="operator" >
<remap from="scan" to="base_scan"/>
<rosparam file="$(find nav2d_tutorials)/param/operator.yaml"/> <rosparam file="$(find nav2d_tutorials)/param/costmap.yaml" ns="local_map" />
</node>

<!-- Start Mapper to genreate map from laser scans -->
<!--node name="Mapper" pkg="nav2d_karto" type="mapper">
<rosparam file="$(find nav2d_tutorials)/param/mapper.yaml"/> </node--> <!-- Start the Navigator to move the robot autonomously --> <!--node name="Navigator" pkg="nav2d_navigator" type="navigator"> <remap from="cmd" to="cmd_vel"/> <rosparam file="$(find nav2d_tutorials)/param/navigator.yaml"/>
</node-->

<!--node name="GetMap" pkg="nav2d_navigator" type="get_map_client" /-->
<!--node name="Explore" pkg="nav2d_navigator" type="explore_client" /-->
<!--node name="SetGoal" pkg="nav2d_navigator" type="set_goal_client" /-->

<!-- Start the joystick-driver and remote-controller for operation-->
<node name="Joystick" pkg="joy" type="joy_node" />
<node name="Remote" pkg="nav2d_remote" type="remote_joy"></node>

<!-- Pioneer model for fancy visualization -->
<!-- Comment this out if you do not have the package 'p2os' available! -->
<include file="$(find p2os_urdf)/launch/pioneer3at_urdf.launch" /> <node name="front_left_wheel" pkg="tf" type="static_transform_publisher" args="0 0 0 0 0 0 p3at_front_left_hub p3at_front_left_wheel 100" /> <node name="front_right_wheel" pkg="tf" type="static_transform_publisher" args="0 0 0 0 0 0 p3at_front_right_hub p3at_front_right_wheel 100" /> <node name="back_left_wheel" pkg="tf" type="static_transform_publisher" args="0 0 0 0 0 0 p3at_back_left_hub p3at_back_left_wheel 100" /> <node name="back_right_wheel" pkg="tf" type="static_transform_publisher" args="0 0 0 0 0 0 p3at_back_right_hub p3at_back_right_wheel 100" /> <!-- RVIZ to view the visualization --> <node name="RVIZ" pkg="rviz" type="rviz" args=" -d$(find nav2d_tutorials)/param/tutorial1.rviz" />

</launch>


I assume (correct me if the assumption is incorrect) that if I bring both these up and use to joystick to point the robot fwd then it will just start roaming around building a map, as it does in the Stage tutorials?

Two issues I am seeing:

1) I am getting a TF tree disconnect between the map and the laser - showing in rviz as:

Transform [sender=unknown_publisher]
For frame [base_laser_link]: No transform to fixed frame [map]. TF error: [Could not find a connection between 'map' and 'base_laser_link' because they are not part of the same tree.Tf has two or more unconnected trees.]


My TF tree is here: https://www.dropbox.com/s/cg8zrudnblffj3h/frames.pdf?dl=0

2) Console is reporting:

 [ERROR ...
edit retag close merge delete

Sort by » oldest newest most voted

Please note that the topics "/cmd" and "/cmd_vel" are different (and should be so). Your remapping on the Navigator is most likely wrong. I assume this causes your type-mismatch.

As a side note: I don't know how much ressources you have on the robot and how your robot and PC are connected, but you should consider moving only the Operator over to the robot and then use the /cmd topic (of type "nav2d_operator/cmd") on your ros-bridge. This should cause much less traffic on your bridge and also move the (somewhat critical) obstacle avoidance directly on your robot.

Edit: GetMap, SetGoal and Explore are helper nodes to call the navigator's actions.You need SetGoal if you want to send goal positions with RVIZ.

If your costmap is not updated, it's always good to check the sensor height first. The local costmap has a min_obstacle_height and a max_obstacle_height (costmap.yaml), and the sensor height must be in between. (Use RVIZ to check the height of the laser scan line.)

more

Thanks I will create a new message to the bridge to accept these messages and let you know. The robot's core is a Raspberry Pi 2 - should have enough power to move the Operator across. Will try that once I get the rest working

( 2015-08-17 02:48:28 -0500 )edit

Ok dumb question - how do I measure the laser scan height in rviz. In reality it's 22cm of from the floor. I've not touched the costmap.yaml file. Defaults are:

obstacle_range: 4.0 min_obstacle_height: 0.0 max_obstacle_height: 2.0 raytrace_range: 4.5

Thanks

( 2015-10-20 16:32:47 -0500 )edit

As a simple check, you can just turn the camera a little so you can see if the laser points are roughly 22cm above the ground. You do not worry about one or two cm, but whether your scans are maybe 22cm beneath the floor. This is often caused by errors in the transformations.

( 2015-10-21 03:22:03 -0500 )edit

Okay - that's what I though. At the moment it's on the floor. Will check the transforms and revert

( 2015-10-21 06:43:08 -0500 )edit

That's done the trick - the static transform was incorrect. cost map has started picking up the data...now to get the robot to actually think about moving!

( 2015-10-26 06:10:18 -0500 )edit

Two issues:

• Your tf tree is disconnected, into the robot frames on the left and the navigation related frames on the right. There should be a connection between base_link and odom (see this random example I googled) that normally is provided by either your mobile base controller directly, or via another node like robot_pose_ekf. The latter case if frequently used when the odometry transform is estimated from multiple sources of information, such as encoders plus gyros.
• Your ros_bridge expects a standard geometry_msgs/Twist message message type for the "cmd_vel" topic, but the publisher it is connected to appears to publish a nav2d_operator/cmd message type instead. This can be fixed by making sure that your publisher also publishes a geometry_msgs/Twist message.
more

Thanks - The bridge is supposed to be sending out an odom transform - not sure what's happened to it. Will check

( 2015-08-17 02:49:36 -0500 )edit