Robot¶
The robot autonomy stack is the core of AirStack, providing layered autonomy from hardware interface through perception, planning, control, and high-level behavior.
Directory Structure¶
The robot autonomy stack is organized under robot/:
robot/
├── docker/ # Robot containerization
│ ├── docker-compose.yaml # Main launch configuration (see Launch Structure)
│ ├── robot-base-docker-compose.yaml # Shared base service
│ ├── Dockerfile.robot # Image definition
│ ├── .bashrc # Shell configuration (mounted into containers)
│ ├── robot_name_map/ # Robot identity mapping configs
│ │ └── default_robot_name_map.yaml
│ └── zed/ # ZED camera Docker files
│ ├── Dockerfile.zed-l4t
│ └── ws/
├── ros_ws/ # ROS 2 workspace
│ └── src/ # Source packages (layered architecture)
│ ├── autonomy_bringup/ # Top-level launch orchestration
│ ├── common/ # Shared packages & utilities
│ ├── interface/ # Hardware interface & safety
│ │ ├── interface_bringup/
│ │ ├── mavros_interface/
│ │ └── robot_interface/
│ ├── sensors/ # Sensor integration
│ │ └── lidar_point_cloud_filter/
│ ├── perception/ # State estimation & perception
│ │ └── perception_bringup/
│ ├── local/ # Local planning, control, world models
│ │ ├── planners/
│ │ ├── controls/
│ │ └── world_models/
│ ├── global/ # Global planning & mapping
│ │ ├── global_bringup/
│ │ ├── planners/
│ │ └── world_models/
│ ├── behavior/ # High-level decision making
│ │ └── drone_safety_monitor/
│ └── modules/ # Synced external modules
└── bags/ # ROS 2 bag recordings
Launch Structure¶
The robot autonomy stack is launched via Docker Compose. The configuration is in robot/docker/docker-compose.yaml.
Multi-Profile Architecture¶
- Base service:
robot-base-docker-compose.yamldefines shared configuration for all platforms - Platform profiles: Different services for desktop/Jetson/VOXL/testing (see Docker Services)
- Layered bringup: ROS 2 launch files organized hierarchically
Launch Command Hierarchy¶
The Docker command: attribute launches the top-level ROS 2 launch file,
which runs a shared preamble and then the selected stack entry file —
the stack is the only dispatch mechanism (see
Stacks):
robot.launch.xml # Entry point (autonomy_bringup):
├── (preamble: namespace, use_sim_time, robot_state_publisher, world→map TF)
└── stacks/<name>/launch/<entry>.launch.xml # The stack entry file —
├── interface.launch.py # a flat list of module
├── lidar_point_cloud_filter.launch.xml # includes; every connection
├── stereo_image_proc.launch.xml # is written down here
├── ... (local, global, behavior modules)
└── interpolate_dds_router / gossip
No stack selected = stacks/full_default. Each module package ships its own
canonical launch file; the stack entry file is the single wiring locus.
Quick Reference¶
# Start robot container (desktop development)
airstack up robot-desktop
# Start without auto-launch (for development)
airstack up robot-desktop --no-autolaunch
# Multiple robots
airstack up robot-desktop --robots 3
# Different platforms (profiles)
airstack up --profile l4t # NVIDIA Jetson
airstack up --profile voxl # ModalAI VOXL
Learn more:
- Docker Services - Detailed Docker configuration
- Autonomy Modules - Layer-by-layer breakdown
- System Architecture - Data flow diagrams
Common Topics¶
The canonical topic/service/action names, message types, and QoS profiles for every interchange point live in the versioned Interface Conventions Specification. A few examples (types per the spec):
| Topic (example) | Type | Description |
|---|---|---|
/$ROBOT_NAME/odometry_conversion/odometry |
nav_msgs/msg/Odometry | Primary state estimate |
/$ROBOT_NAME/global_plan |
nav_msgs/msg/Path | Global waypoint path |
/$ROBOT_NAME/trajectory_controller/trajectory_override |
airstack_msgs/msg/TrajectoryXYZVYaw | Direct trajectory commands |
See also:
- Interface Conventions Specification - The full topic/service/action reference
- System Architecture - Complete data flow diagrams
- Integration Checklist - Step-by-step module integration
Next Steps¶
- Autonomy Modules - Understand the layered architecture
- System Architecture - See how components interact
- Integration Checklist - Add new modules
- Docker Services - Configure deployment platforms