Teams at the University of York's Institute for Safe Autonomy spent 25 to 27 August building robots on a Raspberry Pi Pico W platform and programming them to navigate mazes. The micromaze robot hackathon brought together members of UK RAS STEPS for three days of design, construction and software work.
The task was set out plainly. Participants worked in teams to design, build and program autonomous robots that could move through a series of mazes. The mazes became more complex as the event went on, so a robot that handled an early layout still had to cope with harder ones later.
The platform and the tools
Every team started from the same base: a custom robotics platform built around the Raspberry Pi Pico W. From there, each team designed its own laser-cut chassis. The chassis had to carry the motors and sensors the team chose to integrate, so mechanical decisions and electronics decisions were tied together from the start.
Control software was written in MicroPython. That put the programming work on the same microcontroller-class hardware the robots ran on, rather than on a separate computer.
The sensor options were ultrasonic, infrared and time-of-flight. Each measures distance or proximity in a different way, and teams had to decide which to fit and how to use the readings to steer. Laser-cutting and 3D-printing facilities were available, which allowed teams to revise physical parts during the event rather than working to a fixed design.
How the final challenge was judged
The final challenge did not rest on a single measure. Judging considered maze performance, collision avoidance, robot design, code quality, wireless control and any innovative features the teams developed.
That list rewards more than speed through a maze. A robot that completed the course but hit the walls would lose ground on collision avoidance. A robot with sound hardware but poorly structured code would lose ground on code quality. Including wireless control meant teams also had to think about how a person communicates with the machine, not only how the machine behaves on its own.
The programme around the challenge included a tour of the Institute for Safe Autonomy, collaborative development sessions, final presentations and robot demonstrations. The presentations and demonstrations gave teams a point at which to explain their design choices as well as show the robots running.
A format being tested for wider use
The hackathon also served a second purpose. It helped test an activity that could be developed into future continuing professional development for people new to robotics, or into an outreach programme for children and students.
The event was credited to Rob Woolley and the University of York team, with thanks given to everyone who took part and contributed.
Analysis: what the event does and does not show
The most useful feature of this event is its structure. A shared hardware platform removes the cost and delay of sourcing parts, and it means every team begins from the same starting point. The differences between results then come from design and programming choices. That makes a fair basis for comparison, and it suits a mixed group in which some participants are more experienced than others.
The choice of MicroPython and a Pico W board also fits the stated aim of reaching newcomers. The source does not give participant numbers, team counts or results, so it is not possible to say how well beginners fared. The design does point in a sensible direction, though. The tools run on low-cost, widely used hardware, and the work covers mechanical design, sensing, control and wireless communication within one project. That combination gives a newcomer a full view of how a small autonomous robot comes together.
Compared with a typical software-only coding event, a micromaze robot hackathon forces contact with physical error. A sensor that reads badly, a chassis that flexes or a motor that behaves unevenly shows up immediately in how the robot moves. Laser cutting and 3D printing on site let teams respond to those problems directly. The judging criteria reinforce this by weighing design and collision avoidance alongside code quality.
Several points remain unproven. The source describes the activity as something that could be developed into professional development or outreach, which means it has not yet become either. Nothing in it says how the format would be adapted for children, who would need different supervision and simpler tooling, or for working professionals, who would need a shorter and more structured course. It also gives no evidence on learning outcomes, such as whether participants gained skills they kept using afterwards.
The setting is another point to note. The event ran at an institute focused on safe autonomy, and collision avoidance was one of the judged criteria. The source does not claim a deliberate link between the two. Even so, a maze task in which touching the walls counts against a team is a small-scale way to introduce the idea that autonomous machines should be judged on how safely they move as well as on whether they reach a goal.
For now, the event is best read as a pilot. It shows that a three-day, hands-on build-and-program format can be run with a custom platform, common sensors and in-house fabrication. Whether it can be repeated at larger scale, or adapted for new audiences, will depend on follow-up work that the source does not describe.