The override checking was scattered across two places and is now unified
in controls_tick(). The part in mixer_tick only decides which mixer (or
none) to use give the override flag.
This fixes a bug where multirotors got into override mode when the FMU
is dead/not responding.
The main bug was that the check was for FMU_OK || MANUAL_OVERRIDE_OK
in order to get further in the override checks.
Also a mixer_tick was called inside the controls_tick even though these
are called in px4io.c after each other anyway.
* logger: prevent logpath buffer overflows
The handling of the log path had the potential to cause buffer
overflows, especially on POSIX platforms where the paths are often much
longer than just 64 chars.
* sdlog2: prevent logpath buffer overflows
When the log folder path was created, this was done with the unsafe
sprintf function instead of snprintf. This caused buffer overflows in
SITL but the overflow was usually not detected until recent testing of
some work in progress.
- attitude setpoint generation for stabilized mode was shifted back
to the fw attitude controller. since the fw position controller is polling
on global position attitude setpoints were not generated when global
position was not published.
Signed-off-by: Roman <bapstroman@gmail.com>
- generate complete attitude setpoint for position and altitude
control mode
- fix generation of roll setpoint for position control which lead to
wing rock
- add roll and pitch setpoint offsets so that they are logged as well
Signed-off-by: Roman <bapstr@ethz.ch>
The reason for this change is that RPi2 and RPi3 are compatible, and
hopefully all differences coming up can be resolved without ifdefs but
at runtime.
* logger: disable some default topics, which are most likely not used
This is also to safe CPU and lower the amount of file descriptors used.
* logger: use the hrt timer for more accurate scheduling
Under NuttX with the default rate of 285Hz, the actual measured rate was
only 200Hz while on Linux it was ~280Hz. The reason is that NuttX only
uses a usleep() granularity of 1ms, so that the typical sleep time is
longer than what we set.
Now the logger waits on a semaphore, which gets activated periodically
with a hrt timer. With this the measured rate is exactly the expected one,
285Hz.
This fixes a bug with following setup:
- two (or N > 1) connected gyros
- ekf2 enabled
In this case, sensors would publish with the combined rate of the gyros,
but with N following messages having the same gyro data & timestamp.
Apparently ekf2 cannot handle this, the other estimators can.
We may want to rethink what the proper solution is here.
Julian Oes