hector_mapping doesn't update robot pose with insufficient features [closed]
I am trying to use hector_mapping to create a 2D map using a UGV. I wanna first try it in gazebo before testing it on a real robot.
My robot configuration includes an IMU, 2D laser, and data from wheel encoders. I am running robot_pose_ekf
package to update odom->base_footprint
frame transform and want to use hector_mapping to update map->odom
frame transform. Also, I'm using husky robot in gazebo and start the simulation with robot sitting outside willowgarage model. (FYI, I did the same with gmapping and everything just worked fine)
In RViz, the robot doesn't move until I drive the robot inside the building in Gazebo and that's when robot actually starts driving in RViz and starts building a map. But then as soon as I drive the robot outside the building, robot stops updating its pose in RViz and stops building the map. I believe this is caused due to insufficient laser features when I drive outside (only a wall on one side), but also robot_pose_ekf
is updating odom->base_footprint
transform. What could be causing the robot not to move outside the building.
Here's a copy of the launch file I'm using, any advice will be appreciated.
<launch>
<!-- Create slam node -->
<arg name="tf_map_scanmatch_transform_frame_name" default="scanmatcher_frame" />
<arg name="base_frame" default="base_footprint" />
<arg name="odom_frame" default="odom" />
<arg name="pub_map_odom_transform" default="true" />
<arg name="scan_subscriber_queue_size" default="5" />
<arg name="scan_topic" default="/sensor/laser/scan" />
<arg name="map_size" default="2048" />
<node pkg="hector_mapping" type="hector_mapping" name="hector_mapping" output="screen">
<!-- Frame names -->
<param name="map_frame" value="map" />
<param name="base_frame" value="$(arg base_frame)" />
<param name="odom_frame" value="$(arg odom_frame)" />
<!-- Tf use -->
<param name="use_tf_scan_transformation" value="true" />
<param name="use_tf_pose_start_estimate" value="false" />
<param name="pub_map_odom_transform" value="$(arg pub_map_odom_transform)" />
<!-- Map size / start point -->
<param name="map_resolution" value="0.050" />
<param name="map_size" value="$(arg map_size)" />
<param name="map_start_x" value="0.5" />
<param name="map_start_y" value="0.5" />
<param name="map_multi_res_levels" value="2" />
<!-- 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="laser_z_min_value" value="-1.0" />
<param name="laser_z_max_value" value="1.0" />
<!-- Advertising config -->
<param name="advertise_map_service" value="false" />
<param name="scan_subscriber_queue_size" value="$(arg scan_subscriber_queue_size)" />
<param name="scan_topic" value="$(arg scan_topic)" />
<!-- Debug parameters -->
<!-- <param name="output_timing" value="false"/> <param name="pub_drawings"
value="true"/> <param name="pub_debug_output" value="true"/> -->
<param name="pub_map_scanmatch_transform" value="true" />
<param name="tf_map_scanmatch_transform_frame_name" value="$(arg tf_map_scanmatch_transform_frame_name)" />
</node>
<!-- Create extended kalman filter node -->
<node pkg="robot_pose_ekf" type="robot_pose_ekf" name="robot_pose_ekf">
<remap from="robot_pose_ekf/odom" to="/perception/robot_pose_ekf/pose_odom"/>
<remap from="imu_data" to="/sensor/imu/imu_data"/>
<remap from="odom" to="/sensor/wheel_encoder/odom"/>
<param name="output_frame" value="odom"/>
<param name="freq" value="40.0"/>
<param name="sensor_timeout" value="1.0"/>
<param name="odom_used" value="true"/>
<param name="imu_used" value="true"/>
<param name="vo_used" value="false"/>
<param name="debug" value="false"/>
<param name="self_diagnose" value="false"/>
</node>
</launch>
Playing around more with this system, I could confirm that while robot is driving outside the building
hector_mapping
is compensating forodom->base_footprint
transform published byrobot_pose_ekf
(I could seeodom
frame moving in RViz) which shouldn't happen.