Exporting images at a higher frequency than rtabmap slam frequency?

[dinossht]

I am using ICP SLAM for mapping purposes, and using only RGB images for coloring purposes offline. Currently it seems like the images are added every 1 Hz (same as rtabmap detection rate). Can I add images more frequently without needing to run SLAM at a higher rate?

[matlabbe]

You may try setting Rtabmap/CreateIntermediateNodes=true with Mem/IntermediateNodeDataKept=true.

[dinossht]

This does not seem to add more images to the databases than the number of nodes existing. What functionality is changed by setting these parameters you are referring to?

[matlabbe]

Hi,

To make sure to not miss anything:

Rtabmap/CreateIntermediateNodes=true
Mem/IntermediateNodeDataKept=true
Mem/NotLinkedNodesKept=true
RGBD/LinearUpdate=0.0

There should be nodes in the graph with weight  = -1 when it works. Note that nodes are added at the rate of the lowest topic frequency. If you receive lidar at 1 Hz and images are published at 30 Hz, nodes at 1 Hz will be added. However, if lidar is published at 10 Hz, then you will get 10 Hz camera images in the database instead of 1 Hz (if Rtabmap/DetectionRate is 1).

[dinossht]

Thank you Mathieu! This is what I needed:)

[dinossht]

Hi,
I tested this and does not seem to work as intended. Setting these parameters does not add any more camera frames into the database for coloring. Do you have any idea?

launch file: l.launch

[dinossht]

I think I have a guess for the behaviour. It seems like kamera key frame rate is limited by the lidar data rate. Since I use point loud assembler for lidar, rtabmap receives lidar data at 1 Hz (lidar freq=10 Hz, and the assembler collects 10 data points). Does this make sense?

[matlabbe]

Yes, that is possible. The intermediate nodes are added after synchronizing lidar and camera data, so at best they would be added at the sensor lowest rate.

You may try without point cloud assembler node to increase the rate at which sensors are sync in rtabmap node to 10 Hz.

I don't have however a workaround to be able to feed 1 Hz lidar data with 30 Hz camera data to rtabmap node and having more than 1 Hz camera data saved in the database. Well, maybe changing point cloud assembler to publish an empty cloud when it didn't assemble the full cloud yet, then you will get 10 Hz lidar data to sync on rtabmap node (only 1 of 10 scans would not be empty), thus 10 Hz camera data saved in the database.

[dinossht]

"You may try without point cloud assembler node to increase the rate at which sensors are sync in rtabmap node to 10 Hz." This worked, but running slam with pointcloud data 10Hz is not feasible for me.

"maybe changing point cloud assembler to publish an empty cloud when it didn't assemble the full cloud yet," This is interesting, how could I achieve publishing empty clouds 9/10 times, and publishing a full point cloud 1/10 times. Is there an easy method?

[matlabbe]

An empty cloud could be published by changing this to:

}
else
{
  if(!isMoving)
  {
    clouds_.pop_back();
  }
  else
  {
    previousPose_ = pose;
  }
  sensor_msgs::msg::PointCloud2 rosCloud;
  rosCloud.header = cloudMsg->header;
  cloudPub_->publish(rosCloud);
}

[dinossht]

Aha, thought there were any other clever way I could achieve this without modifying the source :D. But thank you!

[matlabbe]

There could be another way actually, by enabling circular_buffer parameter:

~circular_buffer (bool, default: "false")

    Instead of accumulating all the clouds before publishing the assembled cloud, the input clouds are kept in a circular buffer (of size max_clouds or a assembling_time) and the assebmled cloud is published every time a new scan is received. When circular_buffer is false, the temporary buffer to accumulate the clouds is cleared after each publishing.

[dinossht]

Thank you, that worked!