msg/vehicle_constraints.msg

# Local setpoint constraints in NED frame
# setting something to NaN means that no limit is provided

uint64 timestamp # time since system start (microseconds)

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]
float32 min_distance_to_ground # in meters
float32 max_distance_to_ground # in meters
bool want_takeoff # tell the controller to initiate takeoff when idling (ignored during flight)
bool reset_integral # tells controller to reset integrators e.g. since we know the vehicle is not in air
float32 minimum_thrust # tell controller what the minimum collective output thrust should be

uint32 flight_task
msg: first draft of vehicle_constraints message 2018-04-25 17:28:02 +02:00			`# 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. 2019-05-13 21:07:05 +02:00			`uint64 timestamp # time since system start (microseconds)`
add timestamp field to uORB msgs; sync timestamp whenever possible 2018-08-07 01:30:05 +01:00
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. 2019-05-13 21:07:05 +02:00			`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 2018-05-24 17:58:02 +02:00			`float32 min_distance_to_ground # in meters`
FlightTaskManualAltitude: respect maximum altitude if there is a valid distance sensor 2018-06-25 10:00:08 +02:00			`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. 2019-05-13 21:07:05 +02:00			`bool want_takeoff # tell the controller to initiate takeoff when idling (ignored during flight)`
FlightModeManager: fix integral reset on ground This information could also be used for yaw and integral resets of the lower level controllers. 2020-10-24 17:27:07 +02:00			`bool reset_integral # tells controller to reset integrators e.g. since we know the vehicle is not in air`
FlightModeManager: fix takeoff ramp from zero 2020-10-24 13:15:00 +02:00			`float32 minimum_thrust # tell controller what the minimum collective output thrust should be`
Temporary logging addition to debug CI 2020-10-25 10:04:28 +01:00
			`uint32 flight_task`