-
Notifications
You must be signed in to change notification settings - Fork 13.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce AutoManeuverSystem for BVLOS applications #11169
Conversation
Awesome! One thing that's become a little unclear is the line between navigator states and flight tasks. |
float ___lat_float; /**< padding */ | ||
float ___lon_float; /**< padding */ | ||
}; | ||
struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to dig into AMS a bit more, but you likely don't need to extend mission_item_s
like this unless you're checking for velocity setup acceptance (MissionBlock::is_mission_item_reached()
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How should I do then? I wanted to add vx, vy and vz fields without increasing the size of mission_item_s. That's why I selected three floats I don't need for the velocity waypoint to put them in the same union.
I had to do the same with the orbit although I didn't like to do it. I think we need to make creating new behaviors e.g. modes more accessible in general. Currently it's obviously not enough to create a new task because with the current architecture you also need a new main state, navigation mode, px4 custom mode, ... and fill all the overfilled commander methods with another copy of all the possible flags just to make use of your task. |
@dagar In that case, I think the line is quite clear: the navigator logic provides the desired position/velocity waypoints and the Auto FlightTask executes it as regular waypoints. It's like for RTL, the FlightTask doesn't know and should not know that we are performing an AMS/RTL. |
…to split the desired down velocity and the maximum down velocity reachable by the multicopter. MPC_Z_VEL_DN : Desired downward velocity; used to drive the drone during normal auto and manual position control modes (similar to MPC_XY_CRUISE on the XY axes) MPC_Z_VEL_MAX_DN : Maximum downward velocity (similar to MPC_XY_VEL_MAX on the XY axes)
…eing a multicopter
…y on failsafes to go down
@dagar I rebased it onto master |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Will work on that again once I have the "motion primitives" done. |
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions. |
@bresch Where is this standing? |
Still waiting for the motion primitives. I close this PR as the implementation will change completely |
Description
A basic requirement for BVLOS applications is to allow the drone to perform some emergency maneuvers to prevent collision with manned vehicles or to quickly land in case of low battery/engine failure while flying at high altitudes.
The proposed solution is a new navigator/commander mode, similar to RTL, called Auto Maneuver System (AMS) that can be triggered by the operator or by a companion computer sensing the surrounding environment.
The ways to engage the AMS are:
Depending on the type of maneuver pre-configured by
AMS_TYPE
, the drone will perform an emergency descent at aAMS_DESCEND_VEL
speed untilAMS_DESCEND_ALT
above home altitude (or above ground in a rangefinder is used) and then loiter there (AMS_TYPE
= 0) or land (AMS_TYPE
= 1).Design choices
Since this mode is most likely triggered at cruise speed, a xy velocity waypoint is created with the desired altitude under the drone. Using a velocity waypoint ensures smooth xy deceleration while descending.
In order to go down faster than
MPC_Z_VEL_MAX_DN
currently used to define the desired down velocity in addition to saturate the velocity controller, a new parameterMPC_Z_VEL_DN
has been introduced. The new meaning is then:MPC_Z_VEL_DN
defines the maximum desired down velocity in manual position control and auto modesMPC_Z_VEL_MAX_DN
defines the maximum down velocity that the drone can safely reach and is used to saturate the velocity controllerWith the constraints
MPC_Z_VEL_DN
< or =AMS_DESCEND_VEL
<MPC_Z_VEL_MAX_DN
AMS triggers
RC switch
Set
RC_MAP_AMS_SW
to the desired channel and adjustRC_AMS_TH
Dronecode SDK
See mavlink/MAVSDK#676
MAVLink message
MAV_CMD_DO_SET_MODE (https://mavlink.io/en/messages/common.html#MAV_CMD_DO_SET_MODE)
param1 (base_mode) = 1 (VEHICLE_MODE_FLAG_CUSTOM_MODE_ENABLED)
param2 (custom_main_mode) = 4 (PX4_CUSTOM_MAIN_MODE_AUTO)
param3 (custom_sub_mode) = 10 (PX4_CUSTOM_SUB_MODE_AUTO_AMS)
Shell
nsh>commander mode auto:ams