Hi Tully,

well that's probably the problem, I've used it in a callback function, so
it obviously didn't have any history.

Meanwhile, I've solved the problem using this:

if(transform_listener.waitForTransform ("map","base_footprint",
ros::Time(0), ros::Duration(1.0))){
                transform_listener.lookupTransform("map","base_footprint",ros::Time(0),
base_footprint);
}

but I guess it would be better just to make the listener a member
variable. Maybe it would be good idea to explicitly note this in the
tutorial or description of the listener? I didn't have any idea that the
listener works this way.

Thanks very much for your help,

Michal

> Michal,
> I have two more guesses for you.
>
> Most likely I think it could be a code issue.  Are you keeping the
> TransformListener object in scope?  The TransformListener aggregates data
> over time.  Immediately after you construct it it has zero data history.
> It
> relies on this history to build the tree and allow you to query it.  In
> general it should be outside of any loops, and it is common practice to
> make
> the TransformListener a member variable of a class.
>
> It also could be a connectivity issue.  Are you running on multiple
> computers? Could you run view_frames with the argument --node=FOO where
> FOO
> is the name of the node giving you the errors.
>
> Tully
>
> On Mon, Jul 5, 2010 at 8:02 AM, <Michal.Stolba@cis.strath.ac.uk> wrote:
>
>> Hi,
>>
>> thank you both.
>>
>> So far, I have tried roswtf and it found no problems:
>>
>> "running tf checks, this will take a second...
>> ... tf checks complete"
>>
>> I'll try the second approach as well.
>>
>> Actually it's the other way round - the transform is rarely received
>> correctly.
>>
>> Could the problem be in my code, something like asking for the transform
>> when it's not available?
>>
>> Thanks very much,
>>
>> Michal
>>
>> > Michal,
>> > I'd also suggest that you try running roswtf when things are running
>> with
>> > problems.  That has a tf plugin to try to help detect common problems.
>> >
>> > Tully
>> >
>> > On Fri, Jul 2, 2010 at 9:29 AM, Brian Gerkey
>> > <gerkey@willowgarage.com>wrote:
>> >
>> >> hi Michal,
>> >>
>> >> The fact that it's only rarely received incorrectly is peculiar.
>> >> Sounds like part of the system is occasionally, or slowly, publishing
>> >> a conflicting transform.  I would log all the tf data during a run:
>> >>  rosbag record tf
>> >> Then search through the resulting bag for the problem.  Something
>> like
>> >> this will pull out all the messages that declare a transform with
>> >> base_footprint as the child:
>> >>  rosbag filter in.bag out.bag 'topic == "tf" and
>> >> m.transforms[0].header.frame_id == "base_footprint"'
>> >> (where in.bag should be replaced by the name of bag created by the
>> >> record step).  You can examine the filtered data with rostopic:
>> >>  rostopic echo -b out.bag tf
>> >> Presumably, in that data stream, you'll see occasional conflicting
>> >> declarations of the parent of base_footprint.
>> >>
>> >>        brian.
>> >>
>> >> On Fri, Jul 2, 2010 at 3:42 AM,  <Michal.Stolba@cis.strath.ac.uk>
>> wrote:
>> >> > Hi,
>> >> >
>> >> > thanks for the reply. Gmapping is configured with <param
>> >> name="odom_frame"
>> >> > value="odom_combined"/>
>> >> >
>> >> > i'm launching this configuration:
>> >> >
>> >> > <launch>
>> >> >  <include file="$(find pr2_machine)/$(env ROBOT).machine" />
>> >> >  <include file="$(find
>> hi_level_navigation)/launch/slam_gmapping.xml"
>> >> />
>> >> >  <include file="$(find pr2_navigation_teleop)/teleop.xml" />
>> >> >  <include file="$(find
>> >> pr2_navigation_perception)/lasers_and_filters.xml"
>> >> />
>> >> >  <include file="$(find pr2_navigation_perception)/ground_plane.xml"
>> />
>> >> >  <include file="$(find pr2_navigation_slam)/move_base.xml" />
>> >> > </launch>
>> >> >
>> >> > where slam_gmapping.xml is:
>> >> >
>> >> > <launch>
>> >> >    <node pkg="gmapping" type="slam_gmapping" name="slam_gmapping"
>> >> > output="screen">
>> >> >      <remap from="scan" to="base_scan"/>
>> >> >      <param name="odom_frame" value="odom_combined"/>
>> >> >      <param name="map_update_interval" value="5.0"/>
>> >> >      <param name="maxUrange" value="16.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="1.0"/>
>> >> >      <param name="angularUpdate" value="0.436"/>
>> >> >      <param name="temporalUpdate" value="5.0"/>
>> >> >      <param name="resampleThreshold" value="0.5"/>
>> >> >      <param name="particles" value="80"/>
>> >> >      <param name="xmin" value="-50.0"/>
>> >> >      <param name="ymin" value="-50.0"/>
>> >> >      <param name="xmax" value="50.0"/>
>> >> >      <param name="ymax" value="50.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"/>
>> >> >    </node>
>> >> > </launch>
>> >> >
>> >> > sometimes (quite rarely) the transform is received correctly.
>> >> >
>> >> > Thanks very much,
>> >> >
>> >> > Michal
>> >> >
>> >> >> Perhaps gmapping is configured with odom_frame == base_footprint?
>> >> >>
>> >> >>       brian.
>> >> >>
>> >> >> On Fri, Jun 25, 2010 at 10:32 AM, Wim Meeussen
>> >> >> <meeussen@willowgarage.com> wrote:
>> >> >>> Michal,
>> >> >>>
>> >> >>>> RESULTS: for /map to /base_footprint
>> >> >>>> Chain is: /map -> /base_footprint -> /odom_combined
>> >> >>>> Net delay     avg = 0.020768: max = 0.064
>> >> >>>
>> >> >>> [...]
>> >> >>>
>> >> >>>> the only weird thing is, that in rviz the transform arrows shows
>> >> like
>> >> >>>> this: /base_footprint -> /odom_combined -> /map
>> >> >>>> might this be a sign of some problem?
>> >> >>>
>> >> >>> Yes, This is most likely your problem. It appears that you have a
>> tf
>> >> >>> publisher from map to base_footprint, and another publisher from
>> >> >>> odom_combined to base_footprint. So the base_footprint frame has
>> two
>> >> >>> parents.  In our setup we have amcl publish the transform from
>> map
>> >> to
>> >> >>> odom combined, and the robot pose ekf publish the transform from
>> >> >>> odom_combined to base_footprint.  What setup are you running? Did
>> >> you
>> >> >>> reconfigure amcl to publish a different tf transform?
>> >> >>>
>> >> >>> Wim
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Wim Meeussen
>> >> >>> Willow Garage Inc.
>> >> >>> <http://www.willowgarage.com)
>> >> >>> _______________________________________________
>> >> >>> ros-users mailing list
>> >> >>> ros-users@code.ros.org
>> >> >>> https://code.ros.org/mailman/listinfo/ros-users
>> >> >>>
>> >> >> _______________________________________________
>> >> >> ros-users mailing list
>> >> >> ros-users@code.ros.org
>> >> >> https://code.ros.org/mailman/listinfo/ros-users
>> >> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > ros-users mailing list
>> >> > ros-users@code.ros.org
>> >> > https://code.ros.org/mailman/listinfo/ros-users
>> >> >
>> >> _______________________________________________
>> >> ros-users mailing list
>> >> ros-users@code.ros.org
>> >> https://code.ros.org/mailman/listinfo/ros-users
>> >>
>> >
>> >
>> >
>> > --
>> > Tully Foote
>> > Systems Engineer
>> > Willow Garage, Inc.
>> > tfoote@willowgarage.com
>> > (650) 475-2827
>> > _______________________________________________
>> > ros-users mailing list
>> > ros-users@code.ros.org
>> > https://code.ros.org/mailman/listinfo/ros-users
>> >
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users@code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>
>
>
> --
> Tully Foote
> Systems Engineer
> Willow Garage, Inc.
> tfoote@willowgarage.com
> (650) 475-2827
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>