Semantics Manager

Repository for shared configuration files for handing semantic maps, as well as a library for loading these configuration files.

Top level config

In general, you should load a top-level config file in the config folder. This file has two paths: classes and map which point at the class and map configuration files respectively, relative to the top-level file.

Class config

The class config contains a list of classes, with each class having a list of parameters as follows:

• name: Self-explanatory
• color: An array of the form [R, G, B] giving the color of the class
• loc_weight: The relative weight on this class in the semantic localizer
• exclusive: Only one class with True here is allowed to occupy a given cell
• traversability_diff: The rank order of traversability difficulty. Higher is harder
• localization_class: Mapping from classes to localization. Can use to, for instance, treat cars as road for localization purposes. If set to -1, will completely ignore this class for localization purposes.

Even if not all parameters are necessary, they must be provided (even if, for instance, you are only using the crossview localizer but not the global traversability planner).

Map config

Similarly, the map config defines the map-related information.

• dynamic: If set to True, will expect dynamic maps to arrive via ROS topics, not loaded from file
• resolution: The map resolution in px/m. Note that all following images should be this same resolution.
• raster: Only needed if dynamic is False. Should point to a raster image with colors indicating classes as specified by the class config.
• svg: Optional. Can either point to a map svg or a folder of class rasters as generated by the localizer. If not provided, will use the raster image.
• viz: Optional. Used for visualization purposes. If not provided, will use raster image.
• gps_origin_lat, gps_origin_long: Optional. Specify the GPS coordinates of the map origin.

Node configs

Launch files for the ground and aerial stacks are available in the launch directory. This is done in order to centralize configuration as much as possible. In general, users should avoid modifying the default configs in the relevant packages, but should instead override them here. We therefore avoid having config fragmentation across a bunch of repos.