BlitherPants's profile - activity

Hello,

I am running ROS Hydro on a Turtlebot 2 (Kobuki + Kinect)

I have been trying to use teleop + gmapping to get a decent map of my cubicled office building, but after slowly perimeter-driving and looping back through several hallways, inevitably, the map will eventually do something absurd like this:

I started with the first two hallways on the right, constantly weaving in and out of cubicles and repeating areas. The picture of those hallways really isn't bad, but when I started exploring the third vertical hallway after 30+ minutes, gmapping suddenly decided to create that horizonal hallway beginning to form on the bottom-left, which is extremely off. Anything after that point in time got progressively worse.

This happens fairly frequently when things seem to be going otherwise well.

The following are my gmapping parameters:

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

  <node pkg="gmapping" type="slam_gmapping" name="slam_gmapping" output="screen">
    <param name="base_frame" value="base_footprint"/>
    <param name="odom_frame" value="odom"/>
    <param name="map_update_interval" value="2.0"/>
    <param name="maxUrange" value="6.0"/>
    <param name="maxRange" value="8.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="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"/>
    <param name="linearUpdate" value="0.2"/>
    <param name="angularUpdate" value="0.1"/>
    <param name="temporalUpdate" value="-1.0"/>
    <param name="resampleThreshold" value="0.5"/>
    <param name="particles" value="100"/>

    <param name="xmin" value="-30.0"/>
    <param name="ymin" value="-30.0"/>
    <param name="xmax" value="30.0"/>
    <param name="ymax" value="30.0"/>

<!--
    <param name="xmin" value="-1.0"/>
    <param name="ymin" value="-1.0"/>
    <param name="xmax" value="1.0"/>
    <param name="ymax" value="1.0"/>
  -->
    <param name="delta" value="0.05"/>
    <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>

I have changed very little from the default turtlebot configuration, besides lowering the linear/angular update, slightly increasing the number of particles, and decreasing the map update interval.

