Skip to content

Configuration:Operator

Martin Scheiber edited this page Dec 7, 2022 · 3 revisions

Operator and Autonomy Configuration

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.

Mission Configuration

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.

Behavior and Module Configuration

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 set estimator_init_service_name accordingly, service must be of type std_srvs::SetBool
  • inflight_sensors_init_service: enables service calls to other modules/sensors after successful takeoff; when enabled please set the list inflight_sensor_init_services_name accordingly, services must be of type std_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
Watchdog Settings

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
Other Settings
  • maximum_flight_time_min: determines the maximum time a mission can last; use this to additionally avoid battery drainage