system_state.fmu_data_received_time can be set from an IRQ handler, thus
we need to ensure every read access to it in mixer_tick is atomic.
So we read it once and copy it into a local variable.
- use a linked-list instead of std::vector. Insertion and removal are now
O(1)
- avoid malloc and use a thread_local instance of TimedWait.
It gets destroyed when the thread exits, so we have to add protection
in case a thread exits too quickly. This in turn requires a fix to the
unit-tests.
- the flash-backend is selected by specifying nullptr as file or -1 as fd
- the default file is nullptr, and thus the FLASH
- 'param select' has no effect, FLASH is always the default
Thus there should be no functional change to existing setups.
tone_alarm was started before the parameters were loaded, and the first
tune was played before that as well. CBRK_BUZZER was then read as default,
ignoring the user-configured value.
We now start tone_alarm after we load the parameters. Note that a
previously published startup tone or SD card error will still be played.
This is more accurate, because if we use -1000 as lower bound, a very large
yaw command can reduce thrust more than needed.
The difference can be seen in the following example
(with roll/pitch airmode):
p_dot_sp = -1.0 # roll acceleration
q_dot_sp = 0.9 # pitch acceleration
r_dot_sp = -0.9 # yaw acceleration
To run:
cd src/lib/mixer
make tests
This will validate the C++ implementation by taking the python
implementation as ground-truth. It runs through various actuator control
command values for all airmode variations and several mixer types.
The python script also allows to prototype new mixer algorithms.
It is not integrated into the existing build system, because it's easier
to use that way, with less dependencies, and faster testing workflow.
It could however be a bit more integrated.
Reference: https://github.com/Auterion/Flight_Control_Prototyping_Scripts/tree/master/control_allocation
Provides a more generic desaturation algorithm, making it easier to
handle the different mixer strategies.
python reference implementation:
https://github.com/Auterion/Flight_Control_Prototyping_Scripts/tree/master/control_allocation
The behavior for non-airmode and roll/pitch airmode should be the
same as before.
CPU load is slightly higher for the non-airmode case (+0.5%), for airmode
it is the same.
Also update some comments.
In case we activate the task and don't have a locked yaw, we should
initialize the yaw setpoint with NAN to avoid any abrupt changes.
When switching back from rate to attitude control, the code depended on a
vehicle_control_mode topics update, but the publication frequency of that
is low. So the switch was noticeably delayed.
- better in terms of dependencies:
- the position controller code depended on position topics for yaw
- mc_pos_control does not have to be run for Stabilized mode
- the code path is much simpler, and thus less error prone. This is
especially important since Stabilized is often used as a fail-safe flight
mode.
Previously when switching e.g. from stabilized from acro, the stabilized
flight task kept running and publishing setpoints.
Luckily it caused no problems, but the log showed arbitrary attitude
setpoints.
As there is only one bit used in 'flags', and it is only used in case
update_interval is not null, we can move the bit to UpdateIntervalData.
The size of UpdateIntervalData does not increase (on 32 bit).
Reduces RAM usage by 3.6KB (tested on a Pixracer).
- fsync can be a long blocking operation, so we need to make sure the main
logger thread does not block during this time, when it tries to aquire
the mutex
- fixes calling fsync on an invalid file descriptor
The rate controller is now run directly after a gyro publication, and
as soon as it publishes the actuator controls, the output driver (fmu/...)
runs.
Test on a Pixracer:
Reduces fmu control latency from 219us to 134us.
If we run the rate controller last (same order as before, just increase
the prio), the latency is 201us.
CPU load is unchanged.
The drawback is that the attitude to rate setpoint generation is delayed
by one cycle (4ms), but it will be reduced to 1ms as soon as we run at
1kHz.
- mission logs are stored in a separate directory mission_log
- It's disabled by default
- Does not increase RAM usage if disabled (if enabled, only 300 bytes)
- Log rotate does not apply to the mission logs
Previously the formats of all known uorb messages were written.
- reduces header size by about 13KB
- reduce ulog_message_format_s size to reduce required stack size.
Largest message format is about 1000 bytes.
Previously the acceptance radius was 0, so the FlightTaskAutoLine was
randomly changing yaw and sometimes going into a random direction.
There is still something else wrong in there, but avoids the reposition
problem.
The hover thrust param also changed the thrust scaling in Stabilized mode.
However if the hover thrust is very low (e.g. below 20%), the throttle
stick input becomes very distorted.
- no airframe changes the default
- it does not make much sense to be able to configure the 0.1 threshold
but the 0.3 threshold for ground contact detection cannot be configured.
The typhoon has a 6011_typhoon_h480.post script that got matched as well.
Now we exclude all files that contain a dot (apparently it's not so easy
to do generic pattern matching in a portable way, but this works).
board_get_px4_guid() called board_get_uuid() with a 2 bytes offset into an
uint8_t array. This gives no guarantees on alignment, and board_get_uuid()
casts it to an uint32_t array, leading to potentially unaligned accesses.
Beat Küng