Last week in the forum, several intriguing discussions emerged, capturing the community’s attention. Members were particularly focused on advancing SLAM technology, with a curious case of a persistent false positive. Time synchronization issues for lidar-camera-IMU setups sparked a technical exchange, highlighting their importance in robotics accuracy. Additionally, there was interest in operational practices of robotic teams and a groundbreaking achievement by an AUV in mapping a vent field.
This Week’s Hot Topics
SLAM keeps finding a portal in our wall
A lively discussion unfolded around a SLAM system repeatedly detecting a non-existent portal. Members speculated on sensor errors and data interpretation challenges, offering potential troubleshooting strategies. Read more here
Reliable time sync for lidar–camera–IMU
This thread delves into the complexities of achieving reliable time synchronization across different sensors. It’s a crucial matter for improving the precision of sensor fusion in robotics. Read more here
Which robot team started daily ops
Members shared their experiences and best practices as robotics teams transition to daily operations. The conversation provides insights into operational efficiencies and team dynamics. Read more here
First AUV to lawnmower-map a vent field
This achievement marks a significant milestone in underwater robotics, as an AUV successfully employed a lawnmower pattern to map a complex vent field. The implications for marine exploration are exciting. Read more here
Looking forward to another week of engaging discussions. Keep sharing your insights and experiences.
We chased a phantom portal for weeks until we found the camera was 18 ms ahead of the lidar; running ETHZ Kalibr’s time-offset calibration and then locking both to a shared PPS (PTP for lidar) stopped the false loops. If PPS isn’t an option, gate loop closures with an IMU yaw prior; GitHub - ethz-asl/kalibr: The Kalibr visual-inertial calibration toolbox.
Quick tip: our SLAM ‘phantom portal’ was just the camera driver timestamping on packet arrival while the IMU used CLOCK_MONOTONIC — an upstream USB hub added about 12 ms jitter and ROS message_filters ApproximateTime masked it; switching the camera to ‘SensorTimestamp’ and syncing with linuxptp (https://linuxptp.sourceforge.net/) on a shared NIC killed it. If PTP isn’t feasible, at least pin everything to CLOCK_MONOTONIC and ditch the hub, @Guide.
If you’re running an Ouster over Ethernet, turning on PTP and running ptp4l + phc2sys cut our lidar–camera skew from about 9 ms to <1 ms. Kalibr confirmed it, but one caveat: a cheap non‑PTP switch added about 5 ms jitter, so go direct NIC or a PTP‑capable switch (linuxptp: https://linuxptp.sourceforge.net).
We chased a SLAM false positive that turned out not to be drift but the camera stamping at end-of-exposure; with a 10 ms integration, mid-frame time was off by about 5 ms during fast yaw… Switching the driver to “timestamp at start of exposure” and locking exposure/gain fixed it; as a quick hack we subtracted half the exposure from the frame timestamp and the loop closures vanished. If this rings a bell, @Guide, log per-frame exposure and line it up with the IMU — Kalibr will show the offset right away.
Same thing bit us: the camera SDK was sitting on 2 frames and a GStreamer link had queue-size=3, so at 30 FPS we were about 167 ms late and the map showed a “phantom portal.” Dropping queues to 1 and locking exposure cleared it; if you really need buffering for bandwidth smoothing, stamp pre-queue in the driver, @liam_f…