Hi Sven,

I suggest that you check out the navigation tutorials 
http://www.ros.org/wiki/navigation/Tutorials they also cover basic robot 
setup, in particular this one 
http://www.ros.org/wiki/navigation/Tutorials/RobotSetup/TF is designed 
for what you are doing. 

For reference our default system is the following. 
amcl  publishes the transform from map to odom
wheel_odometry publishes the transform from odom to base (where base is 
the base of the robot)
a static transform publisher publishes the transform from base to laser  
(assuming the laser is rigidly mounted to the base)

I've also responded inline below. 

Tully

Sven Olufs wrote:
> Hi there,
>
> I got some questions to tf nodes in ROS. After studding the wiki, tf & 
> navigation tutorials I am a bit confused about the proper configuration. 
> My story is rather simple: we got a robot (differential drive) and a 
> hokuyo laser scanner on top that will be used for localisation and 
> navigation. My current configuration of the tf nodes is like the:
>
> /map (Map Server)
> /map/odom (Robot wheel encoders)
> /map/odom/scan (Hokuyo)
>
> Using rviz I can see the laser scanners tf Node “running around” on the 
> map. Now I like to use the amcl module to update the robot pose 
> according to the map. As far as I understood (and analyzing the amcl 
> code) it seems like the amcl module creates an own node (default map) 
> with the pose and also updates the odom tf node.
>
> In the tf tutorial (video No 2) spotted a configuration like this:
>
> /map
> /odom
> /base
> /base/laser
>
> I assume that the “base” tf node contains also the pose maintained by 
> the amcl module.
>   
When thinking about a set of coordinate frames the transforms which are 
published are the differences between the two frames it connects.  An 
individual frame does not have any inherent information but there is 
information about how to get from one frame to another. 

Your assumption of having amcl data in the base pose is incorrect.  If 
you want to traverse a large tree you will have to compute the product 
of all the transforms between frames in between. For example if you want 
to get the transform from map to laser it is map->odom * odom->base * 
base->laser.  You can see this visually using the tf utility 
view_frames.  `rosrun tf view_frames` or with the tf plugin in rviz. 
> Now we have a logic paradox: When I try to use the tf nodes like this, 
> the amcl module complains that there is no path from “scan” to “base” 
> since “base” is created my the amcl module. Well I can create a fake 
> static base node, but then we have two publishers on “base”.
>
> I also do not understand why the amcl updates the “map” tf node by 
> default since “odom” is connected to it and both modules uses global 
> coordinates (resulting to bogus coordinates for the “scan” node). And 
>   
There's no such thing at global coordinates, everything is in a 
coordinate frame.  To get data from one frame to an other you must 
transform it appropriately.  Say your laser observes something in the 
the laser frame, if you want it in the map frame you must apply the 
transform from laser to base, then base to odom, then odom to map.  
(This is what tf does for you if you ask it to transform data in the 
laser frame into the map.)
> why is the amcl module updating the “odom” tf node anyway ? Don’t we 
> have two publishers on the same tf node topic ? rviz shows me that the 
> coordinates of “odom” is jumping when I use the amcl module like this. 
> The only way to overcome this is right now to use a separate “pose” tf 
> node that is not connected to “odom” tf node.
>   
When doing things like obstacle avoidance and other things it is 
critical for the robot to have a locally consistent coordinate frame.  
This is the odom frame.  It is designed to be locally consistent, in 
time and space but is expected to drift.

amcl publishes the correction to the odom frame to correct for this 
drift.   The jumps you are seeing are amcl's updates to correct for this 
drift.  If they are large and frequent it suggests that your odometry is 
poor. 

> But then I do I transform the “scan” to “pose” since there is no 
> connection within the tree ?
>
> We I can do this
>
> /map
> /map/odom
> /map/odom/pose
> /map/odom/scan
>
> But face then the same bogus coordinates for pose since “odom” is 
> subtracted from “pose” and both are absolute
>
> How do I avoid this paradox ? And there is no information about this in 
> the tf oder navigation tutorial
>
> Thanks in advance
>
> Sven
>
> P.S. The video tutorials are great :)
>
>