* rtl: remove unconditional transition to land after descent
This was a bug, as it renders the above code lines useless.
This would cause a undesired FW landing for VTOL vehicles if
RTL_LAND_DELAY is above 0.
* rtl: head to center after loiter in VTOL FW
To get the same behavior for RTL with and without loiter before land for
VTOL drones.
* rtl: always go to descend state after return
Previously, the state would change directly to land if in MR and
RTL_LAND_DELAY was 0.0, but we will still wish to descent to
RTL_DESCEND_ALT at descent speed, instead of using landing speeds.
* rtl: mark head to center state as part of vtol transition
The next step in the sequence is transition to MC. By setting
vtol_back_transition we ensure that the acceptance radius is adapted to
the expected transition distance.
Do the same as DO_REPOSITION wit only the altitude field populated
and MAV_DO_REPOSITION_FLAGS set, which means:
- switch to Loiter mode if not already in it
- set the current altitude to what is specified in the altitdue field,
keep current altitude setpoint otherwise
- keep current position setpoint
- fall back to current estimated position in case a position setpoint
is not finite
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Also applies to Loiters that are started due to the previous mode being over (Takeoff,
VTOL_Takeoff, Mission).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
MIS_LTRMIN_ALt was used to limit the go-to altitude of a LOITER_TO_ALT (not the exit altitude,
but the altitude that the vehicle went to to fly to WP), and during landing abort to climb to
at least this altitude. The min entry altitude of LOITER_TO_ALT I remove with this commit, while
for the min alt during abort I added the new parameter MIS_LND_ABRT_ALT.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
previously, the next position setpoint in the triplet was left unchanged during an abort, which meant that the abort loiter current point combined with land next point triggered the early landing config logic. this commit is only a hack to make things work temporarily.. this needs to be handled better.
Replace the existing check for the availability of a takeoff mission item with a combined
check for takeoff and landing item (or landing pattern). New param MIS_TKO_LAND_REQ
can be set to require only a takeoff, only a landing, both takeoff and landing, and
both or none. The latter is meant to be set if is e.g. deemed unsafe to start a flight
through a Takeoff WP without though defining a Landing - as then in case of a RTL the
vehicle doesn't follow a pre-defined path but instead only can do default RTL that especially
for FW and VTOL isn't always safe.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This was previously required to reset the flight speed after a VTOL transition,
but is now no longer required as the DO_CHANGE_SPEED commands are handles directly
in the controllers.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This fixes the issue where the init happended in the initializer list, at which point
the params were not yet initialized and thus resulted in random values for the init
values of _mission_item.loiter_radius and .acceptance_radius.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- this is a precaution to eliminate the possibility of getting stuck in
a loop trying to keep up with a high rate publication that could be
coming from a higher priority task
Also containst a mini refactor by removing the unnecessary function
get_default_altitude_acceptance_radius().
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
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.
Such that the loiter (orbit) status can be displayed on groundstation
and the WP is accepted once within loiter radius
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
If the current yaw setpoint is valid we should use it to make the transition in this direction.
For a VTOL_TAKEOFF the yaw_setpoint is used to specify the transition direction (the
vehicle is aligned towards it and then transition is started). The current yaw can be
a bit off (e.g. because MIS_YAW_ERR is large), and it is better to track the actual setpoint.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
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
Knut Hjorth