Topic 1: Foundations of Multi-Agent Robotics

Topic 1 introduces the core ideas behind multi-agent robotics—systems where multiple robots act together as a coordinated whole rather than as isolated individuals. You will learn how team-level objectives, communication, and coordination reshape the design of autonomy compared to single-robot systems from Chapter 5.

1.1 Single-Agent vs Multi-Agent Systems

In earlier chapters, you focused on building a single autonomous robot that can perceive, plan, and act. In multi-agent settings:

• Multiple robots operate in the same or overlapping environments
• They may share goals, resources, and constraints
• Their decisions and actions interact and can help or hinder each other

Key contrasts:

• Individual vs collective objectives
  • Single-agent: Optimize for one robot’s performance (e.g., shortest path, minimal energy).
  • Multi-agent: Optimize for team performance (e.g., total mission time, coverage, fairness).
• Local vs shared state
  • Single-agent: World model is primarily local to that robot.
  • Multi-agent: World models often need to be partially or fully shared.
• Isolated vs coupled actions
  • Single-agent: Actions mostly affect the robot’s own trajectory.
  • Multi-agent: Actions can create congestion, conflicts, or opportunities (e.g., blocking a doorway vs clearing a path).

The central design question becomes: How do many autonomous robots coordinate to achieve a shared mission safely and efficiently?

1.2 Cooperation, Competition, and Mixed-Motive Scenarios

Multi-agent systems can be:

• Cooperative
  • All robots share a common goal (e.g., maximize warehouse throughput, fully explore a building).
  • Reward structures are aligned: one robot’s success contributes to team success.
• Competitive
  • Robots (or their operators) have opposed goals (e.g., adversarial drones, competitive games).
  • Actions are chosen not just to succeed, but also to limit or outmaneuver others.
• Mixed-motive
  • Robots share some goals but may have individual constraints or sub-goals (e.g., battery limits, priorities, safety regions).

In this course, you will primarily focus on cooperative and mixed-motive fleets where robots work together toward a mission (e.g., logistics, inspection, search-and-rescue), but must negotiate constraints and workloads.

1.3 Collaboration Models and Architectures

Multi-agent systems can be structured in several ways:

• Centralized coordination
  • A central server or “fleet manager” holds the global world model, assigns tasks, and monitors all robots.
  • Pros: Global visibility, easier to optimize for global objectives.
  • Cons: Single point of failure, scalability and bandwidth limits, vulnerability to network issues.
• Decentralized / peer-to-peer
  • Each robot runs its own autonomy stack and shares information directly with peers.
  • Pros: No single failure point, more robust to partial connectivity, scalable.
  • Cons: Harder to guarantee global optimality, more complex consensus and conflict-resolution.
• Hybrid architectures
  • Combine centralized services (e.g., mission planner, high-level map server) with locally autonomous robots that handle perception, control, and safety on-board.
  • Often the most practical approach for real fleets: centralized where it helps, decentralized where it must be.

Later topics in this chapter will show how ROS 2, DDS, and higher-level APIs can support each of these models.

1.4 Communication as a First-Class Design Element

Single-robot systems can often treat networking as an implementation detail. In multi-agent systems, communication is central:

• Robots rely on timely messages to:
  • Share map updates and detections
  • Request help or hand off tasks
  • Announce status (battery, health, current workload)
• Communication channels are constrained by:
  • Latency (how quickly data arrives)
  • Bandwidth (how much data can be sent)
  • Reliability (packet loss, disconnections, interference)

Concepts from communication theory matter:

• Latency vs reliability trade-offs
  • High-frequency sensor data (e.g., LiDAR scans) may use best-effort delivery.
  • Mission-critical commands (e.g., stop, emergency halt) require reliable delivery.
• Topology
  • Star (central server with many robots), mesh (robots talk to each other), or hierarchical combinations.
• Robustness
  • Systems must tolerate dropped packets, delayed data, and temporary partitions.

ROS 2’s DDS-based transport provides many of the knobs (QoS profiles) you will use to manage these trade-offs.

1.5 Scalability and Complexity in Fleets

Adding more robots is not just duplication:

• State space explosion
  • With each additional robot, the combined system’s state grows combinatorially.
• Coordination overhead
  • More robots means more potential conflicts (collisions, deadlocks, communication saturation).
• Global constraints
  • Limited shared resources (e.g., charging stations, narrow aisles, elevators) must be scheduled fairly.

Design patterns for scalability include:

• Spatial partitioning
  • Assign robots to regions and minimize cross-region interference.
• Hierarchical control
  • Use local controllers for fast reactions and higher-level planners for global allocation.
• Policy reuse
  • Share behavior policies across similar robots, but parameterize them by role or context.

Throughout Chapter 6, you will see how these patterns appear in multi-robot SLAM, task allocation, and swarm behaviors.

1.6 From Single-Agent Autonomy to Multi-Agent Teams

Your existing autonomy stack (from Chapter 5) becomes the building block of a fleet:

• Each robot still:
  • Perceives its environment
  • Maintains local state
  • Plans and executes motion safely
• Multi-agent layers add:
  • Shared mapping and perception
  • Fleet-level task allocation and role assignment
  • Inter-robot messaging and dialogue
  • Fleet-wide orchestration, often powered by an LLM-based Commander

You can think of this progression:

Single robot → Autonomous agent → Team of agents → Fleet-level system

The rest of Chapter 6 builds this stack step by step, starting with shared maps and world models, then adding task allocation, fleet networking, swarm behaviors, and finally LLM-orchestrated multi-agent autonomy.