Faster than real-time system-wide replay

[bkueng]

We want to be able to replay faster-than-real-time (see replay doc). For that we need to manipulate system time (hrt_absolute_time() and friends). Probably the best way to do this is to use a constant speed-up factor (maybe automatically set). And then maybe report to the user, when the system starts to lose messages (i.e. replay is too fast).

A solution to this is basically independent from replay and highly overlaps with gazebo time simulation (#3615), so we should find a solution that works for both. We need to identify which parts of the system need the time, and in which way (like hrt_absolute_time(), clock, usleep, timeouts (like poll) etc). For some cases we don't want to speedup, for example status output every second or hardware access, like disk timeouts, and probably other cases.

[bkueng]

Related: #5703

[wil3]

Any progress being made on this front? I'm approaching this from the gazebo sitl side. At the moment if the real_time_update_rate parameter is gazebo is modified to run faster than real time flight is completely unstable and results in a crash. In regards to gazebo, the speed up factor in px4 would need to reflect the simulation time, ideally we'd have the simulator time synchronized with certain parts of the system.

It appears, here a realtime factor is computed off of the simulation time. In gazebo each time step will result in each plugins OnUpdate method to be called, which in turn passes MAVLink messages back and forth between px4. So the gazebo time step is really the clock driving everything when doing sitl with gazebo.

Would a solution be to compute the realtime factor upon receiving a MAVLink message from the gazebo plugin but make this available system wide in replacement for hrt_absolute_time() where needed?

[nicolaerosia]

Somewhat related: A MAVLink message with IMU state is sent on each timestep. I noticed that during my cleanup ( https://github.com/PX4/Firmware/pull/7922 ), the rate at which I was receiving messages was 500 Hz although I was only publishing on uORB at a lower rate. A good understanding of the flows can help us reduce the CPU usage during simulation https://github.com/PX4/sitl_gazebo/blob/master/src/gazebo_imu_plugin.cpp#L240 https://github.com/PX4/sitl_gazebo/blob/master/src/gazebo_mavlink_interface.cpp#L428 https://github.com/PX4/sitl_gazebo/blob/master/src/gazebo_mavlink_interface.cpp#L788

[LorenzMeier]

Hi - we could pick this up on the next dev call if you like.

Am 06.09.2017 um 21:30 schrieb Nicolae Rosia notifications@github.com:

Somewhat related: A MAVLink message with IMU state is sent on each timestep. I noticed that during my cleanup ( #7922 ), the rate at which I was receiving messages was 500 Hz although I was only publishing on uORB at a lower rate. A good understanding of the flows can help us reduce the CPU usage during simulation https://github.com/PX4/sitl_gazebo/blob/master/src/gazebo_imu_plugin.cpp#L240 https://github.com/PX4/sitl_gazebo/blob/master/src/gazebo_mavlink_interface.cpp#L428 https://github.com/PX4/sitl_gazebo/blob/master/src/gazebo_mavlink_interface.cpp#L788

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[PX4BuildBot]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[bkueng]

Still relevant. @dagar is there a label so that the bot does not interfere anymore?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[julianoes]

Fixed by #10648