- publish wind estimate only from EKF, and wind speeds from airspeed selector to new separate topic (airspeed_wind)
- rename message wind_estimate to wind
- publish wind from currently used ekf instance (ekf2selector)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
It was for example possible that DSM got parsed, and in the next iteration
SBUS got parsed, leading to multiple PX4IO_P_STATUS_FLAGS_RC_ flags set.
input_rc::input_source was then incorrectly set to DSM.
Partially guarding was already done: if SBUS got parsed, DSM and others
were skipped.
The IO will still clear all PX4IO_P_STATUS_FLAGS_RC_* flags on RC loss.
We use the stabilize param to set the input. Like this the input flags
can be changed using the configure message later, and then eventually
used in the output.
This includes several changes to fix POI when used with MAVLink gimbal
v2 input:
- Correctly set capability flag that POI is supported.
- Keep lat/lon and calculate attitude on each cycle, instead of only
once on init.
- Always publish gimbal manager information, with or withoug gimbal v2
device.
We should be using gimbal_manager_information and not
gimbal_device_information. Plus, this updates the fields and flags
according to the MAVLink changes.
This should fix the case where AUX gimbals don't work anymore when
gimbal input is mavlink gimbal v2.
The fix is mostly to take care against NAN inputs.
This is a hotfix to restore gimbal functionality for SITL set-ups that
are set to MNT_MODE_IN 4 (gimbal protocol v2) but still need to accept
gimbal v1 commands that might be part of a mission, e.g. uploaded by
MAVSDK.
This is a hack to make sure the messages from the gimbal arrive at other
links (e.g. the ground station). It means that the gimbal does not get
flooded with all other messages that would get forwarded but messages
from the gimbal will still make it through.
- 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.
- new heater_status logging message
- run continously at low rate until configured sensor is found
- fix px4io fd bugs (fd open/close/ioctl must be same thread)
* Commit for the Integration of a position controller for the a Underwater vehicle.
This module is an extension of the uuv_att_control to control an Underwater vehicle to any position, given by the SET_POSITION_TARGET_LOCAL_NED which includes x y z yaw.
Since the position control is designed for a 6DOF Robot, the roll and pitch angle are controlled to be 0.
Additionally there is a stabilization control, which holds the robot at a defined depth, and not move in any direction.
In general the idea is to have this position module to control the position of the uuv. The position module reseives the desired position of the uuv and sends appropriate attitude setpoints to the uuv_attitude_control module.
Additionally the mixer file is adapted, to include the 6 different inputs(x y z roll pitch yaw).
* Commit for the Integration of a position controller for the a Underwater vehicle.
This module is an extension of the uuv_att_control to control an Underwater vehicle to any position, given by the SET_POSITION_TARGET_LOCAL_NED which includes x y z yaw.
Since the position control is designed for a 6DOF Robot, the roll and pitch angle are controlled to be 0.
Additionally there is a stabilization control, which holds the robot at a defined depth, and not move in any direction.
In general the idea is to have this position module to control the position of the uuv. The position module receives the desired position of the uuv and sends appropriate attitude setpoints to the uuv_attitude_control module.
Additionally the mixer file is adapted, to include the 6 different inputs(x y z roll pitch yaw).
Currently not solved/missing:
- Problem with gazebo model(propeller moving chaotically).
- Mixer correct gazebo vs real life (has to be tested in the future)
- correct integration in uuv.apps (when choose which module)
- very basic controller chosen (could be improved a lot in the future)
* Remove error caused by unused variables and a different build error
* added better description of the parameter. Additionally the group is changed.
* added better description of the parameter. Additionally the group is changed.
Fixed bug about parameter
* Added EOF to the files.
* Removed parameter for direct position control for safety reasons.
* small bugfix
- keep `vehicle_control_mode` last state in commander and use appropriate flags in place of various main_state and nav_state checks
- consolidate scattered arming requirements in `arm_disarm()`
- there were a number of different requirements from arming via RC vs Mavlink that don't make any sense
- if geofence enabled require valid home before arming
- throttle requirements for manual modes
- remove unnecessary mavlink feedback that differs between arming interfaces (mavlink vs RC)
- let the preflight/prearm checks respond directly in most cases
Co-authored-by: Matthias Grob <maetugr@gmail.com>
It is more intuitive to use the roll stick as lateral control input given that drones defined this category, plus this is how consumer car / rover radio controls have been working already.
