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
>