This removes the odd px4_i2c_bus_external override which was confusing
me and lead to odd and inconsistent results.
The function is now only available with an int as the argument.
When a mission starts capturing images using the
MAV_CMD_IMAGE_START_CAPTURE command, it should also stop it again, in
case it is stopped early, e.g. with RTL.
As I understand it, only Rev 3 and Rev 4 were shipped by HB for Mini and
CM4, and are likely to be used for it.
It would be nice to have all combinations but it requires quite some
flash in the current implementation.
Without this, uavcan creates MixingOutput classes which then create
empty actuator_outputs publications. This then prevents the motor
output in HITL to be forwarded to the simulator via mavlink.
We use lockdown to prevent outputs like motors and servos from being
active in HITL simulation. This means that we can't treat the lockdown
flag as a flight_terminated, otherwise we can't arm in HITL at all.
PX4 supports int32 parameter types by interpreting the 32 bits in
the float field as an int32 field. To signal this behaviour, it should
set the bit which is described as PARAM_ENCODE_BYTEWISE.
PX4 had always handled parameters this way but never actually sent the
capability (which back then was called PARAM_UNION), however, it should
have. This came up recently in the MAVLink devcall when these flags were
discussed. The takeaway was to remove the flags to make it clearer and
to make sure the projects (like PX4) send them out correctly.
Once we have valid input we should use that and not overwrite our
update_result with the result from other inputs, otherwise the
automatic selection does not actually work.
This behavior means that only the first update will be used if there are
several sources updating in the same cycle.
This is a bigger refactor of vmount to clean it up and plug some holes
in functionality.
The changes include:
- Fixing/simplifying the test command.
- Changing the dependencies of the input and output classes to just the
parameter list.
- Adding a separate topic to publish gimbal v1 commands to avoid
polluting the vehicle_command topic.
- Removing outdated comments and author lists.
- Extracting the gimbal v2 "in control" notion outside into control_data
rather than only the v2 input.
If we receive gimbal_device_attitude_status by mavlink we should not
re-send it as we are already supposed to be forwarding mavlink traffic
from the gimbal to the ground station.
I don't think the PX4 setup script should decide whether a user is to
use ccache or not. Anecdotally, I've heard from some in the dev team
that they are not using it themselves, so I don't think there is a good
basis to push it onto others.
That being said, we can of course still use ccache as part of the CI
builds nevertheless.
The boot order is now:
1. The PX4 bootloader boots, and starts the camera.
2. The camera starts and sends the boot command to the PX4 bootloader.
3. PX4 starts.
This changes the way RC is handled for the Mantis:
- The RC values are re-written when arriving over MAVLink. They are
rescaled from 0..4095 to 1000..2000 and the channel bits added to
separate channels. This makes the downstream handling easier.
- Gimbal pitch is moved from Aux1 to Aux2 as that should be the default.
- Aux3 and Aux4 are used for the photo and video trigger.
- The speed button is used as the FLTMODE channel and set to switch
between POSCTL and ALTCTL.
This adds a check for the previous SYS_AUTOSTART id. If it is still the
old/previous SYS_AUTOSTART id, it will flash the new bootloader as well
as set the proper SYS_AUTOSTART id.
From what I can see the CONFIG_BOARDCTL_POWEROFF is not really used
anywhere, however, the BOARD_HAS_POWER_CONTROL is something that is set,
e.g. for the Mantis, to allow power off.
To play a power off tune, I needed to convert the file to C++, so that I
could use the uORB::Publication.
The current implementation starts playing the power off sound but then
stops it as soon as the button is released.
The problem is mostly that we only get an interrupt when the button is
pressed or released but we don't seem to be able to poll it, at least
not in the current state.
The limits might somewhat match the sensor, guessed based on the
original driver.
The quality is set so that spikes when sitting on the ground are not
used.
So instead of fuzzing each and every PR for 10minutes, we just fuzz
30mins every 24 hours, at 6am UTC which should be a time when US and
Europe might be least active.
This adds the env option PX4_FUZZ which runs the LLVM libFuzzer which
throws random bytes at mavlink_receiver using MAVLink messages over UDP.
The MAVLink messages that are being sent are valid, so the CRC is
calculated but the payload and msgid, etc. are generally garbage, unless
the fuzzing gets a msgid right by chance.
As I understand it, libFuzzer watches the test coverage and will try to
execute as much of the code as possible.
This is an attempt to fix the test failure where PX4 detects an RC
timeout presumably because the tester process mavsdk_tests is stalled
and does not send RC control messages in time.
The imu and sensor_combined data should not be used when it has not been
updated yet, otherwise this triggers a memory sanitizer warning:
Conditional jump or move depends on uninitialised value(s)
at 0x2DA7AA: __sanitizer_cov_trace_const_cmp1 (in build/px4_sitl_default-clang/bin/px4)
by 0x3C4E79: EKF2::Run() (src/modules/ekf2/EKF2.cpp:401)
by 0x6EB881: px4::WorkQueue::Run() (platforms/common/px4_work_queue/WorkQueue.cpp:187)
by 0x6ECB9D: px4::WorkQueueRunner(void*) (platforms/common/px4_work_queue/WorkQueueManager.cpp:230)
by 0x4C07258: start_thread (in /usr/lib/libpthread-2.33.so)
by 0x4D415E2: clone (in /usr/lib/libc-2.33.so)
Conditional jump or move depends on uninitialised value(s)
at 0x3C4E7C: EKF2::Run() (src/modules/ekf2/EKF2.cpp:401)
by 0x6EB881: px4::WorkQueue::Run() (platforms/common/px4_work_queue/WorkQueue.cpp:187)
by 0x6ECB9D: px4::WorkQueueRunner(void*) (platforms/common/px4_work_queue/WorkQueueManager.cpp:230)
by 0x4C07258: start_thread (in /usr/lib/libpthread-2.33.so)
by 0x4D415E2: clone (in /usr/lib/libc-2.33.so)
This prevents a memory sanitizer/valgrind warning:
Conditional jump or move depends on uninitialised value(s)
at 0x2DA536: __sanitizer_cov_trace_cmp4 (in build/px4_sitl_default-clang/bin/px4)
by 0x6590D8: FailureDetector::update(vehicle_status_s const&, vehicle_control_mode_s const&) (src/modules/commander/failure_detector/FailureDetector.cpp:76) by 0x3817DF: Commander::run() (src/modules/commander/Commander.cpp:2605)
by 0x38B10B: ModuleBase<Commander>::run_trampoline(int, char**) (platforms/common/include/px4_platform_common/module.h:180)
This enables flow control on CDCACM for the NuttX boards which fixes a
problem where HITL would stall.
The stall could happen if the hardware would be a bit too slow in
keeping up with the incoming messages. Often, this happened on arming
because the logger would take some time to log all parameters right at
the beginning.
The stall would then not recover due to NuttX bug where the rx interrupt
would not be restored correctly and instead only a slower watchdog would
release the next read. This watchdog takes 200ms which means it's hard
to impossible to get out of the situation without restarting sim and/or
PX4. For more information about the issue, see:
apache/incubator-nuttx#3633
As a workaround, until that bug is fixed, and because it makes sense
anyway, I propose to enable FLOWCONTROL for the serial via USB.
This enables the use case where the gimbal v2 protocol is used
between the ground station and the drone, and the gimbal v1 protocol is
used between the drone and the gimbal.
Julian Oes