Like other vehicles (which use RC_SPEED), ESC_RATE is used to set the
PWM output rate for outputs whose functions are set to MotorN so that
ESCs can be driven at a fast speed (400Hz, same default as aerial
vehicles) while servos still run at normal speed (50Hz, controlled by
OUT_RATE).
Airspeed calculation for JSON was not quite working because velocity_air_ef was not updated in SIM_JSON.cpp
Update libraries/SITL/SIM_JSON.cpp
Co-authored-by: Peter Hall <33176108+IamPete1@users.noreply.github.com>
Update libraries/SITL/SIM_JSON.cpp
Co-authored-by: Peter Hall <33176108+IamPete1@users.noreply.github.com>
comment changes
remove redundant airspeed calculation
this makes the assumption that any reboot done within a SITL was because some parameter changes only take effect after a reboot.
... so after we have reverted the parameters, reboot again to make the reverted parameter values take effect
Probably won't work correctly (and of questionable use) if less than 1.
The `first_set()` function might not be able to return a valid value if
greater than INT16_MAX.
unsigned int needs to be >= uint32_t so that the shift ops are in range.
Ensures out-of-bounds reads and writes are never performed for setting,
clearing, and checking. Fixes test failure when the number of bits
evenly divides the word size.
Fixes an issue where the last word was not set to all 1s if the number
of bits evenly divided the word size.
Also fixes UB if there were 31 valid bits.
We used to produce files hwih looked like log1.BIN. We moved to 00000001.BIN instead so things collate.
This code allowed the autopilot to return data from SD cards which had old logs on them.
this is only used in one place, and that place is called from the same routine setting the persistent state. The only other place which calls readIMUData shouldn't be running the prediction step, but mmay, depending on the previous setting of the prediction step.
We are not initialising this state on filter reset, so it's possible that the state will be set when we do an InitialiseFilterBootstrap, which is probably not desired
This stops us tracking formats-written in two places.
The Write() method will now emit formats as required and set the relevant bit in the backend-owned bitmask of formats sent.
we're running at large speedups; 5 simulated seconds might not be enough time for MAVProxy to accumulate statistics. So get MAVProxy to emit the rate each second instead
