Switch to positive tangential velocity being clockwise because with NED
frame z-axis points down and mathematically positive around the z-axis
results in clockwise yaw rotation when seen from above. Also MAVLink
messages and other components in PX4 are defined this way.
The handling for vehicle commands inside the FlightTasks library
was already there but commented out because the previously used
MAVLink messages were tied to the specific application we used and
there was no clean common message definition. Because there is now
a well defined message for the orbit task I'm uncommenting and using
the working message handling again here.
Nice smooth altitude control is already provided by the existing
flight task for altitude mode. We inherit from it to resuse the
functionality and just all its update first not altering the setpoints
for the z-axis it produced.
Maximum velocity achievable in 4 seconds,
maximum radius achievable in 8 seconds for futher testing.
These should be parameters as soon as it works fine.
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.
- every incremental rebuild extended ${config_romfs_files_list}, the
chached variable was never reset
- cmake -E copy_directory did not remove deleted files
remaining issue: removing a file from the ROMFS & px4_add_romfs_files()
does not trigger the px_romfs_pruner.py COMMANDs to be re-executed.
The px4io driver was ignoring the contents of PX4IO_P_RAW_RC_NRSSI
since digital rssi wasn't working properly. This change was made in
commit 41b127d40.
Now that PX4IO_P_RAW_RC_NRSSI is returning valid values for digital
rssi, we can re-enable its use.
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.
Squashed commits:
[ed2a243] FlightTasks: Preserve control loop tuning when applying max altitude limit
[b33b947] FlightTasks: Add terrain hold function
This new mode of altitude control uses terrain following when holding position and normal altitude control when moving.
Rather than initializing the rssi percentage lookup table at runtime
on the heap, we would like it to be stored in flash.
This change pre-computes the rssi lookup table.
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.
