mjedmonds's profile - activity

/global_localization is what I was looking for. Thanks! Also this answer from Humpelstilzchen explains why

I'm using AMCL with a Velodyne VLP-16. I'm using hector_slam to build the map, saving the map with map_server.

I'm using an IMU and wheel encoder velocities (twist messages) to fuse with robot_localization for odometry and the odom->base_link (base_footprint in my case) transform.

I want to use AMCL for global localization, but I'm having problems. AMCL is not aligning the laser scan with the prebuilt map, leading to incorrect global localization. I've attached a screenshot (if you rotate the laserscan by ~90 degrees clockwise, you get the about the correct alignment.

The only potential problem might be that the laserscan is flat in the velodyne's frame, which is ~0.35m above the ground. Could that be an issue for AMCL?

I'm not very sure where to start debugging this, so any tips/hints/suggestions/requests for more info would be appreciated. I didn't want to dump my entire config in the first post, but I'm more than willing to.

And my AMCL config is pretty standard:

<launch>
<node pkg="amcl" type="amcl" name="amcl">
  <!-- Publish scans from best pose at a max of 10 Hz -->
  <param name="odom_model_type" value="omni"/>
  <param name="odom_frame_id" value="odom" />
  <param name="base_frame_id" value="base_footprint" />
  <param name="global_frame_id" value="map" />
  <param name="use_map_topic" value="true" />
  <param name="odom_alpha5" value="0.1"/>
  <param name="transform_tolerance" value="0.2" />
  <param name="gui_publish_rate" value="10.0"/>
  <param name="laser_max_beams" value="30"/>
  <param name="min_particles" value="500"/>
  <param name="max_particles" value="5000"/>
  <param name="kld_err" value="0.05"/>
  <param name="kld_z" value="0.99"/>
  <param name="odom_alpha1" value="0.2"/>
  <param name="odom_alpha2" value="0.2"/>
  <!-- translation std dev, m -->
  <param name="odom_alpha3" value="0.8"/>
  <param name="odom_alpha4" value="0.2"/>
  <param name="laser_z_hit" value="0.5"/>
  <param name="laser_z_short" value="0.05"/>
  <param name="laser_z_max" value="0.05"/>
  <param name="laser_z_rand" value="0.5"/>
  <param name="laser_sigma_hit" value="0.2"/>
  <param name="laser_lambda_short" value="0.1"/>
  <param name="laser_lambda_short" value="0.1"/>
  <param name="laser_model_type" value="likelihood_field"/>
  <!-- <param name="laser_model_type" value="beam"/> -->
  <param name="laser_likelihood_max_dist" value="2.0"/>
  <param name="update_min_d" value="0.2"/>
  <param name="update_min_a" value="0.5"/>
  <param name="resample_interval" value="1"/>
  <param name="transform_tolerance" value="0.5"/>
  <param name="recovery_alpha_slow" value="0.0"/>
  <param name="recovery_alpha_fast" value="0.0"/>
</node>
</launch>

Yes, thank you. Makes sense.

If I properly set the initial pose, it works, but this seems counterintuitive to me. The point of global localization is

If I properly set the initial pose, it works, but this seems counterintuitive to me. The point of global localization is

Less than 2 meters. Should I travel farther to get a global alignment?

AMCL not localizing in pre-built map I'm using AMCL with a Velodyne VLP-16. I'm using hector_slam to build the map, savi

AMCL not localizing in pre-built map I'm using AMCL with a Velodyne VLP-16. I'm using hector_slam to build the map, savi

It should be the value of the odometry topic from rtabmap, which is /rtabmap/odom if you have rtabmap namespace'd, or /odom if you don't (your control-new.launch has it namespace'd).

My main point is that you should try to understand the hierarchy of your setup and set the proper value.

The numbering for each fused source should start at 0, as the robot_localization documentation indicates. So if rtabmap is your own odometry source, you should set it be 'odom0' and 'odom0_config'. However, you said you were also integrating wheel odometry, which can be a twist or odometry input.

Yes, that sounds correct, though you know more about your exact configuration than I do.

Yes, this is a fundamental change to the odometry/filtered topic, so you will have to rerecord your bags. Any change to the robot's configuration will require a rerecording of any bags.

Not a problem, put the odom configuration in between the <node> tags for robot_localization in the file you linked

No, you set those parameters in the robot_localization launch file that's already fusing your IMU and wheel odometery. See an example robot_localization launch file from the package.

with a corresponding config like this:

<rosparam param="odom1_config">[true, true, false, false, false, true, false, false, false, false, false, false, false, false, false]</rosparam>

You'll add a line like this:

<param name="odom1" value="rtabmap/odom"/>

It seems more appropriate to have bottom-out and tipping avoidance be part of your navigation planner, but I'm not an expert on the topic.

However, the way I use robot_localization, I fuse the IMU with the wheel odometry and visual odometry from rtabmap. See the robot_localization package

First, you need to add a calibrated tf between your base_link and your realsense_frame. You can manually measure this and verify it. The robot needs to know where the camera is relative to its other parts.

You may also want to look at the robot_localization package to fuse your rtabmap odometry with the IMU and wheel odometry.

Hi,

I'm writing a dynamic footprint node, which projects a robot's arm state down onto the 2d polygon for the footprint of the robot. This is based on a rectangular project of the robot's arms with the state coming from tf. The goal of this is to conservatively plan with the robot's arms moving around (e.g. a static rectangle is not a sufficient definition for the robot's footprint).

My concern is this: even with the arms projected down, is the "lethal" point of the robot still only considered the midpoint of the robot, or is any point inside of the footprint polygon that is inflation_radius distance away considered lethal? Here's a mockup picture of what I'm talking about. Is the lethal point a constant in the center of the footprint polygon, or an area based on the shape of the footprint polygon?

Thanks!

Hi,

I'm working with a mobile robot trying to give it localization. I am using visual odometry (rtabmap) and was planning on using diff_drive_controller to give odometry from cmd_vel topics. The two would be coupled (with IMU data from the base as well) using robot_pose_efk. I've already recorded a live rosbag which contains all the of the camera topics, cmd_vel, and raw IMU data.

Here's my question: how can I minimally launch ros_control such that diff_drive_controller will work. I really don't need anye of the other features of ros_control (or so I think, I might be very mistaken). I just need for diff_drive_controller to output odometry messages from cmd_vel topics. The goal is that all of this ends up in robot_pose_efk.

Thanks.

Edit: Upon looking at the diff_drive_controller code, I'm not sure that it will work. My robot (a baxter mobility base) is already publishing the twist and subscribes to the cmd_vel from the joystick. Here's a list of the topics: http://mbsdk.dataspeedinc.com/ROS_API

So, it looks like I'm looking for a package which can convert twist + wrench messages into odometry, or I need to write such a node.