Confusion with TF...

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Confusion with TF...

Jason Owens
Hello all,

I've been having some issues with tf, time and gazebo... quite
possibly due to a case of newbie-itis. Perhaps the simplest question
is this:

Why would changing the update rate of the gazebo_ros_p3d plugin from
10Hz -> 11Hz make the laser scans bounce all over the place when
moving the robot?

I am confused as to why increasing the data rate of the pose transform
would cause the laser scans (both sensor frame and transformed world
frame point cloud) to jitter so much. I feel like this is an issue,
since when I implement SLAM on board a real robot, I will not be able
to have great control over the data publish rate, which other nodes
may depend on (e.g. an incremental generalized voronoi graph builder).

A little more background:

Given a create-like simulated robot with differential drive,
hokuyo-like laser, the gazebo-ros-p3d plugin publishing ground-truth
pose, another node publishing the /world -> /base_link transform based
on this pose info, and a node that builds an occupancy grid -
everything works quite well (i.e. rviz shows the map and laser data
"cleanly"). This is when the updateRate of the p3d plugin is set to
some multiple of 10Hz (which is the rate of the laser). However, if I
perturb the updateRate of the ground truth (i.e. 13Hz, 15Hz, 19Hz),
the laser scans start to jump around quite a bit in rviz, and the
occupancy grid gets very messy. I realize a real robot will not have a
perfectly clean map, but I am trying to understand the problem with
the transforms here so I can mitigate it.

I *am* using tf::MessageFilter, and have tried a variety of queue
sizes and tolerances, but to no avail. I actually first noticed the
problem when running on a laptop with 2 instead of 4 cores (like my
desktop), and it was clear not all the messages were being received.
roswtf doesn't show anything of interest (other than the /time topics
are unconnected, which I assume is due to "/use_sim_time = true"?). I
thought it was due to extrapolation, but it seems extrapolation is
disabled by default. However, if I print the extrapolation_mode from
the time_cache I get *a lot* of extrapolate_forward cases... which I
thought the tf::MessageFilter would prevent.

I have attached a copy of my urdf and launch file, if they may help.

Thanks ahead for any suggestions! Also - thank you so much for ROS; so
far, it has made my life easier in many ways, and hopefully I'll be
able to convince my employer (DoD) to allow us to contribute our
source back to the community.

-Jason

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users

pseudocreate.launch (3K) Download Attachment
pseudocreate.xml (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Confusion with TF...

John Hsu
Hi,
It's hard to debug this issue without being able to reproduce the problem... is there a way you can create a pseudo-package which we can run and reproduce the symptoms?  Also, can you also attach outputs from

rosrun tf view_frames
roswtf

You can see most of the tf debugging tools at:

http://www.ros.org/wiki/tf/Debugging%20tools

Lastly, there's a tf troubleshoot page here that might be helpful:

http://www.ros.org/wiki/tf/Troubleshooting

thanks,
John

On Wed, Apr 14, 2010 at 6:30 AM, Jason Owens <[hidden email]> wrote:
Hello all,

I've been having some issues with tf, time and gazebo... quite
possibly due to a case of newbie-itis. Perhaps the simplest question
is this:

Why would changing the update rate of the gazebo_ros_p3d plugin from
10Hz -> 11Hz make the laser scans bounce all over the place when
moving the robot?

I am confused as to why increasing the data rate of the pose transform
would cause the laser scans (both sensor frame and transformed world
frame point cloud) to jitter so much. I feel like this is an issue,
since when I implement SLAM on board a real robot, I will not be able
to have great control over the data publish rate, which other nodes
may depend on (e.g. an incremental generalized voronoi graph builder).

A little more background:

Given a create-like simulated robot with differential drive,
hokuyo-like laser, the gazebo-ros-p3d plugin publishing ground-truth
pose, another node publishing the /world -> /base_link transform based
on this pose info, and a node that builds an occupancy grid -
everything works quite well (i.e. rviz shows the map and laser data
"cleanly"). This is when the updateRate of the p3d plugin is set to
some multiple of 10Hz (which is the rate of the laser). However, if I
perturb the updateRate of the ground truth (i.e. 13Hz, 15Hz, 19Hz),
the laser scans start to jump around quite a bit in rviz, and the
occupancy grid gets very messy. I realize a real robot will not have a
perfectly clean map, but I am trying to understand the problem with
the transforms here so I can mitigate it.

I *am* using tf::MessageFilter, and have tried a variety of queue
sizes and tolerances, but to no avail. I actually first noticed the
problem when running on a laptop with 2 instead of 4 cores (like my
desktop), and it was clear not all the messages were being received.
roswtf doesn't show anything of interest (other than the /time topics
are unconnected, which I assume is due to "/use_sim_time = true"?). I
thought it was due to extrapolation, but it seems extrapolation is
disabled by default. However, if I print the extrapolation_mode from
the time_cache I get *a lot* of extrapolate_forward cases... which I
thought the tf::MessageFilter would prevent.

