Ernest's profile - activity

My quick question is: can we change the map_start_x and map_start_y parameters of the hector_mapping node once it's running? Or do we need to restart the node with those parameters?

Thank you in advance,

Ernest

Hi,

So, this is an odd one. I got the following "good" visualisation of hector_mapping in RVIZ (http://i.imgur.com/lYppRzn.png (imgur link) because I need 20 karma to attach an image..) by running this simple launch file:

<?xml version="1.0"?>
<launch>
    <node pkg="hector_mapping" type="hector_mapping" name="hector_mapping" output="screen">

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

    </node>

    <node pkg="tf" type="static_transform_publisher" name="base_to_laser_broadcaster" args="0 0 0 0 0 0 /base_link /laser 100" />


</launch>

I must have changed something because when I re-ran re-ran the hector_mapping node and the visualisation I got http://i.imgur.com/yoiXaUy.png (this) - the base_link frame seems to be moving fine but I don't see the map (what was in grey on the first screenshot) anymore.

Any idea why the map isn't being displayed anymore?

Thanks in advance,

Ernest

Some extra info:

tf_monitor returns this:

 Frame: /base_link published by
 /hector_mapping Average Delay:
 0.0366189 Max Delay: 0.0540163 Frame: /laser published by
 /base_to_laser_broadcaster Average
 Delay: -0.0994484 Max Delay: 0 Frame:
 /scanmatcher_frame published by
 /hector_mapping Average Delay:
 0.0367215 Max Delay: 0.0540429

 All Broadcasters: Node:
 /base_to_laser_broadcaster 10.1691 Hz,
 Average Delay: -0.0994484 Max Delay: 0
 Node: /hector_mapping 80.7814 Hz,
 Average Delay: 0.0366702 Max Delay:
 0.0540429

Hi,

I'm setting up a hector_mapping node. My simple launch file sets up a static base_link -> laser transform:

<node pkg="hector_mapping" type="hector_mapping" name="hector_mapping" output="screen">

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

</node>

<node pkg="tf" type="static_transform_publisher" name="base_to_laser_broadcaster" args="0 0 0 0 0 0 /base_link /laser 100" />

When I run it, I get the following error, but only once:

lookupTransform base_link to laser timed out. Could not transform laser scan into base_frame.

Does that mean there is one lookupTransform call for which the tf wasn't set up, but then it found it?

Thanks in advance,

Ernest

Hi,

I'm trying to write a node in Python that subscribes to a topic and listens to another.

One way I have managed to do that is by issuing the publish command in the callback. However, this approach only lets my node publish when a new message comes in from the topic it is subscribed to. So my publisher is "constrained" to the subscribed topic's frequency.

Is there an other way to do this? I've looked online and couldn't find anything.

Thanks in advance, Ernest

Hi,

To run move_base (part of the Navigation stack), I need to provide an odom topic which move_base can subscribe to.

I use hector_mapping for odometry on my robot, and have set the pub_map_odom_transform option of my hector_mapping node to true to publish a tf between the map & the odom frames.

Is it possible to output odom as a topic from hector_mapping? If not, how should I go about constructing odom messages from hector_mapping topics? (I have a hunch that this is possible seeing as a tf from map to odom is available..)

Thank you in advance,

Ernest

Edit: Alternatively, is there a way in move_base to use the incoming map->odom tf for odometry (as opposed to the odom topic) ?

In certain situations, my LiDAR's platform is subject to sharp motions which hector_mapping cannot handle. In this question, I asked Stefan Kohlbrecher, (one of) the author(s) of the hector_mapping package, what causes this.

Following his comments, I would like to know how to save the full internal state of hector_mapping to restart it with a valid state in case it fails.

Thank you very much,

Ernest

Hi,

I'm using move_base to generate paths based on a map & odom generated by hector_mapping. The below rviz screenshot sums up my problem quite well: essentially as the new (middle) obstacle appeared in my LiDAR's view, the global path (in green) doesn't update. It seems properly inflated (blue).

So what happens is that move_base keeps going onto the global path until it arrives too close to the obstacle, and then it backs up (recovery mode).

Any ideas why my global path isn't changing?

My yamls:

   global_costmap:

  global_frame: /map
  robot_base_frame: /base_link 
  update_frequency: 1.0

  static_map: false
  rolling_window: true

  width: 26
  height: 26
  resolution: 0.025

  map_type: costmap


local_costmap:
  global_frame: /odom
  robot_base_frame: /base_link 
  update_frequency: 1.5
  publish_frequency: 1.5
  static_map: false
  rolling_window: true
  width: 20.0 
  height: 20.0 
  resolution: 0.05

  map_type: costmap

I am trying to tackle the following warning when running Navigation:

[ WARN] [1368081077.201722266]: Could not get robot pose, cancelling reconfiguration
[ WARN] [1368081077.401579990]: Costmap2DROS transform timeout. Current time: 1368081077.4015, global_pose stamp: 136.4000, tolerance: 0.3000

The transform timed out because the time & the pose stamp are extremely different. Are they in different time epochs? If so, how can that be solved?

Thanks,

Ernest

Hi,

I'm providing odometry to move_base through a map->odom tf provided by hector_mapping.

This means that my odom topic is empty, which I think is the cause of a host of warnings, such as:

[ WARN] [1368064440.957099892, 700.300000000]: Costmap2DROS transform timeout. Current time: 700.3000, global_pose stamp: 700.0000, tolerance: 0.3000

[ WARN] [1368064440.957199828, 700.300000000]: Could not get robot pose, cancelling reconfiguration

I have managed to make move_base ignore the lack of odom messages by going to costmap_2d_ros.cpp of the costmap_2d package and doing this (warning: this is a bad hack!):

    // check global_pose timeout
if (current_time.toSec() - global_pose.stamp_.toSec() > transform_tolerance_) {
  ROS_WARN_THROTTLE(1.0, "Costmap2DROS transform timeout. Current time: %.4f, global_pose stamp: %.4f, tolerance: %.4f",
      current_time.toSec() ,global_pose.stamp_.toSec() ,transform_tolerance_);
  return true;
//  return false;
}

My question: is this a dangerous workaround? Is there a better way to tell move_base to ignore the odom topic?

Thank you in advance,

EDIT

Sometimes, the two times are very different, which leads me to think that they might be in different time epochs:

Costmap2DROS transform timeout. Current time: 1368081077.4015, global_pose stamp: 136.4000, tolerance: 0.3000

When this happens, the quick hack described above doesn't help..

Hi,

I've declared my robot's footprint in my common costmap params:

footprint: [[-0.7,-0.45], [0.70,-0.45],[0.70, 0.45],[-0.70, 0.45]]

and so I haven't set inscribed or circumscribed radii, because those can be figured out from my footprint.

Nevertheless, when I run move_base I get this warning:

[ WARN] [1367908257.219539023, 2.000000000]: You have set an inflation radius that is less than the inscribed and circumscribed radii of the robot. This is dangerous and could casue the robot to hit obstacles. Please change your inflation radius setting appropraitely.

Any idea why? Can I safely ignore this warning?

Thanks,

Ernest

Hi,

I've noticed that when sharp pose changes occur on my laser frame, the following error sometimes appears & kills hector_mapping:

SearchDir angle change too large

I was wondering: what exactly causes this, and if it is indeed linked to an unfeasible change of pose or laser scan data, what are the precise constraints on hector_mapping?

Thank you very much!

Ernest

Hi, I'm trying to set a good scan_subscriber_queue_size for my hector_mapping node. According to the wiki:

~scan_subscriber_queue_size (int, default: 5) The queue size of the scan subscriber. This should be set to high values (for example 50) if logfiles are played back to hector_mapping at faster than realtime speeds.

I'm not sure what logfiles being played back means; my node just take in scans from hokuyo_node, so is it ok to leave the default value of 5?

Thanks,

Ernest