Octomap + Collision = Octomap being ignored!

[Thiago Motta]

Hello Community!

Im currently working on a setup with MoveIt and an octomap being updated constantly, which works just fine, but now I need the robot to avoid the octomap points during planning and I just cant achieve it!
The only way I've found so far to display the octomap was to download a Octomap Server, update it with PointCloud2 info and add the PointCloud2 Display at MoveIt, setting its topic to /octomap_point_cloud_centers. This visualization also works just fine, but how am I supposed to take octomap points into account when planning a movement? Those octomap points are just being ignored!
Is there a way to display the Octomap with MotionPlanning or PlanningScene? How?

Let me know if there is anything else I can provide to make my problem clearer!

Thank you all!

[Thiago Motta]

Although MoveIt only showed me 2 options at "Planning Scene Topic", at MotionPlanning, I decided to write down one of the published topics (http://wiki.ros.org/octomap_server) and filling it with /octomap_full worked!

Abraço,

Thiago Ribeiro da Motta.

[Thiago Motta]

Actually, thats rubbish. It worked for the first 2 cases and then it didnt for all the rest...

Anyone still got any idea how to help me ? Im thinking on creating a talker that listens to /octomap_full or /projected_map and publishes to moveit_msgs/PlanningScene. Is that the easiest way to do it ?

Abraço,

Thiago Ribeiro da Motta.

[Thiago Motta]

Anyone? Im still struggling with this!

[Sachin Chitta]

Hi Thiago,

MoveIt! has the capacity to generate and use its own Octomap representation but it looks like you are not using that. If you have an externally generated octomap, you need to add it to the planning scene. The easiest way to do this is through the /planning_scene topic. You can see this tutorial for how the ROS API to the planning scene works. The PlanningScene message contains a PlanningSceneWorld which you can use to specify the Octomap.

Hope this helps.

Best Regards,
Sachin

[Thiago Motta]

Thank you so much for your reply, Sachin! It really helped me!

After following the first link you sent, I was able to generate an Octomap with a PointCloud2 Publisher running in the same machine. However the real case scenario needs the publisher to be running on a differente machine with Windows (alongside with roscore) and having the Linux machine communicate with it. Once I update the sensors.yaml file with the topic being published from Windows, Im not able to see any point at the octomap and these two messages starts to show up:

MessageFilter [target=/SimUEP/puma560/world ]: Dropped 100.00% of messages so far. Please turn the [ros.moveit_ros_perception.message_notifier] rosconsole logger to DEBUG for more information.

MessageFilter [target=/SimUEP/puma560/world ]: The majority of dropped messages were due to messages growing older than the TF cache time. The last message's timestamp was: 1395777629.035284, and the last frame_id was: SimUEP/puma560/linkLaser1

Is there a way to increase TF cache time? Or what else can I do?

Abraço,

Thiago Ribeiro da Motta.

[Thiago Motta]

There is also this message:

MessageFilter [target=/SimUEP/puma560/world ]: Discarding Message, in frame SimUEP/puma560/linkLaser1, Out of the back of Cache Time(stamp: 1395779912.239 + cache_length: 10.000 < latest_transform_time 1395779929.508. Message Count now: 0

Abraço,

Thiago Ribeiro da Motta.

[Dave Hershberger]

The MessageFilter message can come from any code using a tf::MessageFilter.

If it is inside RViz that the messages are being discarded, there is often a "Queue Size" parameter in each display which controls this.  The default is 10.  Try increasing it to 100 or something big to see what works.

If it is not inside RViz, you can either work through the source code to find where the tf::MessageFilter is set up and either increase or parameterize the queue size.

Another possibility is that the clocks on the two computers are far enough out of sync to be causing this problem.

Dave

[Thiago Motta]

Those messages are being shown at RViz, but since Im only using MotionPlanning display, I couldnt find any "Queue Size" parameter (not even at moveit.rviz). Since this couldnt be found, I tried to synchronize both clocks.
After synchronizing both machines clocks (which had a difference of about 20 second between them) using NTP, I still get the first two warnings, but now there is also this message:

Outgoing queue full for topic [/SimUEP/puma560/laserScan]. Discarding oldest message

Location:

C:\work\sdk\ros_comm\clients\cpp\roscpp\src\libros\transport_subscriber_link.cpp::197

I still dont get to see any point at Rviz.

Any other suggestion?

Abraço,

Thiago Ribeiro da Motta.

[Thiago Motta]

Problem solved! The Windows PointCloud2 publisher was publishing way too fast. Once I had slowed it down everything started to work!

Thank you all for the help! =D

Abraço,

Thiago Ribeiro da Motta.

[reem-support]

On Mar 25, 2014 9:46 PM, "Dave Hershberger" <dave.her...@sri.com> wrote:
>
> The MessageFilter message can come from any code using a tf::MessageFilter.
>
> If it is inside RViz that the messages are being discarded, there is often a "Queue Size" parameter in each display which controls this.  The default is 10.  Try increasing it to 100 or something big to see what works.
>
> If it is not inside RViz, you can either work through the source code to find where the tf::MessageFilter is set up and either increase or parameterize the queue size.
>
> Another possibility is that the clocks on the two computers are far enough out of sync to be causing this problem.

Out of sync clocks are a very common cause for such errors. I'd check if you have a clock offset of more than 10s.

Adolfo