Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Get Replay running again #13885
This is a small-effort attempt to get Replay running in the form that it has traditionally run in, feeding sensor data in from our existing BARO, GPS messages etc.
It does run, and does reproduce both successful replication of a flight and at least one (justifiable!) FPE.
Future work will look at changing Replay to log input to the EKFs as separate messages which should give us a less-prone-to-break tool.
NKQ is a generated name - don't copy it across to output Stop whinging about presence of NKF6 and friends; we know these generated names are not going to be present in modern logs memcpy rather than strncpy within log_FMT Correct strings vs optionally-terminated structure entries in sanity checks Call AP_Param::load_all() to start the parameter saving thread. AP_Compass' init() method now saves parameters (compass reordering), and because we're disarmed we will block until the parameter is pushed onto the to-save queue; if there's no thread popping off that list we block indefinitely. Remove duplicate definitions of various singleton objects. Replay: write out GPS message to output log Useful for diagnosis, but also because we struggle to find a time base without this and the pymavlink tools take forever to work Replay: set COMPASS_DEV_ID and COMPASS_PRIO1_ID so EKF gets mag data Replay: avoid use of system clock; use stopped-clock only Replay: constraint to emitting output for single core only
We haven't initialised the GCS at all, so it's not a great idea to update_receive() and the like.
Uusally problems evidence themsleves with stdin not working correctly - for example, "git add -p" skipping through all queries as if the user was just pressing enter.