Brian Gerkey's profile - activity

I would guess that there's a problem in your tf tree. The laser callback in amcl is at the end of a tf message filter that will fire when the incoming scan can be successfully transformed into the odom frame. It would seem that that condition is never satisfied.

I suspect that if you try to visualize the laser data in rviz in whatever frame you've specified as the odom_frame for amcl, you won't see any data there, either.

The solution depends on what exactly is wrong in your tf tree. Try visualizing transforms in rviz.

I would guess that your ARM machine is configured to run big-endian. The ROS communication protocol uses little-endian on the wire and as far as I know, roscpp's seralizer doesn't account for running on a big-endian host.

Adding big-endian support to roscpp has been discussed.

But you can likely work around your problem by configuring your ARM machine to run as little-endian instead of big-endian. There's usually a way to do that.

Btw, I would expect rospy to work properly across mixed-endian machines as it's using Python's struct module to implement serialization.

All of those feature should be implementable, with enough work. You would start by deconstructing the code for stageros and augmenting it with the features that you want. Basically, you'd end up writing your own ROS wrapper for libstage, with the extra functionality that you want. I expect that the toughest part will be the graphical selection of robots and execution of ROS code, because that may require modifying libstage's GUI hooks.

Fair warning: you'll be coding in a space that is not well exercised by other people, and so you'll likely end up diving into the libstage code itself to understand what's going on.

Sorry that I can't provide more guidance than that; if I were doing this, I would start by reading the libstage headers to see what's possible.

I'm not sure that I completely understand your use case. But here's something that might be useful: you can selectively filter messages from a .bag. E.g., to get all the non-tf messages, plus only those tf messages that encode a particular transform:

rosbag filter in.bag out.bag 'topic != "tf" or m.transforms[0].header.frame_id == "odom_combined" and m.transforms[0].child_frame_id == "base_footprint"'

I often do something like this to remove the map->odom transform from a bag so that I can test amcl or gmapping.

I'm not sure that I fully understand your use case, but you might try roslaunch args. Here's a launch file that sets two params from arguments:

<launch>
  <arg name="my_integer_param" default="1"/>
  <arg name="my_string_param" default="foobar"/>
  <param name="my_integer_param" value="$(arg my_integer_param)"/>
  <param name="my_string_param" value="$(arg my_string_param)"/>
  <node name="rosplay" pkg="rosbag" type="rosbag" args="play /tmp/mybag.bag"/>
</launch>

Defaults for the args are given, so you can launch it normally:

roslaunch foo.launch

But you can override them on the command-line, e.g.:

roslaunch foo.launch my_integer_param:=42 my_string_param:=barfoo

I don't know whether it's ready for use, but maybe FCL can do what you need.

I usually explain ROS in the following way:

ROS = plumbing + tools + capabilities + ecosystem

1. plumbing: ROS provides publish-subscribe messaging infrastructure designed to support the quick and easy construction of distributed computing systems.

2. tools: ROS provides an extensive set of tools for configuring, starting, introspecting, debugging, visualizing, logging, testing, and stopping distributed computing systems.

3. capabilities: ROS provides a broad collection of libraries that implement useful robot functionality, with a focus on mobility, manipulation, and perception.

4. ecosystem: ROS is supported and improved by a large community, with a strong focus on integration and documentation. ros.org is a one-stop-shop for finding and learning about the thousands of ROS packages that are available from developers around the world.

In the early days, the plumbing, tools, and capabilities were tightly coupled, which has both advantages and disadvantages. On the one hand, by making strong assumptions about how a particular component will be used, developers are able to quickly and easily build and test complex integrated systems. On the other hand, users are given an "all or nothing" choice: to use an interesting ROS component, you pretty much had to jump in to using all of ROS.

Four years in, the core system has matured considerably, and we're hard at work refactoring code to separate plumbing from tools from capabilities, so that each may be used in isolation. In particular, we're aiming for important libraries that were developed within ROS to become available to non-ROS users in a minimal-dependency fashion (as has already happened with OMPL and PCL).

According to REP 3:

"We use the C++03 (ISO/IEC 14882:2003) standard, and are compiler-agnostic. While we mainly develop with gcc, no use of compiler-specific features is allowed without proper use of macros to allow use on other platforms.

Use of C++[0|1]x or tr1 features are only allowed if support for that feature is checked at compile time, and equivalent functionality exists without requiring C++[0|1]x code. A wholesale jump to C++[0|1]x will not happen until all commonly used OS platforms fully support it."

Cleaning up the map as you're suggesting shouldn't hurt localization performance, but probably won't help either. By default, amcl uses a likelihood field model when interpreting laser data; this model has the effect of "blurring" the obstacles in the map, so moving a pixel a bit one way or the other won't have a huge effect.

If you compare performance with both maps, I'd be interested to know the results.

It looks like your robot may have an under-reporting bias in its odometry.

Try this sanity check to get an idea of how just odometry + laser looks.