* added ability to slew rate limit the roll angle output of the l1 controller
* FixedWingPositionControl: this avoids the steps in roll angle setpoint which occur when the controller
switches to a new waypoint
* GroundRoverPositionControl: adapted to new l1 API
- running at max priority significantly decreases jitter for the latency
test, providing more consistent results
- stack size increase is required for the latency test
To avoid that multiple SITL instances have the same UUID we add the
mavlink system ID to the UUID which is sent via mavlink.
This should resolve the case where multiple vehicles show up with the
same UUID in simulation.
Note that the UUID show in `ver` will still be the same for all
instances.
Temperature compensation is not supported in HITL. Therefore, don't try
and fail. This basically removes the confusing error message that we get
in HITL.
Modules generally do not check for a valid timestamp, thus we need to avoid
publishing invalid data.
This is for example problematic in the attitude_estimator_q, if the
system has no mag: it will copy the (invalid) data and then fails to
initialize, as there is no more mag data coming in.
The controls_tick() rate exceeds the rate at which RC receivers
provide digital rssi. As such, most ticks set PX4IO_P_RAW_RC_NRSSI
to 0.
This change promotes the controls_tick() local variable 'rssi' to
static storage so that it doesn't have to be updated every tick to
keep the correct value in PX4IO_P_RAW_RC_NRSSI.
On SPM4649T receivers with firmware versions at least 1.1RC9, the
serial data will contain an rssi value in dbm, as outlined in the
Remote Receiver Interfacing document section 8.3.1.
If the value received is greater than or equal to zero, the receiver
does not support rssi data, and the incoming value will be ignored.
However, if the value is negative, we can use the rssi value.
When we have a valid rssi, it gets mapped to a percentage from 0 to
100 as expected by mavlink. This mapping is constructed as a
logarithmic function over Spektrum's published minimum and maximum
rssi values, -92dBm to -42dBm as 0 to 100:
100 Log10[1 + (x - min) * (9 / (max - min))]
This change updates all calls to the dsm input rountes to return
the rssi value.
Note that one place this doesn't work with the px4io enabled.
There is a comment left in the absence of analog rssi that:
"we do not actually get digital RSSI regs[PX4IO_P_RAW_RC_NRSSI]".
This restriction has been left in place, as removing it exposes a
problem where the frequency of the control tick is greater than
that of valid dsm frames so the rssi isn't valid every cycle.
Daniel Agar