I have attached a copy of my urdf and launch file, if they may help.

Thanks ahead for any suggestions! Also - thank you so much for ROS; so
far, it has made my life easier in many ways, and hopefully I'll be
able to convince my employer (DoD) to allow us to contribute our
source back to the community.

-Jason

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users



_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: Confusion with TF...

Jason Owens
On Wed, Apr 14, 2010 at 2:18 PM, John Hsu <[hidden email]> wrote:
> Hi,
> It's hard to debug this issue without being able to reproduce the problem...

I figured that might be the case...

> is there a way you can create a pseudo-package which we can run and
> reproduce the symptoms?  Also, can you also attach outputs from
>
> rosrun tf view_frames
> roswtf

I'll work on creating a mini-pkg; until then, I've uploaded two bag
files at http://public.me.com/robocoder (the jitter has the matching
tf rate 10Hz, and the no_jitter has 13Hz), and I've attached the
frames and wtf output to this message. I do notice that for some
reason, the frame.pdf shows the messages as being quite old - is this
something that has to do with gazebo? When I look at the
ros::Time::toSec() when the system is running, I get values that match
the ROS time displayed in rviz, i.e. starting from 0.

Thanks for looking at this!
-Jason

>
> You can see most of the tf debugging tools at:
>
> http://www.ros.org/wiki/tf/Debugging%20tools
>
> Lastly, there's a tf troubleshoot page here that might be helpful:
>
> http://www.ros.org/wiki/tf/Troubleshooting
>
> thanks,
> John
>
> On Wed, Apr 14, 2010 at 6:30 AM, Jason Owens <[hidden email]> wrote:
>>
>> Hello all,
>>
>> I've been having some issues with tf, time and gazebo... quite
>> possibly due to a case of newbie-itis. Perhaps the simplest question
>> is this:
>>
>> Why would changing the update rate of the gazebo_ros_p3d plugin from
>> 10Hz -> 11Hz make the laser scans bounce all over the place when
>> moving the robot?
>>
>> I am confused as to why increasing the data rate of the pose transform
>> would cause the laser scans (both sensor frame and transformed world
>> frame point cloud) to jitter so much. I feel like this is an issue,
>> since when I implement SLAM on board a real robot, I will not be able
>> to have great control over the data publish rate, which other nodes
>> may depend on (e.g. an incremental generalized voronoi graph builder).
>>
>> A little more background:
>>
>> Given a create-like simulated robot with differential drive,
>> hokuyo-like laser, the gazebo-ros-p3d plugin publishing ground-truth
>> pose, another node publishing the /world -> /base_link transform based
>> on this pose info, and a node that builds an occupancy grid -
>> everything works quite well (i.e. rviz shows the map and laser data
>> "cleanly"). This is when the updateRate of the p3d plugin is set to
>> some multiple of 10Hz (which is the rate of the laser). However, if I
>> perturb the updateRate of the ground truth (i.e. 13Hz, 15Hz, 19Hz),
>> the laser scans start to jump around quite a bit in rviz, and the
>> occupancy grid gets very messy. I realize a real robot will not have a
>> perfectly clean map, but I am trying to understand the problem with
>> the transforms here so I can mitigate it.
>>
>> I *am* using tf::MessageFilter, and have tried a variety of queue
>> sizes and tolerances, but to no avail. I actually first noticed the
>> problem when running on a laptop with 2 instead of 4 cores (like my
>> desktop), and it was clear not all the messages were being received.
>> roswtf doesn't show anything of interest (other than the /time topics
>> are unconnected, which I assume is due to "/use_sim_time = true"?). I
>> thought it was due to extrapolation, but it seems extrapolation is
>> disabled by default. However, if I print the extrapolation_mode from
>> the time_cache I get *a lot* of extrapolate_forward cases... which I
>> thought the tf::MessageFilter would prevent.
>>
>> I have attached a copy of my urdf and launch file, if they may help.
>>
>> Thanks ahead for any suggestions! Also - thank you so much for ROS; so
>> far, it has made my life easier in many ways, and hopefully I'll be
>> able to convince my employer (DoD) to allow us to contribute our
>> source back to the community.
>>
>> -Jason
>>
>> _______________________________________________
>> ros-users mailing list
>> [hidden email]
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>
>
> _______________________________________________
> ros-users mailing list
> [hidden email]
> https://code.ros.org/mailman/listinfo/ros-users
>
>

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users

