You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Telemetry should be integrated in replays via tlogs in the same way as live viewing supports it.
Additional information
Live viewing allows auto-rotation via telemetry integration, but it's not possible to link a tlog file when doing replays, so the initial correctly-rotated display can only be seen live. This means visual inspection and analysis after a dive requires recording the screen, which seems unnecessary when both relevant data streams are also already being recorded.
Including telemetry in replays also makes it possible to compare display options given the same set of inputs, which can be important when determining the usefulness of a given setting.
The text was updated successfully, but these errors were encountered:
As an alternative it may be worth Ping Viewer recording the heading it receives from the autopilot as part of its binary data logs. Maybe we could make a generic "sensor heading" message in the ping-protocol to support this, and just convert the received MAVLink messages to that for logging purposes?
That wouldn't be as temporally accurate as doing a replay from an autopilot DataFlash log, for example, but would at least allow replaying the scan as it was displayed at the time of recording. It could also be useful for more generically supporting other data input types (e.g. if someone wants to manually record their ping data through a script and play it back with Ping Viewer later).
Summary
Telemetry should be integrated in replays via tlogs in the same way as live viewing supports it.
Additional information
Live viewing allows auto-rotation via telemetry integration, but it's not possible to link a tlog file when doing replays, so the initial correctly-rotated display can only be seen live. This means visual inspection and analysis after a dive requires recording the screen, which seems unnecessary when both relevant data streams are also already being recorded.
Including telemetry in replays also makes it possible to compare display options given the same set of inputs, which can be important when determining the usefulness of a given setting.
The text was updated successfully, but these errors were encountered: