Skip to content
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

Closed
wants to merge 11 commits into from
Closed

Conversation

bresch
Copy link
Member

@bresch bresch commented Jan 8, 2019

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:

  • RC switch
  • MAVLink command mode change

Depending on the type of maneuver pre-configured by AMS_TYPE, the drone will perform an emergency descent at a AMS_DESCEND_VEL speed until AMS_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 parameter MPC_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 modes
  • MPC_Z_VEL_MAX_DN defines the maximum down velocity that the drone can safely reach and is used to saturate the velocity controller
    With 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 adjust RC_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

@dagar
Copy link
Member

dagar commented Jan 8, 2019

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 {
Copy link
Member

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()).

Copy link
Member Author

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.

@MaEtUgR
Copy link
Member

MaEtUgR commented Jan 17, 2019

is a new navigator/commander mode

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.

@bresch
Copy link
Member Author

bresch commented Feb 19, 2019

One thing that's become a little unclear is the line between navigator states and flight tasks.

@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.
In my opinion, the FlightTasks should not handle too much high level logic; we don't want it to become a new Commander/Navigator...

@davids5
Copy link
Member

davids5 commented Feb 20, 2019

devcall AI:@bresch will rebase @dagar to review

…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)
@bresch
Copy link
Member Author

bresch commented Feb 25, 2019

@dagar I rebased it onto master

@thomasgubler
Copy link
Contributor

@bresch could you rebase?

@bkueng could you do the review and merge (for post 1.9)

@stale
Copy link

stale bot commented Sep 29, 2019

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.

@bresch
Copy link
Member Author

bresch commented Sep 29, 2019

Will work on that again once I have the "motion primitives" done.

@stale
Copy link

stale bot commented Jan 16, 2020

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

@stale stale bot added the stale label Jan 16, 2020
@LorenzMeier
Copy link
Member

@bresch Where is this standing?

@stale stale bot removed the stale label Mar 8, 2020
@bresch
Copy link
Member Author

bresch commented Mar 10, 2020

Still waiting for the motion primitives. I close this PR as the implementation will change completely

@bresch bresch closed this Mar 10, 2020
@LorenzMeier LorenzMeier deleted the dev-ams branch January 18, 2021 14:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants