Skip to main content
Contents2 / 11 ▾
Chapter II

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.

2.1

Design a navigation stack from sensor input to actuator command.

rating — likely · whiteboard-style

A production robotics navigation stack divides responsibilities across 7 discrete real-time layers to maintain low control latency and deterministic failover:

Table 2.1 — Complete 7-Layer Autonomous Navigation Architecture
LayerComponentUpdate RateInput / Output Data
1. Hardware DriversLiDAR / Stereo RealSense / IMU / Encoders$30\text{Hz} - 1\text{kHz}$Raw SPI/USB/Ethernet packets $\rightarrow$ DMA buffers
2. State EstimationArduPilot 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 & CostmapVoxel Grid Layer / Spatio-Temporal Costmap$20\text{Hz}$Pointclouds $\rightarrow$ 2.5D Occupancy Grid ($C(x,y) \in [0, 255]$)
4. Global PlannerHybrid A* on $SE(2)$ / Kinematic RRT*$1 - 2\text{Hz}$ / EventCostmap + Goal $\rightarrow$ Global Path Waypoints ($\mathbf{x}_{1:N}$)
5. Local PlannerDynamic Window Approach (DWA) / TEB Planner$20 - 50\text{Hz}$Global Path + Live Obstacles $\rightarrow$ Velocity Command $(v, \omega)$
6. Feedback ControllerModel Predictive Control (MPC) / Cascade PID$100\text{Hz}$$(v, \omega)$ + State $\rightarrow$ Actuator Wrench / Motor Speeds
7. Motor InterfaceCAN 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.

2.2

Architect a "return to origin if GPS is disrupted" system, as a whiteboard design prompt.

rating — likely

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;
    }
};
2.3

Global vs. local planners — what's the difference, and when do you re-plan?

rating — possible

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):

$$f(n) = g(n) + h(n), \quad h(n) = \max\left( h_{\text{Reed-Shepp}}(n), h_{\text{2D-A*}}(n) \right)$$

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)$:

$$G(v, \omega) = \alpha \cdot \text{heading}(v, \omega) + \beta \cdot \text{dist}(v, \omega) + \gamma \cdot \text{velocity}(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}$.
2.4

Explain ROS's costmap/nav2 concept and how you'd translate it into ga-msg.

rating — possible

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);
2.5

What is a costmap inflation layer, and why does it matter?

rating — possible

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:

$$\text{Cost}(d) = \begin{cases} 254 (\text{LETHAL}), & \text{if } d \le r_{\text{inscribed}} \\ (C_{\text{inscribed}} - 1) \cdot e^{-\alpha \cdot (d - r_{\text{inscribed}})}, & \text{if } r_{\text{inscribed}} < d \le r_{\text{inflation}} \\ 0, & \text{if } d > r_{\text{inflation}} \end{cases}$$

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.