Software Architectures for Intelligent Robots
Designing the software architecture of an intelligent robot requires balancing competing demands: response speed (react to obstacles in milliseconds), deliberative quality (plan an optimal path to the goal), and adaptability (handle unexpected situations). Three canonical architectures capture the design space:
1. Deliberative (Sense-Plan-Act, SPA): The robot maintains a complete world model, plans an optimal action sequence, then executes. Planning can use search algorithms (A*, RRT), constraint satisfaction, or model-based optimisation. Strength: globally optimal decisions. Weakness: planning takes time; the world changes while the robot plans (the "frame problem"). Used in early AI robotics (SHAKEY, 1966) and modern task planning.
2. Reactive (Behaviour-Based): No internal world model. Behaviours map sensor inputs directly to motor outputs using simple rules. Response is nearly instantaneous. Strength: fast, robust, handles dynamic environments well. Weakness: cannot plan globally, may oscillate in symmetric environments, limited to reflex-like behaviours. Exemplified by Brooks' Subsumption Architecture and Braitenberg vehicles.
3. Hybrid (Three-Layer): The dominant architecture in modern robotics. Combines a reactive layer (low-latency safety and reflexive behaviours), a sequencing/executive layer (task execution, skill coordination), and a deliberative planning layer (global path planning, task planning). Used in the Mars rovers, autonomous vehicles, and ROS-based systems (Nav2 fits this model).
Deliberative vs Reactive Architecture
Deliberative (Sense-Plan-Act)
- Planning horizon: long-term, globally optimal over full mission
- World model: explicit, complete, continuously updated symbolic model
- Response speed: slow (milliseconds to seconds for planning)
- Robustness: brittle if world model becomes stale or inaccurate
- Scalability: computational cost grows with world complexity and action space
- Best for: structured environments, well-defined tasks, optimal route planning
- Examples: STRIPS planners, A* path planner, task and motion planning (TAMP)
Reactive / Behaviour-Based
- Planning horizon: none — purely reactive to current sensor readings
- World model: none — direct sensor-to-actuator mapping
- Response speed: very fast (microseconds to milliseconds)
- Robustness: highly robust — no model can become incorrect
- Scalability: scales well; add behaviours independently
- Best for: dynamic, unpredictable environments, safety-critical reflexes
- Examples: Brooks subsumption, potential fields, Braitenberg vehicles
Behaviour-Based Robotics and Modern Behaviour Trees
Brooks' Subsumption Architecture (1986) was a landmark in reactive robotics. The architecture consists of layers of augmented finite-state machines (AFSM), each implementing a behaviour. Layers are arranged in priority order: lower layers (avoid obstacles, maintain stability) have higher priority and can subsume (override or suppress) outputs from higher layers (wander, explore, seek goal). This creates emergent, seemingly intelligent behaviour from simple rules.
The subsumption architecture proved that useful robot behaviour did not require complex world models — a philosophical shift from AI of the era. The MIT COG and Herbert robots demonstrated convincingly reactive behaviour in unstructured environments.
Behaviour Trees (BT) are the modern successor, widely used in games (Halo, The Sims) and now robotics. A BT is a directed tree of control nodes (Sequence, Fallback/Selector, Parallel, Decorator) and leaf nodes (Action, Condition). Execution flows from the root: a Sequence succeeds only if all children succeed (logical AND); a Fallback succeeds if any child succeeds (logical OR); an Action calls an external function; a Condition checks a predicate.
BTs are used in Nav2 (the ROS 2 navigation stack) via BehaviorTree.CPP and bt_navigator. The navigation BT encodes: check if goal is valid → compute global path → follow path → recover if stuck → report result. The XML-defined BT can be swapped without recompiling, enabling mission-specific navigation behaviours.
Robot Software Architecture Comparison
| Architecture | Key Idea | Response Time | World Model | Examples |
|---|---|---|---|---|
| Deliberative (SPA) | Sense full world, plan optimal action, execute | Slow (100ms–s) | Explicit, complete | SHAKEY, STRIPS planners, TAMP |
| Reactive / Subsumption | Layered AFSMs, direct sensor-action mapping | Very fast (<10ms) | None | COG, Herbert, Roomba early versions |
| Hybrid 3-Layer | Reactive + executive + deliberative layers | Fast (reactive layer) | Partial (map + local) | Mars rovers, autonomous vehicles, Nav2 |
| Behaviour Tree | Hierarchical tree of conditions and actions | Fast to moderate | Implicit in conditions | Nav2 bt_navigator, MoveIt 2, game AI |
| BDI Agent | Beliefs, Desires, Intentions — plan from goals | Moderate | Explicit belief base | AgentSpeak, JADE, autonomous UAVs |
Integrating Machine Learning into Robot Software
Machine learning augments each layer of the robot software stack:
Perception: Convolutional neural networks replace hand-crafted feature extractors for object detection, semantic segmentation, and depth estimation. A camera driver node publishes raw images; a neural network inference node subscribes, runs forward passes (GPU-accelerated), and publishes structured detections on a separate topic.
State estimation: Learned odometry networks (e.g. DeepVO, LOAM variants) supplement wheel encoders and IMUs for more accurate pose tracking in challenging terrain or low-texture environments.
Planning: Learned cost functions, goal-conditioned policies (imitation learning), or model-based RL replace hand-tuned planners for tasks like dexterous manipulation, where analytical models are intractable.
Control: Neural controllers (learned inverse kinematics, learned PID gain schedulers, end-to-end control) replace classical controllers in domains with complex, nonlinear dynamics.
Integration pattern in ROS 2: ML models run inside standard ROS 2 nodes. The node loads a PyTorch or TensorFlow model at startup, subscribes to sensor topics (e.g. /camera/image_raw, /scan), runs batched inference, and publishes predictions (e.g. /detections, /cmd_vel). This decoupling allows independent ML model updates without changing the rest of the system architecture.