ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

TF Setting for Hector mapping (roll/pitch angle)

asked 2012-06-26 20:04:59 -0600

jas gravatar image

updated 2012-06-26 20:09:59 -0600

what is the communication between the following frame?

Base on my understanding, I'll assume the parent-child relationship as below

Parent ----> child

--- ----> map (map_frame)

map ----> nav (odom_frame)

nav ----> base_footprint (base_frame)

base_footprint ----> base_stabilized

base_stabilized ----> base_link

base_link ----> laser

Is this above relationship correct?

Since I'm gonna implement on the UAV...... The problems that i'm getting are the following :

[lookupTransform base_footprint to laser timed out. Could not transform laser scan into base_frame.]

what is the link between nav--->base_stabilized? how to tf it?

what should i set the base_frame to? base_stabilized or based_footprint?

Finally do you have any suggestion/ideas that how all the tf for the large angle change and have roll/pitch movement of the UAV should link together?

(Thank in advanced for your helping) :D

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2012-06-26 22:31:54 -0600

updated 2012-06-26 22:41:34 -0600

Hi, I assume you checked this How-To-Do for setting up the TFs.

what is the link between nav--->base_stabilized? how to tf it?

In cases where you to not have any odometry (UAV and so on) this frame is equal to base_stabilized and you can set it up this way:

<param name="pub_map_odom_transform" value="true"/>
<param name="map_frame" value="map" />
<param name="base_frame" value="base_frame" />
<param name="odom_frame" value="base_frame" />

We also use Hector on UAVs (Octocopters, result video here). The our default Launch configuration is below:

<node pkg="hector_mapping" type="hector_mapping" name="hector_mapping" output="screen">
<param name="base_frame" value="base_stabilized" />
<param name="odom_frame" value="base_stabilized"/>
<param name="output_timing" value="false"/>
<param name="use_tf_scan_transformation" value="true"/>
<param name="use_tf_pose_start_estimate" value="false"/>
<param name="scan_topic" value="scan"/>
<!-- Map size / start point -->
<param name="map_resolution" value="0.025"/>
<param name="map_size" value="2048"/>
<param name="map_start_x" value="0.5"/>
<param name="map_start_y" value="0.5" />
<param name="laser_z_min_value" value="-2.5" />
<param name="laser_z_max_value" value="3.5" />
<!-- Map update parameters -->
<param name="update_factor_free" value="0.4"/>
<param name="update_factor_occupied" value="0.7" />    
<param name="map_update_distance_thresh" value="0.2"/>
<param name="map_update_angle_thresh" value="0.06" />
<param name="pub_map_odom_transform" value="true"/>
<param name="pub_drawings" value="true"/>
<param name="pub_debug_output" value="true"/>
<param name="hector_mapping/pub_map_odom_transform" value="true"/>
<include file="$(find hector_geotiff)/launch/geotiff_mapper.launch" />

Hope this solves your issues.

edit flag offensive delete link more


I've set the setting as above but i've got the result as this link . I was tested out with all the processing thing put on the platform at the stationary point but move in large angle and turning which is as in video... the axis in the rviz drifted around and sometime it move out of the grid..then on the terminal it shown "search angle too large" that it make the map not accurate at all.. can you suggest any idea to fix the problem? (Thanks for your help :D really appreciate it)

jas gravatar image jas  ( 2012-07-01 19:43:17 -0600 )edit

Ok, i see. First of all, the radical movements you are performing in the video are literally extreme and so i do not wonder that the search angle is to large. Just think about a robot which is performing such movements, most likely this robot will get sick and mad ;-)

tlinder gravatar image tlinder  ( 2012-07-01 20:39:27 -0600 )edit

But back to the problem. If a robot needs to perform so fast movements it needs to get also its sensor data fast and precise. Hector and the Hokuyo updated with ca. 30-50 Hz wich is enough for standard UAV movemenst. If the robot needs to move faster you may need a faster scanner or

tlinder gravatar image tlinder  ( 2012-07-01 20:44:53 -0600 )edit

more orthogonal data, i.e. sensor data about your movement from a different source. In cases of UAVs but also UGVs Inertial Measurement Units (IMUs) are one of such sensors. The IMU then is in minimum giving you a orientation estimation. Hector can be feed with such data as a odomentry.

tlinder gravatar image tlinder  ( 2012-07-01 20:50:36 -0600 )edit

Thanks for your information.... i know that it move a bit too fast :D haha but just to say that we are gonna to put it on the UAV, we afraid that it will be too sensitive that it drift outside of the grid....

jas gravatar image jas  ( 2012-07-01 21:03:16 -0600 )edit

sorry to bother you again..just now i'm tested with the resonable speed which we think UAV might behave with shown in this video. but the drifting of the axis is as sensitive as usual,

jas gravatar image jas  ( 2012-07-01 23:55:59 -0600 )edit

i have no idea to solve it...any suggestion which we could stablized the axis...(Thanks for you help :D)

jas gravatar image jas  ( 2012-07-02 00:14:55 -0600 )edit

Ok is see pleas can you make a bag file and run Hector on a regular PC. I have the feeling that your embedded PC which you are using is not really pulling the full 40 Hz of the scanner or is to slow to deal with them. Is there any other process running? If you make the bag available i may test it.

tlinder gravatar image tlinder  ( 2012-07-02 03:39:56 -0600 )edit

Question Tools


Asked: 2012-06-26 20:04:59 -0600

Seen: 3,665 times

Last updated: Jun 26 '12