frames.pdf (15K) Download Attachment
wtf.out (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Confusion with TF...

John Hsu
Hi Jason
Can you pose the nodes that are publishing the necessary tf transforms as well?
thanks,
John

On Wed, Apr 14, 2010 at 2:37 PM, Jason Owens <[hidden email]> wrote:
On Wed, Apr 14, 2010 at 2:18 PM, John Hsu <[hidden email]> wrote:
> Hi,
> It's hard to debug this issue without being able to reproduce the problem...

I figured that might be the case...

> is there a way you can create a pseudo-package which we can run and
> reproduce the symptoms?  Also, can you also attach outputs from
>
> rosrun tf view_frames
> roswtf

I'll work on creating a mini-pkg; until then, I've uploaded two bag
files at http://public.me.com/robocoder (the jitter has the matching
tf rate 10Hz, and the no_jitter has 13Hz), and I've attached the
frames and wtf output to this message. I do notice that for some
reason, the frame.pdf shows the messages as being quite old - is this
something that has to do with gazebo? When I look at the
ros::Time::toSec() when the system is running, I get values that match
the ROS time displayed in rviz, i.e. starting from 0.

Thanks for looking at this!
-Jason

>
> You can see most of the tf debugging tools at:
>
> http://www.ros.org/wiki/tf/Debugging%20tools
>
> Lastly, there's a tf troubleshoot page here that might be helpful:
>
> http://www.ros.org/wiki/tf/Troubleshooting
>
> thanks,
> John
>
> On Wed, Apr 14, 2010 at 6:30 AM, Jason Owens <[hidden email]> wrote:
>>
>> Hello all,
>>
>> I've been having some issues with tf, time and gazebo... quite
>> possibly due to a case of newbie-itis. Perhaps the simplest question
>> is this:
>>
>> Why would changing the update rate of the gazebo_ros_p3d plugin from
>> 10Hz -> 11Hz make the laser scans bounce all over the place when
>> moving the robot?
>>
>> I am confused as to why increasing the data rate of the pose transform
>> would cause the laser scans (both sensor frame and transformed world
>> frame point cloud) to jitter so much. I feel like this is an issue,
>> since when I implement SLAM on board a real robot, I will not be able
>> to have great control over the data publish rate, which other nodes
>> may depend on (e.g. an incremental generalized voronoi graph builder).
>>
>> A little more background:
>>
>> Given a create-like simulated robot with differential drive,
>> hokuyo-like laser, the gazebo-ros-p3d plugin publishing ground-truth
>> pose, another node publishing the /world -> /base_link transform based
>> on this pose info, and a node that builds an occupancy grid -
>> everything works quite well (i.e. rviz shows the map and laser data
>> "cleanly"). This is when the updateRate of the p3d plugin is set to
>> some multiple of 10Hz (which is the rate of the laser). However, if I
>> perturb the updateRate of the ground truth (i.e. 13Hz, 15Hz, 19Hz),
>> the laser scans start to jump around quite a bit in rviz, and the
>> occupancy grid gets very messy. I realize a real robot will not have a
>> perfectly clean map, but I am trying to understand the problem with
>> the transforms here so I can mitigate it.
>>
>> I *am* using tf::MessageFilter, and have tried a variety of queue
>> sizes and tolerances, but to no avail. I actually first noticed the
>> problem when running on a laptop with 2 instead of 4 cores (like my
>> desktop), and it was clear not all the messages were being received.
>> roswtf doesn't show anything of interest (other than the /time topics
>> are unconnected, which I assume is due to "/use_sim_time = true"?). I
>> thought it was due to extrapolation, but it seems extrapolation is
>> disabled by default. However, if I print the extrapolation_mode from
>> the time_cache I get *a lot* of extrapolate_forward cases... which I
>> thought the tf::MessageFilter would prevent.
>>
>> I have attached a copy of my urdf and launch file, if they may help.
>>
>> Thanks ahead for any suggestions! Also - thank you so much for ROS; so
>> far, it has made my life easier in many ways, and hopefully I'll be
>> able to convince my employer (DoD) to allow us to contribute our
>> source back to the community.
>>
>> -Jason
>>
>> _______________________________________________
>> ros-users mailing list
>> [hidden email]
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>
>
> _______________________________________________
> ros-users mailing list
> [hidden email]
> https://code.ros.org/mailman/listinfo/ros-users
>
>

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users



_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users