zrzk
/
px4_autopilot
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
31902 Commits
14 Branches
0 Tags
306 MiB
Tree: 9d124c2b1a
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '9d124c2b1a'
${ noResults }
px4_autopilot/msg/vehicle_constraints.msg

14 lines
512 B
Raw Normal View History Unescape

msg: first draft of vehicle_constraints message
7 years ago
# Local setpoint constraints in NED frame
# setting something to NaN means that no limit is provided
mc_pos_control/FlightTasks: trigger takeoff based on task The initial idea of the flight task architecture was that a task can freely set it's setpoints and doesn't have to worry about takeoff and landing. It would just takeoff when it's landed and there's a setpoint to go up and land when it puts a setpoint that pushes into the ground. With the takeoff logic there are some significant interface problems depending on the way a task is implemented: From the setpoint is not high enough to trigger to an unexpected takeoff because of some estimator fluctuation affecting the setpoint. It's easiest to solve this by allowing the task to determine when a takeoff is triggered. If no condition is implemented by default a task is not allowing a takeoff and cannot be used to get the vehicle off the ground.
6 years ago
uint64 timestamp # time since system start (microseconds)
add timestamp field to uORB msgs; sync timestamp whenever possible
7 years ago
mc_pos_control/FlightTasks: trigger takeoff based on task The initial idea of the flight task architecture was that a task can freely set it's setpoints and doesn't have to worry about takeoff and landing. It would just takeoff when it's landed and there's a setpoint to go up and land when it puts a setpoint that pushes into the ground. With the takeoff logic there are some significant interface problems depending on the way a task is implemented: From the setpoint is not high enough to trigger to an unexpected takeoff because of some estimator fluctuation affecting the setpoint. It's easiest to solve this by allowing the task to determine when a takeoff is triggered. If no condition is implemented by default a task is not allowing a takeoff and cannot be used to get the vehicle off the ground.
6 years ago
float32 yawspeed # in radians/sec
float32 speed_xy # in meters/sec
float32 speed_up # in meters/sec
float32 speed_down # in meters/sec
float32 tilt # in radians [0, PI]
vehicle constraints: minimum distance to ground. currently used when distance sensor is available
7 years ago
float32 min_distance_to_ground # in meters
FlightTaskManualAltitude: respect maximum altitude if there is a valid distance sensor
7 years ago
float32 max_distance_to_ground # in meters
mc_pos_control/FlightTasks: trigger takeoff based on task The initial idea of the flight task architecture was that a task can freely set it's setpoints and doesn't have to worry about takeoff and landing. It would just takeoff when it's landed and there's a setpoint to go up and land when it puts a setpoint that pushes into the ground. With the takeoff logic there are some significant interface problems depending on the way a task is implemented: From the setpoint is not high enough to trigger to an unexpected takeoff because of some estimator fluctuation affecting the setpoint. It's easiest to solve this by allowing the task to determine when a takeoff is triggered. If no condition is implemented by default a task is not allowing a takeoff and cannot be used to get the vehicle off the ground.
6 years ago
bool want_takeoff # tell the controller to initiate takeoff when idling (ignored during flight)