Project 4

Swarm

Sponsors

Coordinate up to three MONA bots using the shared arena camera for localisation to push a trolley across the arena quickly while avoiding obstacles and keeping the run controlled.

Overview

Teams are expected to use the shared arena camera as the localisation view for this project, with a laptop plugged into that feed while they are on the arena. At the start of the event, each team will receive 1 MONA bot for setup, testing, learning, and agreeing a shared fiducial marker standard with the other teams before organisers transition to 3 shared sets of 3 MONA bots. A maximum of 3 MONA bots may be used for a run.

The goal is to autonomously push a trolley from one side of the arena to the other while avoiding obstacles. Faster successful runs will rank more highly.

Objectives

Teams must build a system that:

1. Coordinates the provided MONA bots using the shared arena camera for localisation while moving the trolley across the arena.
2. Detects and avoids obstacles throughout the run.
3. Completes the crossing as quickly and reliably as possible.

Quickstart

1. Start with one MONA and a minimal command loop before you plan 3-bot behaviour.
2. Use the MONA library and example code linked in the resources section as your starting point.
3. Plan around supervisor-managed arena and camera access rather than assuming constant availability.
4. When you are on the arena, plug your laptop into the arena camera and use that live view both to position the MONAs and to run your camera-based tracking from the real camera angle.
5. Use the initial one-MONA period to agree a shared fiducial marker convention with the other teams before different mounts and sizes diverge.
6. Generate, print, and mount fiducial markers early rather than treating them as an optional late add-on.

MONA Access Plan

• We only have access to 10 MONA bots in total for the event.
• At the start of the event, each team will be handed 1 MONA bot for setup, testing, and learning the platform.
• Use that initial 1-MONA period to discuss a shared fiducial marker system with the other teams so the arena camera can localise every bot reliably.
• Once teams are ready, organisers will transition to 3 shared sets of 3 MONA bots.
• Teams will need to share time on those 3-bot sets during development and judged use.
• A maximum of 3 MONA bots may be used for a run.

Arena Rules

• Teams will share one arena during development and testing.
• Each team gets a minimum of 4 minutes on the arena before allowing another team to use it.
• Teams are responsible for organising arena time between themselves.
• Teams are expected to plug their laptop into the arena camera when they are on the arena and use that feed to position the MONAs and run their camera-based tracking.
• Supervisors will manage arena and camera access on the day, but teams still need to keep arena usage fair and practical.

Materials Provided

• Access to the staged MONA allocation described above
• Access to the arena and overhead camera as the shared localisation and tracking view while teams are on the arena
• Camera connection for teams to plug a laptop into the arena view while positioning MONAs and running their tracking pipeline
• 1 wireless access point shared between 2 teams, for local robot/laptop communication
• Access point setup will be kept minimal:
  • configured in standard AP mode
  • 2.4 GHz Wi-Fi for compatibility with the MONA ESP32 hardware
  • local DHCP enabled so laptops and robots can join the network without manual IP configuration
  • intended for local command/telemetry traffic only, not high-bandwidth video streaming
• MONA robot Arduino library and example code are linked in the resources section above
• Teams may use the linked MONA robot Arduino library and example code as a starting point for robot control and local wireless communication
• The Wi-Fi/socket examples in that linked codebase are a more suitable starting point for team robot coordination than browser-based control examples
• One 3D printer will be reserved for this project at the start of the event so teams can print fiducial cases and related mounts quickly

Arena Camera Setup

Teams should treat the arena camera as part of the control stack. When you are on the arena, plug your laptop into the camera and use that live image both to place the MONAs and to run the camera-based tracking that localises them from the real camera position.

This is why we strongly recommend putting fiducial markers on the bots. The shared camera view needs a consistent way to identify and position every MONA during setup and testing, and fiducial-based tracking has been the most practical shared standard in previous years.

Reference arena view. The camera is mounted above the arena facing downward and is visible on the right side of this image. Teams are expected to plug a laptop into that feed to position the MONAs and run their tracking loop from the real camera viewpoint.

Fiducial Markers

Teams should plan for printed fiducial markers and a marker mount from the start. The MONA bots do not ship with markers attached by default, so the mount needs to be part of the early build rather than a last-minute add-on.

At the start of the hackathon, each team gets 1 MONA to test with. Use that initial window to coordinate with the other teams and agree a shared fiducial marker system that everyone can use reliably from the shared arena camera. We recommend that someone generates the marker sheets early and prints them on the university computers before incompatible mount choices spread across teams.

In past years, teams have mounted these fiducials on 3D-printed cases fitted to the MONAs. Teams can design and add those cases this year if they want to build them, and we recommend designing around M3 screws with self-tapping holes for a simple, robust mount.

Teams can print fiducial markers on paper using the university printers, and if attaching them cleanly to the MONAs is difficult they can print mounts on a 3D printer at the start of the event instead, since glue must not be used directly on the MONAs.

Example of a shared fiducial standard mounted on 3D-printed cases across multiple MONAs.

Fit the fiducial mount early. Camera-based tracking depends on the marked configuration, not the bare robot.

Bare MONA platform reference. Each team starts here, so use the initial one-MONA period to move quickly to a marker-ready mount.

The MONA pool is shared and limited, so keep the fiducial case and mount quick to fit and compatible across the robots you are handed.

Common Failure Points

• designing for three bots before one bot is reliable
• treating the arena camera as a setup aid instead of the core localisation view
• leaving fiducial marker placement until the end of the build
• failing to agree a shared marker standard with the other teams during the initial one-MONA period
• assuming uninterrupted arena time during development
• delaying trolley interaction and obstacle recovery tests until judged runs

Scoring Criteria

Maximum score: 100 points

The project rewards competitive performance on the course, controlled obstacle handling, repeatable operation, and originality of approach.

Qualifying and Knockout Placement (50 points)

All teams will complete 3 qualifying runs. A team’s best valid qualifying run will be used to rank the field.

Completed crossings rank above non-finishers. Among teams that complete the course, the faster valid completion time ranks higher. Among teams that do not complete the course, the team that achieves the furthest valid trolley progress ranks higher.

The top 4 teams advance to the knockout stage. Semifinals will be seeded 1st vs 4th and 2nd vs 3rd, with semifinal winners advancing to the final and semifinal losers competing in a 3rd-place playoff. Teams placed 5th to 10th will receive placement points based on their qualifying rank.

Final Place	Points
1st	50
2nd	42
3rd	36
4th	30
5th	24
6th	20
7th	16
8th	12
9th	8
10th	4

Control and Obstacle Handling (25 points)

This category rewards controlled trolley movement, effective obstacle avoidance, stable corrections, and minimal disruption to obstacles. Minor contact is allowed, but repeated contact, poor recovery, or obvious course disruption will reduce the score. Judges may stop a run if the system becomes uncontrolled or unsafe.

Performance Level	Points
Clean, controlled navigation with little or no meaningful obstacle interference	21-25
Generally controlled operation with some avoidable contact or recovery corrections	14-20
Repeated contact, weak control, or inconsistent obstacle management	6-13
Severely uncontrolled or ineffective navigation	0-5

Repeatability (15 points)

Repeatability will be scored using the same 3 qualifying runs. A successful run is one that completes a valid crossing within the allowed judging window.

Successful Qualifying Runs	Points
3	15
2	10
1	5
0	0

Innovation (10 points)

The final 10 points will be awarded qualitatively for originality of approach. Judges may reward creative swarm strategies, novel robot coordination, interesting recovery methods, or inventive use of sensing and control.