Feat/fastdem map timestamp

[jlgalanRB]

Why

FastDEM accumulates scan data in an elevation map. ROS messages derived from that map, including ~/drop/cloud, use the map timestamp in their message header.

integrateImpl used the input cloud timestamp to look up the robot pose, but did not copy that timestamp to the map. As a result, the map could retain its initial timestamp of zero, and map-derived messages could also be published with a zero timestamp. Consumers using TF could then interpret the message using the latest available transform instead of the transform for the scan that updated the map.

What changed

After a scan has been integrated and the optional raycasting and drop detection have completed, set the map timestamp from the input cloud:

map_.setTimestamp(cloud.timestamp());

Empty preprocessed scans still return without changing the map timestamp.

Result

Map-derived ROS messages are stamped with the time of the latest scan that updated the map.

[Copilot]

Copilot review overview

🟡 Changes recommended

The central timestamp propagation and rejected-scan behavior need regression tests.

Review effort: Balanced
Findings: 1

Open (1)

• Add tests for timestamp propagation and empty integration behavior · New

What changed in this PR

Updates FastDEM maps to inherit the timestamp of the latest successfully integrated scan.

Changes:

• Sets the map timestamp after mapping and optional post-processing.
• Preserves the timestamp when preprocessing rejects a scan.

File	Description
fastdem/​src/​fastdem.cpp	Propagates the integrated cloud timestamp to the map.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.