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
>
(text/plain)