- GPSDrivers in PX4/Firmware (3e0d06c65167c0bd79c193ea75ca5c7959053ff7): bd72eb6794
- GPSDrivers current upstream: d6940d9c8c
- Changes: bd72eb6794...d6940d9c8c
d6940d9 2021-12-02 alexklimaj - Update F9P moving base with direct UART2 connection
eb0cb58 2021-11-25 sebastian - always using groundspeed for vel_m_s in ubx driver
0408160 2021-11-18 alexklimaj - Remove extra UART1 baudrate set
* ekf2: selector treat combined test ratio > 1 as a warning
* ekf2: wait for 1s of constant warning to trigger an instance switch
Co-authored-by: bresch <brescianimathieu@gmail.com>
Use the same memory allocation in sw_crypto driver as what is used in
src/lib/crypto libraries
In addition, in nuttx protected build, allocate all memory from kernel heap
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
This fixes the following compile error on Mac:
src/drivers/gps/gps.cpp:562:23: fatal error: use of undeclared identifier 'B921600'
case 921600: speed = B921600; break;
^
When scaling manual input, we should only use pitch -90 to +90 instead
of -180 to 180 degrees which leads to weird behavior as it gets passed
on by a quaternion.
It is possible to either set the keyfile locations in board configuration or
with the same environment variables as before.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
This is more logical place for the "backend" implementation than
directly under platform.
This also allows making other implementations as "real" drivers, as well as proper configuration via Kconfigs
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
On Nuttx we have an additional check whether the directory is accessible
to check if we are trying to write to storage that is not on the SD
card. This returns the FileProtected error whereas on Linux this just
ends up being a FileNotFound.
The ifdefs around this issue are not pretty but the alternatives of
either removing the tests for /bogus folders, or removing the additional
check on the NuttX side don't seem better either.
In commit 462b572172 the reading operation
on the PX4 side was changed to only read as many bytes as requested
rather than however many fit in the payload data.
This caused the unit tests to fail which this commit here aims to fix.
What is confusing about MAVLink FTP is that there is a size field which
generally signals how many bytes of the payload data are used/set.
However, in the case of a read requst, the size field is used to
indicate how many bytes should be read. The payload data is empty in
that case though.
This case was, from how I understand it, not implemented/tested in the
unit tests and now failed. In order to implement it I had to change a
few things:
- Change _setup_ftp_msg and _send_receive_msg so that the params contain
a data length rather than the size field. The size field itself needs
to be set outside of these methods using payload->size.
- Since we test files smaller, equal, and bigger than one payload data
length, I implemented that we send multiple read requests until we
have the whole file and not just the first part.
- Additionally, I saw a lot of uninitialized warnings in valgrind, and
got rid of them by adding a few zero initializations.
This check enforced setting a VTOL transition switch if an RC as used on a VTOL.
It comes from a time when the only way to transtion was through the RC switch,
whereas now we have also a mavlink message in place for it, so enforcing it is
no longer needed.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- avoid unnecessary filter reset on parameter update
- additional minor optimizations (precomputing dt inverse, etc)
- moving filter reset check and dynamic notch filter update checks out of the update loops
- this were necessary previously when the scale factor wasn't applied prior to filtering the otherwise raw data