[ros-users] exception in transform listener

Tully Foote tfoote at willowgarage.com
Fri Jul 2 17:01:36 UTC 2010


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 at 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 at 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 at 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 at code.ros.org
> >>> https://code.ros.org/mailman/listinfo/ros-users
> >>>
> >> _______________________________________________
> >> ros-users mailing list
> >> ros-users at code.ros.org
> >> https://code.ros.org/mailman/listinfo/ros-users
> >>
> >
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users at code.ros.org
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



-- 
Tully Foote
Systems Engineer
Willow Garage, Inc.
tfoote at willowgarage.com
(650) 475-2827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100702/1d55fc19/attachment-0003.html>


More information about the ros-users mailing list