SITL: allow setting jsbsim_ext sim rate multiplier #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
spernsteiner
added a commit
to GaloisInc/VERSE-OpenSUT
that referenced
this pull request
Feb 14, 2025
autopilot: update ardupilot submodule This pulls GaloisInc/verse-ardupilot#2, which allows setting a sim rate multiplier for `jsbsim_ext`, which is required for OpenSUT autopilot setup.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I noticed recently that the OpenSUT autopilot is completely non-functional - instead of initializing sensors in a few seconds and letting the user start the mission, it slowly initializes them over the course of several hours (I ran it for 3+ hours and it never reached the "pre-arm good" state) while constantly dropping the connection to MAVproxy. After several days of debugging and a bit of archeology, I found this commit on my old laptop, which apparently I forgot to push when creating #1. Adding this commit fixes the bug.
The actual change in this commit is to allow the JSBSim update rate to be an integer multiple of the autopilot's update rate. The performance overhead of the OpenSUT's nested VM setup means the autopilot update rate can't exceed ~300 Hz, but JSBSim's update rate must be at least 400 Hz (ideally much higher) or else the simulation becomes unstable. To work around this, we run JSBSim at 2500 Hz and run the autopilot at 250 Hz with a sim rate multiplier of 10x. The autopilot needs to be aware of the sim rate multiplier because the autopilot itself is responsible for driving the simulation - it periodically sends commands to JSBSim instructing it to advance the simulation by a certain amount.
I haven't fully investigated the previous bug, but my guess is that the autopilot was timing out waiting for updates from JSBSim. The autopilot was expecting an update after each step, but JSBSim was sending updates only every 10 steps.