forked from Archive/PX4-Autopilot
2542b1bb26
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 |
||
|---|---|---|
| .ci | ||
| .clusterfuzzlite | ||
| .devcontainer | ||
| .github | ||
| .vscode | ||
| Documentation | ||
| ROMFS | ||
| Tools | ||
| boards | ||
| cmake | ||
| integrationtests/python_src/px4_it | ||
| launch | ||
| msg | ||
| platforms | ||
| posix-configs | ||
| src | ||
| test | ||
| test_data | ||
| validation | ||
| .ackrc | ||
| .clang-tidy | ||
| .gitattributes | ||
| .github_changelog_generator | ||
| .gitignore | ||
| .gitmodules | ||
| .travis.yml | ||
| .ycm_extra_conf.py | ||
| CMakeLists.txt | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| CTestConfig.cmake | ||
| Firmware.sublime-project | ||
| Jenkinsfile | ||
| Kconfig | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| appveyor.yml | ||
| eclipse.cproject | ||
| eclipse.project | ||
| package.xml | ||
README.md
PX4 Drone Autopilot
This repository holds the PX4 flight control solution for drones, with the main applications located in the src/modules directory. It also contains the PX4 Drone Middleware Platform, which provides drivers and middleware to run drones.
PX4 is highly portable, OS-independent and supports Linux, NuttX and MacOS out of the box.
- Official Website: http://px4.io (License: BSD 3-clause, LICENSE)
- Supported airframes (portfolio):
- Multicopters
- Fixed wing
- VTOL
- Autogyro
- Rover
- many more experimental types (Blimps, Boats, Submarines, High altitude balloons, etc)
- Releases: Downloads
Building a PX4 based drone, rover, boat or robot
The PX4 User Guide explains how to assemble supported vehicles and fly drones with PX4. See the forum and chat if you need help!
Changing code and contributing
This Developer Guide is for software developers who want to modify the flight stack and middleware (e.g. to add new flight modes), hardware integrators who want to support new flight controller boards and peripherals, and anyone who wants to get PX4 working on a new (unsupported) airframe/vehicle.
Developers should read the Guide for Contributions. See the forum and chat if you need help!
Weekly Dev Call
The PX4 Dev Team syncs up on a weekly dev call.
Note The dev call is open to all interested developers (not just the core dev team). This is a great opportunity to meet the team and contribute to the ongoing development of the platform. It includes a QA session for newcomers. All regular calls are listed in the Dronecode calendar.
Maintenance Team
- Project: Founder
- Architecture
- Dev Call
- Communication Architecture
- UI in QGroundControl
- Multicopter Flight Control
- Multicopter Software Architecture
- VTOL Flight Control
- Fixed Wing Flight Control
- OS / NuttX
- Driver Architecture
- Commander Architecture
- UAVCAN
- State Estimation
- Vision based navigation and Obstacle Avoidance
- RTPS/ROS2 Interface
See also maintainers list (px4.io) and the contributors list (Github).
Supported Hardware
This repository contains code supporting Pixhawk standard boards (best supported, best tested, recommended choice) and proprietary boards.
Pixhawk Standard Boards
- FMUv6X and FMUv6U (STM32H7, 2021)
- Various vendors will provide FMUv6X and FMUv6U based designs Q3/2021
- FMUv5 and FMUv5X (STM32F7, 2019/20)
- FMUv4 (STM32F4, 2015)
- FMUv3 (STM32F4, 2014)
- FMUv2 (STM32F4, 2013)
Manufacturer and Community supported
- Holybro Durandal
- Hex Cube Orange
- Hex Cube Yellow
- Airmind MindPX V2.8
- Airmind MindRacer V1.2
- Bitcraze Crazyflie 2.0
- Omnibus F4 SD
- Holybro Kakute F7
- Raspberry PI with Navio 2
Additional information about supported hardware can be found in PX4 user Guide > Autopilot Hardware.
Project Roadmap
A high level project roadmap is available here.
Project Governance
The PX4 Autopilot project including all of its trademarks is hosted under Dronecode, part of the Linux Foundation.
