-
Notifications
You must be signed in to change notification settings - Fork 2
Configuration:Operator
WIP
The autonomy engine is the main point of in-mission interaction with the user.
For a detailed tutorial on each individual autonomy setting, please also refer to the module's README.
Within the CNS Flight Stack, missions are configured in environment specific .yaml
files (see src/flightstack/flighstack_bringup/configs/autonomy/
). Each configuration can include multiple mission descriptions, defining trajectories and sensor entities:
missions:
mission_1:
description: "Test" # provide any description here
filepaths: # provide the system file path
- "dh/test1.csv"
- "dh/test2.csv"
# - ... many more
# if you want to fly the same trajectory multiple times, put the same filename here multiple times
entities_actions:
- ["gnss_sensor", "land"] # watchdog entities
# - [..., ...] all other sensors to be used in this mission
The mission configuration is loaded inside the operator launchfile or through the terminal with
roslaunch flightstack_bringup fs_operator.launch config_filepath:=<PATH_TO_CONFIG_FILE> trajectory_dir:=<PATH_TO_TRAJECTORIES_FOLDER>
Please note that in the newest version the filepaths
are provided with respect to the trajectory_dir
provided in the launchfile. If you want to provide global paths launch the autonomy with trajectory_dir:=""
. In older versions, the filepaths
hat to be the global paths to the files. Also, if you are flying the same (or multiple) trajectory multiple times, provide them x times in the list under filepaths
. The parameter sequence_multiple_in_flight
determines then, if the UAV lands between each trajectory iteration: if true
it will not land in between.
The autonomy engine interacts with all other modules and oversees their status and results. However, in certain configurations or missions some functionality might be disabled. This can be done within the autonomy engine's launchfile and the following boolean flags exist:
-
activate_user_interface
: enables the terminal-based UI -
activate_watchdog
: enables the watchdog; see below for additional parameters -
activate_data_recording
: enables the data recording -
activate_landing_detection
: enables the landing detection -
perform_takeoff_check
: enables the flatness and distance to ground check before takeoff -
perform_estimator_check
: enables the estimator divergence check before takeoff -
estimator_init_service
: enables a service call to initialize an estimator just before takeoff (see example in MaRS). When enabled please setestimator_init_service_name
accordingly, service must be of typestd_srvs::SetBool
-
inflight_sensors_init_service
: enables service calls to other modules/sensors after successful takeoff; when enabled please set the listinflight_sensor_init_services_name
accordingly, services must be of typestd_srvs::Empty
-
hover_after_mission_completion
: deactivates automatic landing after reaching final waypoint from navigation list -
sequence_multiple_in_flight
: enables the sequencing of multiple waypoint files in-flight, rather than landing and taking off again
When the watchdog is enabled, the autonomy engine communicates the following configurations to it
-
watchdog_rate_Hz
: check rate of the watchdog, decrease this value if you see performance issues -
watchdog_startup_time_s
: time to allow the watchdog to observe entities without reporting issues (sometimes entities, e.g., drivers, take time to reach their desired rate after launching) -
watchdog_heartbeat_timeout_multiplier
: sets the upper boundary for the time between two consecutive watchdog status reports, i.e.max_time = 1.0/watchdog_rate_Hz * watchdog_heartbeat_timeout_multiplier
-
fix_timeout_ms
: when the watchdog is asked to fix an issue, this value provides the maximum time allowed until fix and correct functionality must be reported, otherwise a safety landing is initiated
-
maximum_flight_time_min
: determines the maximum time a mission can last; use this to additionally avoid battery drainage