- no longer start sercon or mavlink usb by default
- on USB connection (VBUS) monitor serial USB at low rate and start Mavlink if there's a HEARTBEAT or nshterm on 3 consecutive carriage returns
- the mavlink USB instance is automatically stopped and serdis executed if USB is disconnected
- skipping Mavlink USB (and sercon) saves a considerable amount of memory on older boards
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>
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 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.
The both results of ?: should be of same type, and some compilers give error
on this:
" implicit conversion from 'float' to 'double' to match other result of conditional"
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Instead of only keeping track of the sequence ID of specific "supported"
components, we now keep track of any sysid/compid of an incoming
message. Before this change, unknown components (such as jMAVSim) would
completely screw up the mavlink message stats and create confusion (at
least in my case).
With this change we currently keep track of up to 8 other components.
Once we reach the limit, we will print a warning.
Without these fields the pre-arm check would complain and fail.
Also, the voltage is adjusted to be at around 70% rather than 30% which
would almost start to trigger warnings.
- handle SET_POSITION_TARGET_LOCAL_NED and SET_POSITION_TARGET_GLOBAL_INT with ORB_ID(trajectory_setpoint)
- FlightTaskOffboard not needed at all
- bypass position_setpoint_triplet entirely (start removing extraneous fields)
- simplify offboard_control_mode to map to supported control modes
Adds support for using the MAVLink command MAV_CMD_DO_SET_ACTUATOR to
update the actuator values on control group 3 aux{1, 2, 3}. A simple
deconfliction with rc_update is implemented: when a MAVLink command is
sent, RC is disabled for that channel until a major stick movement is
detected.
We should be using gimbal_manager_information and not
gimbal_device_information. Plus, this updates the fields and flags
according to the MAVLink changes.
- add command to request a message
- add gimbal attitude message
mavlink_receiver handle GIMBAL_MANAGER_SET_ATTITUDE
first implementation of new vmount input MavlinkGimbalV2
- setup class
- decode gimbal_manager_set_attitude in ControlData
add gimbal information message
add gimbal manager information and vehicle command ack
mavlink messages: add stream for GIMBAL_MANAGER_INFORMATION
mavlink_receiver: handle GIMBAL_DEVICE_INFORMATION
remove mavlink cmd handling from vmount input MavlinkGimbalV2
complete gimbal manager:
- send out fake gimbal_device_information for dummy gimbals
- complete ROI handling with nudging
small fixes
fix typos
cleanup
- gimbal device information
- flags lock
- check sanity of string
add support for CMD_DO_GIMBAL_MANAGER_ATTITUDE
stream GimbalDeviceAttitudeStatus for dummy gimbals
- add uROB gimbal_attitude_status
- fill status in vmount output_rc for dummy gimbals not able to send the
status themselves
- stream mavlink GimbalDeviceAttitudeStatus
better handle the request for gimbal infomation request
clean up
bring gimbal information back on vmount init
add new gimbal message to mavlink normal stream
fix publication of gimbal device information
rename gimbal_attitude_status to gimbal_device_attitude_status
stream gimbal_manager_status at 5Hz
mavlink: send information only on request
Sending the information message once on request should now work and we
don't need to keep publishing it.
mavlink: debug output for now
make sure to copy over control data
mavlink: add missing copyright header, pragma once
mavlink: address review comments
mavlink: handle stream not updated
Our answer does not just depend on whether the stream was found but
whether we actually were able to send out an update.
mavlink: remove outdated comment
vmount: add option for yaw stabilization only
The stabilize flag is used for gimbals which do not have an internal IMU
and need the autopilot's attitude in order to do stabilization. These
gimbals are probably quite rare by now but it makes sense to keep the
functionality given it can e.g. be used by simple servo gimbals for
sensors other than highres cameras.
The stabilize flag can also be re-used for gimbals which are capable of
stabilizing pitch and roll but not absolute yaw (e.g. locked to North).
For such gimbals we can now set the param MNT_DO_STAB to 2.
We still support configuring which axes are stabilized by the
MAVLink command DO_MOUNT_CONFIGURE, however, this is generally not
recommended anymore.
vmount: fix incorrect check for bit flag
mavlink_messages: remove debug message
Signed-off-by: Claudio Micheli <claudio@auterion.com>
use device id
remove debug print
gimbal attitude fix mistake
clang tidy fix
split:
- gimbal_attitude -> gimbal_device_set_attitude, gimbal_manager_set_attitude
- gimbal_information -> gimbal_device_informatio, gimbal_manager_information
add gimbal protocol messages to rtps msg ids
support set attitude for gimbal directly speaking mavlink
clean up gimbal urob messages
vmount: address a few small review comments
vmount: split output into v1 and v2 protocol
This way we can continue to support the MAVLink v1 protocol. Also, we
don't send the old vehicle commands when actually using the new v2
protocol.
vmount: config via ctor instead of duplicate param
vmount: use loop to poll all topics
Otherwise we might give up too soon and miss some data, or run too fast
based on commands that have nothing to do with the gimbal.
typhoon_h480: use gimbal v2 protocol, use yaw stab
Let's by default use the v2 protocol with typhoon_h480 and enable yaw
lock mode by stabilizing yaw.
Daniel Agar