Since I know that a failure in scan matching causes gmapping to rely on odometry, I wonder if my odometry is decent enough. I ran the test suggested in the navigation tuning guide ( http://wiki.ros.org/navigation/Tutori... ):

• I booted up minimal.launch, keyboard_teleop.launch , gmapping_demo.launch, and view_navigation_app.launch
• In rviz, I set the global frame to odom, turned off all costmaps, and put the decay time on /scan to 600s.

I did all the following tests at the lowest teleop speed.

This is the result of performing three rotations in my standard-sized cubicle:

Entrance to cubicle, staring at wall ~5ft away:

Drove straight towards wall:

Circled ... (more)

Hello,

I've been trying to get a decent map of an office building using gmapping on my Turtlebot 2(Kinect), ROS Hydro, Ubuntu 12.04

After posting this a few weeks ago, I had come to the conclusion that my gmapping runs were failing because my i3 laptop CPU wasn't fast enough; while running gmapping with a bagfile, I would see one of the cores jump to 100% usage and sit there for a few seconds. While doing this, I would suppose gmapping was missing vital updates. I somewhat confirmed this by slowing down my bagfiles, and this produced overall better, but still not entirely consistent, maps.

I have now obtained an i7 laptop (Dell Latitude E6410 -- 2.67 GHz x 4) to test with, and I figured this should be fast enough, but I am still not getting consistent results between playing the same bagfile back with the same arguments to gmapping.

For instance, compare these two images:

When creating the bagfile, I used keyboard teleop at the default speed, which is very slow. These two images are generated from the same bagfile, using the same gmapping parameters, and played back ten times slower.

If driving the robot at a slow speed, playing the bagfile back at a tenth of that, and running gmapping on an i7 processor does not produce identical results between identical runs, what does?

What worries and confuses me is that modern computers don't get all that much faster than the one I have. Yet people on here seem to be getting reasonable and consistent results. Am I missing something basic that everyone else understands? Do I need to use a separate lightning-fast desktop computer to run solely gmapping and publish the map and transforms back to the laptop? Is there a bug in gmapping that makes it produce different output between identical runs if the map is big?

My gmapping parameters, by the way, are the turtlebot demo defaults, with slightly reduced particles and increased map update interval:

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

  <node pkg="gmapping" type="slam_gmapping" name="slam_gmapping" output="screen">
    <param name="base_frame" value="base_footprint"/>
    <param name="odom_frame" value="odom"/>
    <param name="map_update_interval" value="100"/>
    <param name="maxUrange" value="6.0"/>
    <param name="maxRange" value="8.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="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"/>
    <param name="linearUpdate" value="0.5"/>
    <param name="angularUpdate" value="0.436"/>
    <param name="temporalUpdate" value="-1.0"/>
    <param name="resampleThreshold" value="0.5"/>
    <param name="particles" value="50"/>
  <!--
    <param name="xmin" value="-50.0"/>
    <param name="ymin" value="-50.0"/>
    <param name="xmax" value="50.0"/>
    <param name="ymax" value="50 ...

Hello,

I am trying to run navigation on a Turtlebot 2 with Kinect on ROS Groovy and Ubuntu 12.04 64 bit.

I have previously been able to run the gmapping demo to create maps just fine, and have been using it to experiment with the "explore" algorithm. My issue thus far as been that, while I have been able to get explore working with 2D costmaps, this is not enough because the Kinect cannot locate some obstacles on the ground and has been crashing into things. I would like to have gmapping also take the bump sensor on the Kobuki into account, and it seems the only reasonable way to do that is by using voxel maps instead of 2d costmaps, as per this question: http://answers.ros.org/question/58111/bumper-in-the-gmapping-costmap-turtlebot/

I have changed my gmapping parameter files to do this. I then run the following:

roslaunch turtlebot_bringup minimal.launch
roslaunch turtlebot_navigation gmapping_demo.launch

After gmapping launches, I immediately get this repeated error:

Registering First Scan
[ INFO] [1378838179.754750699]: Still waiting on map...

[ INFO] [1378838180.763781769]: Received a 320 X 512 map at 0.050000 m/pix

[ INFO] [1378838181.463125972]: MAP SIZE: 320, 512
[ INFO] [1378838181.477537345]: Subscribed to Topics: scan bump
[ INFO] [1378838182.150699492]: Sim period is set to 0.20
[ WARN] [1378838182.179434911]: Trajectory Rollout planner initialized with param meter_scoring not set. Set it to true to make your settins robust against changes of costmap resolution.
[ WARN] [1378838183.486340527]: The origin for the sensor at (-0.09, 0.01, 0.30) is out of map bounds. So, the costmap cannot raytrace for it.
[ WARN] [1378838184.684260669]: The origin for the sensor at (-0.09, 0.01, 0.30) is out of map bounds. So, the costmap cannot raytrace for it.
[ WARN] [1378838185.686235306]: The origin for the sensor at (-0.09, 0.01, 0.30) is out of map bounds. So, the costmap cannot raytrace for it.
[ WARN] [1378838186.686290364]: The origin for the sensor at (-0.09, 0.01, 0.30) is out of map bounds. So, the costmap cannot raytrace for it.

This did not happen before I made my changes, so I must not be setting the voxel maps properly. The following are my param files:

base_local_planner_params.yaml

controller_frequency: 5.0
TrajectoryPlannerROS:
  max_vel_x: 0.50
  min_vel_x: 0.10
  max_rotational_vel: 1.5
  min_in_place_rotational_vel: 1.0
  acc_lim_th: 0.75
  acc_lim_x: 0.50
  acc_lim_y: 0.50

  holonomic_robot: false
  yaw_goal_tolerance: 0.3
  xy_goal_tolerance: 0.15

  goal_distance_bias: 0.8
  path_distance_bias: 0.6
  sim_time: 1.5
  heading_lookahead: 0.325
  oscillation_reset_dist: 0.05

  vx_samples: 6
  vtheta_samples: 20
  dwa: true

costmap_common_params.yaml

origin_z: 0.0
z_resolution: .1
z_voxels: 2


max_obstacle_height: 0.60  # assume something like an arm is mounted on top of the robot
obstacle_range: 2.5
raytrace_range: 3.0
robot_radius: 0.18
inflation_radius: 0.50
observation_sources: scan bump

scan: {data_type: LaserScan, topic: /scan, marking: true, clearing: true, min_obstacle_height: 0.1, max_obstacle_height: 0.6}

# Current bump cloud configuration
bump: {data_type: PointCloud2, topic: mobile_base/sensors/bumper_pointcloud, marking: true, clearing: false, min_obstacle_height: 0 ...