Ask Your Question
0

AMCL claims no data is being published even though there is (including tf data)

asked 2019-02-28 08:59:00 -0600

cmahieu gravatar image

updated 2019-02-28 09:04:08 -0600

gvdhoorn gravatar image

Hi

I am trying to get navigation to run on my robot. To do this I am currently trying to get AMCL to work on ROS kinetic (ubuntu 16.04 Xenial).

My setup consists of 3 machines (of which 2 are relevant). I have: - My server: which is running a roscore, amcl, robot control software etc - A raspberry Pi 3 with a RPLidar A3 connected running the lidar ros pacakge '' - A virtual machine running Ubuntu 16.04 on my computer which is used to run GUI's Rviz, rqt_tf_tree, ...

Data can be published and received from all machines so I think this is working (I set the ROS_MASTER_URI, ROS_HOSTNAME and ROS_IP variables and I edited the /etc/hosts file)

The lidar works and publishes data correctly (confirmed in Rviz and through rostopic echo). image description

However AMCL gives the following error every 15 seconds:

[ WARN] [1551364654.979541753]: No laser scan received (and thus no pose updates have been published) for 1551364654.979506 seconds.  Verify that data is being published on the /rplidar topic.

I do not get the error when using a different laserscan (the one from the robot instead of the RPLidar for instance). I have tried letting the lidar publish to the base_footprint frame directly as well as to a separate 'laser' fixed frame for which I then run:

rosrun tf static_transform_publisher 0 0 0 0 0 0 1.0 base_footprint laser  50

Running roswtf on the server machine does not yield anything useful (only some unconnected topics). Running it on the Raspberry does however:

WARNING Received out-of-date/future transforms:
 * receiving transform from [/naoqi_driver_node] that differed from ROS time by 86.070399184s
 * receiving transform from [/static_transform_publisher_1551361858545724424] that differed from ROS time by 86.129054226s

The same info is given when i run roswtf from the virtual box machine.

A screenshot of rqt_tf_tree is below: image description image description

And output of rosrun tf tf_echo base_footprint laser:

At time 1551365866.147
- Translation: [0.000, 0.000, 0.000]
- Rotation: in Quaternion [0.000, 0.000, 0.000, 1.000]
            in RPY (radian) [0.000, -0.000, 0.000]
            in RPY (degree) [0.000, -0.000, 0.000]
At time 1551365866.898
- Translation: [0.000, 0.000, 0.000]
- Rotation: in Quaternion [0.000, 0.000, 0.000, 1.000]
            in RPY (radian) [0.000, -0.000, 0.000]
            in RPY (degree) [0.000, -0.000, 0.000]
At time 1551365867.899
- Translation: [0.000, 0.000, 0.000]
- Rotation: in Quaternion [0.000, 0.000, 0.000, 1.000]
            in RPY (radian) [0.000, -0.000, 0.000]
            in RPY (degree) [0.000, -0.000, 0.000]

I am totally at a loss so any help would be greatly appreciated

Regards Christof

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2019-02-28 09:03:25 -0600

gvdhoorn gravatar image

updated 2019-02-28 09:35:27 -0600

Receiving transform from [..] that differed from ROS time by 86.129054226s

With "multiple machines" and issues with TF / subscribers the first thing to check would be time synchronisation across all machines involved. Can you confirm you've done that?


Edit:

I had no idea synchronization was something to take into account.

It is pretty logical though, if you think about it: how would we be able to temporally correlate sensor data (or more generally: publications) coming from different machines without a common/shared/synchronised clock?

I quickly forced synchronisation by taking the desyncrhonized data and publishing it to a new topic without the old time info and this works (as a temp solution).

You probably already figured it out, but republishing like that is certainly not a real solution.

Take a look at wiki/ROS/NetworkSetup - Timing issues, TF complaining about extrapolation into the future? for a solution.

edit flag offensive delete link more

Comments

Hi

I had no idea synchronization was something to take into account. I quickly forced synchronisation by taking the desyncrhonized data and publishing it to a new topic without the old time info and this works (as a temp solution). Thank you! I would not have been able to solve this without you!

cmahieu gravatar imagecmahieu ( 2019-02-28 09:20:55 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-02-28 08:59:00 -0600

Seen: 105 times

Last updated: Feb 28