This goes the other way around; arch_io_pins is using the pin
definitions from drivers_board, so the drivers_board needs to be linked
into arch_io_pins
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Since uORB is split into kernel and userspace parts, it is no longer possible to just
link uORB into px4_platform, which is used in both kernel and user side.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Define __KERNEL__ macro during compilation and place the module in separate library
Remove default library linking to m or libc on NuttX. Add these in platform layer instead, since
they are different on kernel and user side
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
The needed version specific things come from px4 layer. Since version
is used both in kernel an user sides in protected build, it can't directly
link to drivers_board
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
For NuttX protected or kernel build, the prebuilds can't contain libraries which are
different for kernel and user-space in protected/kerenl builds
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
- introduces new parameter EKF2_PREDICT_US to configure the filter
update period in microseconds
- actual filter update period will be an integer multiple of IMU
This is done by inheriting from FlightTaskManualAltitudeSmoothVel again.
The altitude change by command is taken care of by switching
to the apporach when the altitude difference is big enough and
switching back once the altitude is close enough.
The altitude of the command is not perfectly reached but this can
only be done smoothly when the Orbit has full control over the
altitude smoothing. The independent altitude smoothing is not kept
because it was lacking stick handling like altitude lock and smooth
transitions when opening and closing the vertical position loop.
I think they were forgotten and it leads to side effects:
- The acceleration feed-forward does not get executed
- The acceleration setpoint is NAN when initializing the altitude
smoothing when arriving at the circle
The existing logic using the angle between velocity vectors failed to
determine a yaw failure in practice because the state velocity is often
too small compared to its uncertainty to be used. In all the failures
reported, the yaw emergency estimator converged properly and yaw reset
would have fixed the issue.
A much simpler check using the yaw difference between the main EKF
and the emergency estimator is now used to tell if the vel/pos update
failure is most likely caused by a wrong heading.