PointCloud2 not beeing Displayed!

[Thiago Motta]

Hello MoveIt community!

Im currently trying to display a PointCloud in MoveIt with no success. Ive got a Publisher that is using this implementation  http://wiki.ros.org/navigation/Tutorials/RobotSetup/Sensors, but transforming it to PointCloud2, with "sensor_msg::convertPointCloudToPointCloud2",  before publishing. I also got a listener that is receiving data just fine.

Once at Moveit, Ive got Grid, MotionPlanning, PlanningScene and PointCloud2 tabs. Status under PointCloud2 tab is beeing shown as Ok and Topic, under Status, under PointCloud2, shows the number of messages beeing received, which is beeing updated correctly. Topic under PointCloud2 is filled with the publisher topic.

The problem is that I dont see anything being drawn at RViz display.

I have changed the moveit_sensor_manager.launch.xml, sensor_manager.launch.xml and created the sensors_rgbd.yaml file.

PointCloud2 data is being publised by the /point_cloud2_publisher topic to /cloud2 topic and being listened by the /PointCloud2_listener

When running RViz there is also these errors:

[ERROR] [1393610232.381403234]: Transform error: Lookup would require extrapolation into the future.  Requested time 1393610232.381054973 but the latest data is at time 1393610232.332442045, when looking up transform from frame [SimUEP/puma560/link1] to frame [SimUEP/puma560/world]

[ERROR] [1393610232.381452217]: Transform cache was not updated. Self-filtering may fail.

Im currently using ROS Hydro and Ubuntu 12.04.2 LTS (Precise Pangolin). Roscore is launched at a Windows 7 machine and Ubuntu is set to get ROS data (ROS_MASTER_IP and ROS_IP are set accordly) from the Windows machine.

Im uploading some files to help solving this out! All of them can be found here: https://www.dropbox.com/sh/bzwqs885010sbos/KIHKwVKrAT 
They can also be found at the anexed files.

So, what am I doing wrong? Let me know if you need something else.

Thank you all for helping me!

[Dave Hershberger]

The "extrapolation into the future" error makes it seem like you might have a clock synchronization problem between the computers.  It's only 0.05 seconds difference that I can see from the error, but maybe that's enough to cause trouble.

If that error is from RViz, it is possible that you can solve it by increasing the "queue size" parameter in the PointCloud2 display.  It is currently at 10 in your screenshot - try setting it to 100 and see what happens.  That is how many PointCloud2 messages it will queue up waiting for sensor-data times to match TF transform times.  I'm not sure this will solve it because the error message doesn't look real familiar, but it seems related.  Since that parameter is a count of PointCloud2 messages, you don't want to set it super high as that could start filling up your RAM.  However this sort of time-mismatch situation is exactly why the parameter was originally added.

Dave

[Thiago Motta]

That error beggings at the very start of MoveIt, without even adding the PointCloud2 tab.. It started showing today and Ive been working with this setup for about a week or two. 
Changing the Queue Size doesnt solve this error.
This error actually happens every second or so.

Im actually intrigued on why I need a PointCloud2 to be displayed at RViz since it does support only PointCloud.. but when publishing a PointCloud node, I get an error which says something along the line of "Expecting data of type PointCloud2 but receiving data of type PointCloud" with an MD5 refence in the middle of the sentence.

[Dave Coleman]

Bringing back this issue from two months ago, I'm running into it too, now, when using the DepthImageOctomapUpdater 

I'm getting:

ERROR ros.moveit_ros_planning: Transform error: Lookup would require extrapolation into the future.  Requested time 1397683300.784093773 but the latest data is at time 1397683300.742001914, when looking up transform from frame [left_gripper_r_finger] to frame [camera_rgb_optical_frame]
ERROR ros.moveit_ros_perception: Transform cache was not updated. Self-filtering may fail.

Did you make any progress on this?

[Thiago Motta]

Since I was using two different machines, I had to synchronize their clocks in order to make it work. This solution was done with NTP, http://ubuntuforums.org/showthread.php?t=862620.
If that doesnt works for you, I would try checking for your TF to see its beeing built correctly. The last time I ran into this was because I had a point cloud with a reference at world while the data was actually from a link, so I had to change the reference.

Abraço,

Thiago Ribeiro da Motta.

[Steffen P]

I have exactly the same problem. Dave have you found a solution?

[Thiago Motta]

From my personal experience, this could mean a couple of things:

1 - If you are using ROS at a machine and your ROS-dependent application in another one then the error might be because your clocks are not synchronized. This can be solved by synchronizing both your machines clock, which can be achieved with this tutorial: http://ubuntuforums.org/showthread.php?t=862620

2 - It could mean that something with your TF is messed up. In the case I posted above, the error says that it cant transform from link1 to world. If thats the case, then the workaround is to change the octomap_frame, at moveit_sensor_manager to the joint it cant transform to (link1 in this case). This change also needs to be done at octomap_mapping.launch, at frame_id field. Those steps would make the point cloud to be published relative to the new joint you are updating, so it should get rid of the error aswell, but be advised: Depending on the joint you are inputing, the pointcloud could suffer some rotation. If that happens, try a joint that matches the previous joint axis.

3 - If you are only using the PointCloud2 plugin at RViz, try making the chance suggested by Dave Hershberger and raising the value of Queue Size within the plugin. This particular solution havent really worked for me, but at least is something you can try in case both of the advices above didnt solve your problem.

Let me know if those workarounds worked for you.

Abraço,

Thiago Ribeiro da Motta.

[Rabe]

Hey everyone,

I recently had the same issue:
My computers were synchronised, TF was available, and the time difference ROS was complaining about was very small, under 5ms.
My solution was to increase the queue size in the plugin. This can be done in the sensors_rgbd.yaml.

Maybe this might help someone