Hi all,
I’m feeding CAN-based VehicleIO states into the DriveWorks Egomotion module and noticed that the latest egomotion estimate timestamp (dwEgomotionResult.timestamp_us) often does not match the timestamp of the most recently added VehicleIO state (“Last EgoMotion Added Time”). Sometimes it matches, sometimes it stays on an older value for several updates.
Observation / pattern from logs:
Last EgoMotion Added Time(m_lastEgoMotionAddedTime) always equals the current CAN frame timestamp I add (msg.timestamp_us).Egomotion estimate timestamp(fromdwEgomotion_getEstimationTimestamp()) updates only occasionally (seems to “commit” only on some updates).
Examples (timestamps in µs):
- Estimate is exactly 2 messages behind
- [t1] CAN 0x86 (Steeringupdate) @ 1767810988223906 → estimate becomes 1767810988223906 ✅
- [t2] CAN 0xB2 (Wheel-speed update) @ 1767810988231761 → estimate stays 1767810988223906
- [t3] CAN 0x86 (Steeringupdate) @ 1767810988233644 → estimate stays 1767810988223906 ❌ (timestamp is from 2 messages before, i.e. t1)
- Estimate is exactly 3 messages behind
- [t1] CAN 0x86 (Steeringupdate) @ 1767810988253522 → estimate becomes 1767810988253522 ✅
- [t2] CAN 0xB2 (Wheel-speed update) @ 1767810988253983 → estimate stays 1767810988253522
- [t3] CAN 0xB2 (Wheel-speed update) @ 1767810988262509 → estimate stays 1767810988253522
- [t4] CAN 0xFD (Speed update) @ 1767810988262971 → estimate stays 1767810988253522 ❌ (timestamp is from 3 messages before, i.e. t1)
- Estimate is exactly 1 message behind
- [t1] CAN 0xFD (Speed update) @ 1767810988282854 → estimate becomes 1767810988282854 ✅
- [t2] CAN 0x86 (Steeringupdate) @ 1767810988283580 → estimate stays 1767810988282854 ❌ (timestamp is from 1 message before, i.e. t1)
Relevant Code
- Add CAN timestamp offset + decode signals
dwCANMessage msg = sensorEvent->canFrame;
msg.timestamp_us += m_offsetTime; // loop simulation
dwTime_t tsFrame = msg.timestamp_us;
CHECK_DW_ERROR_MSG(dwCANInterpreter_consume(&msg, m_aCanInterpreter), "Consume message failed");
// parse signals -> fill m_vioSafety/m_vioNonSafety/m_vioAct + setSignalValid(...)
- Add VehicleIO state to egomotion (only if we have all required signals at least once)
if (anyUpdate) {
if (m_lastEgoMotionAddedTime < sensorEvent->timestamp_us) {
dwStatus st = dwEgomotion_addVehicleIOState(&m_vioSafety, &m_vioNonSafety, &m_vioAct, m_egomotion);
m_lastEgoMotionAddedTime = sensorEvent->timestamp_us;
// validity checks:
// dwSignal_checkSignalValidity(m_vio*.validityInfo.*) -> all DW_SUCCESS
// log all timestamps
// log the content of the
}
}
Question:
Is this behavior expected (internal buffering / coalescing / rate limiting), i.e. egomotion only publishes a new estimate on certain “trigger” updates? If yes, what determines when a new estimate is produced (steering vs speed vs wheel, min dt, required field validity, etc.)?
Any hints on which timestamps egomotion uses internally to decide when to integrate/commit would be greatly appreciated.