Fixes the issue by setting the timestamps using the system's raw monotonic clock with armarx::rtNow(), as expected by the used RobotAPI code.
This is inconsistent with the rest of the RobotUnitSimulation-component, which exclusively uses the system's realtime or the time provided by a timeserver, but consistent with the timestamps set by the real-robot units.
I don't expect this to break anything (at least as long as the timeserver-functionality isn't used), as this change just adapts the behavior of the simulated RobotUnits to match the (correct) behavior of the real-robot RobotUnits.
Christian Dreher authored