Unable to remove shape handle about robot_body_filter

[peci1]

Hi, you need to provide proper time. It seems you are running the simulation in a way that it timestamps data with its simulation time which starts at time 0 (e.g. 'data from time 257.18'). However, the ROS nodes do not know about this time, so they run in real time (e.g. 1696841160, which is the unix timestamp of current time).

Gazebo simulator provides a topic called /clock where it publishes the simulation time, and you can then add <param name="/use_sim_time" value="true" /> to your launch file to tell ROS to use this time. However, I don't see the /clock topic in the list of topics provided by Isaac. You will need to figure out how to configure Isaac to publish the /clock topic. I have no experience with Isaac so I can't help with that.

[peci1]

You Are Awesome. Adding a /clock topic and setting a <param name="/use_sim_time" value="true" /> works.

I'm glad it worked!

Question 1: Time-latency https://github.com/peci1/robot_body_filter/assets/39259734/9264dd46-5b16-4659-bdcc-e716da4a8ba6

My setup is working because of your help. How can I increase the processing speed? Ignoring the robot mesh out-to-interest region is the best option?

The most slowing down thing is doing pointcloud-mesh collisions checks. There are two ways (which can even be combined):

1. Use primitive shapes (boxes, cylinders, spheres) as collision objects instead of meshes. This may require you creating an alternative URDF model with different <collision> elements. Or have a look around if panda hasn't released a simplified model.
2. Number of links that are considered during the filtering. Refer to parameters ignored_links/everywhere and only_links in the readme. If you know some links cannot ever be seen by the camera, just remove them from the filter.
3. (bonus point :) ) Shadow filtering. But you have that turned off.

Also, if you're building this package from source, make sure you build it in release or relwithdebinfo modes. Debug mode is super slow.

I'm not sure how fast your camera is, but generally, the 30 FPS depth cameras are pretty tough to process. If your application allows, you could also consider decreasing the FPS of the camera to get more predictable filtered FPS (i.e. not to overload the filter). The filter itself cannot parallelize processing more, but in an extreme case, I can imagine you could write a nodelet that sends the pointclouds to e.g. 5 filters running side by side, but all publishing to the same output topic. This way, each of the 5 filters could be processing some data at the same time. The latency would stay the same, but the rate would increase.

Question 2.: Best way to multiple processing My Task: pick up an object on the table using a robot My current objective is to clear out the 1.background 2. robot and 3. table from the point cloud to capture only the object.

Background: by setting a bounding box robot: by the current setting that the movie shows table: by setting the same point cloud filter, using a table urdf.

1. what is the best option to clear out static objects, like `table`?

If you have it in the same URDF as the arm, that's fine, you can just leave it there. If not, you can either run a second instance of this filter, or use a plain pcl_ros/CropBox nodelet to filter out the table.

2. Should I launch three point cloud filters to clear out the background, table, and robot?

The fewer filters, the better.

3. Three pointcloud processes need to be connected, will the order affect performance?

robot_body_filter can do basic pointcloud clipping using parameters sensor/min_distance and sensor/max_distance. This is automatically done before the other more expensive tests. If you know something more about your pointcloud, e.g. a bounding box of the scene of interest, I suggest running first a CropBox filter to get just the area of interest, and after that running robot_body_filter. If you use CropBox for filtering out the table, also do it before this filter. Generally, the more things you filter out using simpler filters, the better. robot_body_filter is usually the most expensive one. But it only acts on points that have not yet been filtered out.

Also, if you're building a filtering pipeline, be sure to use nodelets and not nodes.

[PARKBONG]

You Are Awesome.
Adding a /clock topic and setting a <param name="/use_sim_time" value="true" /> works.

But I would like to ask two more questions.

Question 1: Time-latency
https://github.com/peci1/robot_body_filter/assets/39259734/9264dd46-5b16-4659-bdcc-e716da4a8ba6

My setup is working because of your help.
How can I increase the processing speed? Ignoring the robot mesh out-to-interest region is the best option?

Question 2.: Best way to multiple processing
My Task: pick up an object on the table using a robot
My current objective is to clear out the 1.background 2. robot and 3. table from the point cloud to capture only the object.

Background: by setting a bounding box
robot: by the current setting that the movie shows
table: by setting the same point cloud filter, using a table urdf.

1. what is the best option to clear out static objects, like table?
2. Should I launch three point cloud filters to clear out the background, table, and robot?
3. Three pointcloud processes need to be connected, will the order affect performance?

Again, as a beginner in this kind of ROS project, I appreciate your kind and fast help.
Thanks!