By adding the sequence number we can avoid double triggering due to
command retransmissions. This is according to the mavlink spec for
MAV_CMD_IMAGE_START_CAPTURE.
Using mixers on the IO side had a remote benefit of being able to
override all control surfaces with a radio remote on a fixed wing.
This ended up not being used that much and since the original design
10 years ago (2011) we have been able to convince ourselves that the
overall system stability is at a level where this marginal benefit,
which is not present on multicopters, is not worth the hazzle.
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
Co-authored-by: Daniel Agar <daniel@agar.ca>
With Makefile build, generate_component_general.py was called twice during
build, which did not happen with the ninja build.
This created a race condition with the following error in rare cases:
Traceback (most recent call last):
File "/__w/PX4-Autopilot/PX4-Autopilot/src/lib/component_information/generate_component_general.py", line 79, in <module>
save_compressed(filename)
File "/__w/PX4-Autopilot/PX4-Autopilot/src/lib/component_information/generate_component_general.py", line 33, in save_compressed
with open(filename, 'r') as content_file:
FileNotFoundError: [Errno 2] No such file or directory: '/__w/PX4-Autopilot/PX4-Autopilot/build/px4_sitl_default/component_general.json'
make[3]: *** [src/lib/component_information/CMakeFiles/component_information_header.dir/build.make:68: component_general.json] Error 1
Merging the targets avoids the duplicate execution.
This reverts the behavior for offboard velocity setpoint.
Back in v1.11, the velocity input in NED_BODY was assumed to be in the
world frame but rotated by yaw to the vehicle frame. With the current
state the frame is completely fixed to the body. While this might be
technically correct, it doesn't seem much intuitive for multicopters
and breaks the MAVSDK offboard velocity API.
So as an example, with a velocity setpoint of 5 m/s forward, the drone
would in
- v1.11: fly forward with 5 m/s
- v1.12: start to fly forward by pitching down but then descend rapidly
as the forward velocity would translate to a setpoint in Z into the
ground as it is pitched down.
This commit restores the behavior to what we had previously.
Forward message to other mavlink channels only if it is broadcast or the target component was seen on this link before (at least one message was received)
- sending protocol
- uorb event message & template methods for argument packing
- libevents submodule to send common events and handle json files
- cmake maintains a list of all (PX4) source files for the current build
(PX4 modules + libs), which is used to extract event metadata and
generate a json file
This fixes a tricky bug that we discovered in MAVSDK:
https://github.com/mavlink/MAVSDK/pull/1464
It turns out the target_system and target_component fields can
potentially be:
1. at the end of a message payload,
2. and zero,
and therefore they get trimmed. When you then try to read it you
potentially read some garbage from the CRC fields.
This makes sure that the vehicle_command topic is properly
initialized from the beginning.
orb_exists returns -1 or 0 and not a bool as one would expect.
This adds support to handle INT32_MAX for COMMAND_INT.x/y by converting
it to NAN internally.
It also adds paranoid checks to prevent:
- NAN being used sent by a COMMAND_INT by mistake.
- INT32_MAX being used sent by a COMMAND_LONG by mistake.
Nicolas Martin