Navigation Architecture
Designing a real-world autonomy navigation stack from physical sensor drivers down to motor torque control requires modular layer boundary isolation, dynamic costmap representation, and mathematically sound trajectory planning algorithms.
Design a navigation stack from sensor input to actuator command.
A production robotics navigation stack divides responsibilities across 7 discrete real-time layers to maintain low control latency and deterministic failover:
| Layer | Component | Update Rate | Input / Output Data |
|---|---|---|---|
| 1. Hardware Drivers | LiDAR / Stereo RealSense / IMU / Encoders | $30\text{Hz} - 1\text{kHz}$ | Raw SPI/USB/Ethernet packets $\rightarrow$ DMA buffers |
| 2. State Estimation | ArduPilot EKF3 / ESKF / ORB-SLAM3 | $100\text{Hz} - 1\text{kHz}$ | Sensors $\rightarrow$ 6-DOF Pose $\mathbf{T}_{w,b} \in SE(3) + \mathbf{v}, \mathbf{\omega}$ |
| 3. Mapping & Costmap | Voxel Grid Layer / Spatio-Temporal Costmap | $20\text{Hz}$ | Pointclouds $\rightarrow$ 2.5D Occupancy Grid ($C(x,y) \in [0, 255]$) |
| 4. Global Planner | Hybrid A* on $SE(2)$ / Kinematic RRT* | $1 - 2\text{Hz}$ / Event | Costmap + Goal $\rightarrow$ Global Path Waypoints ($\mathbf{x}_{1:N}$) |
| 5. Local Planner | Dynamic Window Approach (DWA) / TEB Planner | $20 - 50\text{Hz}$ | Global Path + Live Obstacles $\rightarrow$ Velocity Command $(v, \omega)$ |
| 6. Feedback Controller | Model Predictive Control (MPC) / Cascade PID | $100\text{Hz}$ | $(v, \omega)$ + State $\rightarrow$ Actuator Wrench / Motor Speeds |
| 7. Motor Interface | CAN bus / EtherCAT Master Driver | $200\text{Hz} - 200\text{kHz}$ | Motor Speeds $\rightarrow$ PWM / CAN-FD Frames / EtherCAT Datagrams |
Layer Boundary Control Flow & Shared Memory Isolation
To achieve sub-$10\text{ms}$ perception-to-actuation latency without ROS message copy overhead, perception and local planning modules communicate via POSIX Shared Memory (`shm_open` + `mmap`) lock-free ring buffers, with synchronization signaled by low-latency eventfd semaphores.
Architect a "return to origin if GPS is disrupted" system, as a whiteboard design prompt.
When presenting a whiteboard architecture for emergency return under GPS disruption, structure the design into Perception Degradation Detection, Graph-Based Trajectory Inversion, and Deterministic Failover Execution.
1. Detection & Trigger Logic
GPS degradation is flagged when GPS horizontal dilution of precision $HDOP > 2.5$, satellite count $N_{sat} < 6$, or EKF position innovation variance exceeds $3\sigma$ threshold for $>500\text{ms}$.
2. Whiteboard Module Breakdown
class EmergencyReturnSystem {
public:
void onGpsLoss() {
// Step 1: Lock current dead-reckoning origin frame
Eigen::Matrix4d T_fail = local_ekf_.getPose();
// Step 2: Extract last N valid keyframes from ring buffer
auto path = pose_graph_.getBacktrackPath(50 /* max keyframes */);
// Step 3: Instantiate local dynamic obstacle avoidance planner
dwa_planner_.setTargetTrajectory(path);
// Step 4: Execute reverse flight state machine
state_ = SystemState::RETRACTING_ALONG_GRAPH;
}
};
Global vs. local planners — what's the difference, and when do you re-plan?
Global and local planners operate on fundamentally different mathematical abstractions, search spaces, and time horizons.
1. Global Planner: Hybrid A* on $SE(2)$
Finds a globally optimal path from start to goal over the complete known map. Standard A* treats the robot as a point on a discrete 2D grid. Hybrid A* searches continuous 3D state space $(x, y, \theta)$, enforcing non-holonomic kinematic constraints (minimum turning radius $R_{\min}$ via Dubins/Reeds-Shepp curves):
2. Local Planner: Dynamic Window Approach (DWA)
Operates in velocity space $(v, \omega)$ at $20\text{Hz}$ within a rolling sensor window. Computes admissible velocity search space $V_r = V_s \cap V_a \cap V_d$ (where $V_s$ is maximum hardware velocity, $V_a$ is braking distance velocity limit, $V_d$ is acceleration limits). Evaluates candidate trajectories over horizon $\tau$ by maximizing objective function $G(v, \omega)$:
3. Re-planning Triggers
- Local Planner: Re-calculates velocity commands $(v, \omega)$ every control loop iteration ($20\text{Hz}-50\text{Hz}$) regardless of map changes.
- Global Planner: Re-plans asynchronously when: (a) a new obstacle intersects the current global path within distance $D_{\text{check}}$, (b) goal pose moves, or (c) local planner reports progress stall for $T_{\text{stall}} > 3.0\text{s}$.
Explain ROS's costmap/nav2 concept and how you'd translate it into ga-msg.
ROS Nav2 Costmap2D represents environment cost by stacking discrete functional layers: Static Layer, Obstacle Layer, Inflation Layer, and Range Sensor Layer. Each layer writes integer cost values $[0, 255]$ into a shared grid.
Translating Nav2 Costmap into ga-msg Architecture
ROS 2 Costmap2D suffers from dynamic memory allocations and serialization latency over DDS when sending full costmap grids. In our custom ga-msg framework, costmaps are implemented via zero-copy POSIX shared memory ring buffers:
// ga-msg Shared Memory Costmap Representation
struct SharedCostmapGrid {
uint32_t width;
uint32_t height;
double resolution;
double origin_x;
double origin_y;
uint8_t cells[1024 * 1024]; // 1MB zero-copy flat array
};
// Readers (Local Planner) and Writers (Perception) map memory directly:
int shm_fd = shm_open("/ga_costmap_shm", O_RDWR, 0666);
SharedCostmapGrid* costmap = (SharedCostmapGrid*)mmap(NULL, sizeof(SharedCostmapGrid), PROT_READ | PROT_WRITE, MAP_SHARED, shm_fd, 0);
What is a costmap inflation layer, and why does it matter?
The inflation layer inflates obstacle boundaries by propagating costs outward from obstacle cells to ensure the planner accounts for the robot's physical footprint while treating the robot center as a point mass.
Mathematical Inflation Decay Function
For any cell at Euclidean distance $d$ from the nearest obstacle cell:
where $r_{\text{inscribed}}$ is the radius of the robot's inscribed circle, $r_{\text{inflation}}$ is the maximum inflation radius, and $\alpha$ is the cost decay factor. Without inflation, global path planners route waypoints directly along obstacle edges, causing physical chassis collisions when turning.