This feature allows user to use a Gripper type pacakge delivery
mechanism on a drone to trigger the delivery during a mission via the
mission item `DO_GRIPPER`.
This is a minimal change that is intended to have simplest pacakge
delivery feature on PX4, however the future scope would extend this
feature out of Navigator, and rather move towards a federated PX4
(flight-mode flexibility) architecture. But until then, this will serve
the purpose.
Update Tools/sitl_gazebo submodule to remove sdf file overwrite error
- There was an error happening due to .sdf file being overwritten, it
was caused by a wrongfully added. sdf file.
- This update pulls in the PR commit: https://github.com/Auterion/sitl_gazebo/pull/147
Initial cut on supporing PAYLOAD_PLACE mission item
Tidy and comment on navigation.h to clarify mission item definition
- Convert vehicle command ack subscription data type to
SubscriptionData, to not care about having a dedicated struct for
copying the latest data
- Tidy and comment on navigation.h to clarify the definition of
mission_item_s, which is confusing as it is an intergration of MAVLink
Standard into PX4's internal Mission Item structure
Rename mission_block's mission item reached function & cleanup navigator
- Isolated Handle Vehicle Commands function inside the Navigator
- Rename mission_block's mission item reached function to 'reached or
completed', as the navigation command can also be an action (e.g.
DO_SET_SERVO, which doesn't make sense to refer to as 'reached' when we
have successfully done executed the command)
Include MAVLink PR commit to include payload_drop message
More changes to add payload_drop MAVLink message support
- Comitting for testing purposes
Add mission item payload_drop to vehicle command payload drop link
- Now with a mission item with the nav_cmd set to 'payload drop', the
appropriate 'payload drop' vehicle command will be issued
Make Payload drop executable via Mission Plan
Implement payload_drop module to simulate payload delivery
- Simple module that acknowledges the payload drop vehicle command after
certain time, to simulate a successful delivery
Additional changes - payload drop module not working yet
- Need to do more thread stuff to make it work :(
Fix Payload Drop enum mismatch in vehicle_command enums
- First functional Payload Drop Implementation MVP
- Simple Ack & resuming mission from Navigator tested successfully
Hold the position while executing payload drop mission item
- Still the position hold is not solid, maybe I am missing something in
the position setpoint part and all the internal implications of
Navigator :(
Add DO_WINCH command support
Some fixes after rebase on develop branch
- Some missed brackets
- Some comment edits, etc
Add DO_WINCH command support
- Still has a problem of flying away from the waypoint while the
DO_WINCH is being executed, probably position setpoint related stuff :(
Apply braking of the vehicle for DO_WINCH command
- Copies the behavior of NAV_CMD_DELAY, which executes a smooth, braking
behavior when executing the delay because of the braking condition in
`set_mission_items` function
- This will not apply to Fixed wings
- The payload deploy getting triggered may be too early, as right now as
soon as the vehicle approaches the waypoint within the acceptance
threshold, the payload gets deployed
Add DO_GRIPPER support
Implement Gripper actual Hardware triggering support
- Currently not working, possibly in the mixer there's a bug
- Implemented the publishing of actuator_controls_1 uORB topic
- Implemented the test command for the payload_drop module, to test the
grpiper functionality
- Edited px4board file to include the payload_drop module
- Added Holybro X500 V2 airframe file, to enable testing on X500 V2
- Created new Quad X Payload Delivery mixer, which maps the actuator
controls 1 topic's data into the MAIN pin 5 output
Make Payload Drop Gripper Work
- Initialization of the Gripper position to CLOSED on Constructor of the
payload_drop module
- Setting the OPEN and CLOSED value to the appropriate actuator controls
input
Set vehicle_command_ack message's timestamp correctly
- By not setting the timestamp, the ack commands were not correctly
graphed in PlotJuggler!
Rename payload drop module to payload deliverer
- I think it's a more complex name (harder to type), but more generic
Add Gripper class (WIP)
Add Gripper class functionalities
- Add gripper uORB message
- Add gripper state machine
Use Gripper class as main interface in payload_deliverer
- Utilizes Gripper class functions for doing Gripper functionality
Remove mixer based package delivery trigger logic
- Remove custom mixer files that mapped actuator controls to outputs
statically
Additional improvements of the payload_deliverer
Fix payload_deliverer module not starting
- _task_id wasn't geting set appropriately in task_spawn function, which
led to runtime failure
Add Gripper Function to mixer_module
- Still not showing up as function mapping in QGC, needs fix
Add parameters to control gripper behavior
- Now user can enable / disable gripper
- Also select which type of gripper to use
Applying review from nuno
Remove timeout fetching from mission item and use gripper's timeout
- Previously, it was planned to use a custom DO_GRIPPER and DO_WINCH
MAVLink message definitions with information on timeout, but since now
we are using original message definition, only relevant timeout
information is defined in the payload_deliverer class
- This change brings in the timeout parameter to the Navigator, which
then sets the timeout in the mission_block class level, which then
processes the timeout logic
Make payload deployment work for Allmend test :P
Support gripper open/close test commands in payload_deliverer
Move enum definition for GRIPPER_ACTION to vehicle_command.msg
Remove double call for ` ${R}etc/init.d/rc.vehicle_setup`
- Was introduced during the rebase
- Was causing module already running & uORB topic can't be advertised
errors
Fix format via `make format` command
Modify S500 airframe file to use for control allocation usage
- Added Control allocation related parameters as default to not have it
reset every time the airframe is selected
Implement mission specific payload deploy timeout and more changes
Switch payload_deliverer to run on work queue
Remove unnecessary files
- Airframe changes from enabling control allocation are removed
Address review comments
- Remove debug messages
- Remove unnecessary or verbose comments & code
- Properly call parameter_update() function
Switch payload_deliverer to scheduled interval work item & refactor
- Switch to Schedeuled on Interval Work Item, as previous vehicle
command subscription callback based behavior led to vehicle comamnd ack
not being sent accordingly (since the Run() wouldn't be called unless
there's a new vehicle command), leading to ack command not being sent
out
- Also, old vehicle commands were getting fetched due to the
subscription callback as well, which was removed with this patch
- Fix the wrong population of floating point param2 field of vehicle
command by int8_t type gripper action by creating dedicated function
- Refactor and add comments to increase readability
Add gripper::grabbing() method and handle this in parameter update
- Previously, the intermediate state 'grabbing' was not considered, and
when the parameter update was called after the first initialization of
the gripper, the grab() function was being called again, which would
produce unnecessary duplicate vehicle command.
- Also replaced direct .grab() access to sending vehicle comamnd, which
unifies the gripper actuation mechanism through vehicle commands.
Navigator: Change SubscriptionData to Subscription to reduce memory usage
- Also removed unused vehicle command ack sub
PayloadDeliverer: Remove unnecessary changes & Bring back vehicle_command sub cb
- As it is always only used for the vehicle command ack message
- It was a duplicate, hence making it error prone for maintainment
- The uORB message comments were updated to make the relationship with
the MAVLink message / enum definitions clear
They cause problems with building px4_msgs in ROS2 Humble Hawksbill and removing them fixes the issue.
Co-authored-by: Agata Barcis <agata.barcis@tii.ae>
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.
The arming button required some refactoring in order to support to
toggle arm/disarm using the vehicle_command. Otherwise manual_control
would have to subscribe to the arming topic and we would spread out the
logic again, and risk race conditions.
* commander: send parachute command on termination
This sends the DO_PARACHUTE command to parachute component.
* commander: fix lying comments and printf
* commander: use one flag for termination triggered
This merges the duplicate flags _flight_termination_triggered and
_flight_flight_termination_printed.
* commander: correct variable name
* commander: always send tune with parachute
* commander: fix target_component for parachute cmd
The previous changes were wrong in that all commands were now sent to
the parachute component which doesn't make any sense. Of course only the
parachute command should be sent there.
- 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
- 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.
- use proper Mavlink MAV_CMD_FIXED_MAG_CAL_YAW command for initiating magnetometer quick cal
- MAV_CMD_FIXED_MAG_CAL_YAW allows specifying the yaw and optionally latitude and longitude if the vehicle doesn't have GPS
Allow enabling/disabling transmitting data from all mavlink instances
with a specific mode/type. When disabled the instance can still receive
data. The uORB message used is the vehicle_command and uses the following
parameter:
param1: Specifies the mode/type of the instances to enable/disable transmitting
param2: Boolean to indicate if transmitting should be enabled or disabled
The previous approach was checking system id and component id but it
will not work in 100% of cases as external devices can send MAVLink
message with the right system id but with broadcast component id.
Junwoo Hwang
Beat Küng
Hamish Willee
abarcis
Matthias Grob
RomanBapst
Julian Oes
Daniel Agar
Martina Rivizzigno
Igor Campos
FengShun
David Jablonski
Lorenz Meier
TSC21
acfloria
DonLakeFlyer
Nicolas de Palezieux
José Roberto de Souza
Mohammed Kabir
Don Gagne
David Sidrane