Introducing the Micromouse Project
My journey into embedded systems started much like many others: blinking LEDs on an Arduino and gradually working through communication protocols, timers, and device drivers. Although I was able to build working projects, I eventually realized that learning individual peripherals wasn’t the same as understanding how they came together to form a complete embedded system.
Around that time, I joined the Rutgers Micromouse team. What initially looked like a small robotics competition quickly became a project that forced me to answer exactly that question. Each feature the robot required introduced another engineering problem, making Micromouse an ideal project for learning embedded engineering.
In this series, I'll document that journey one design challenge at a time. In this introductory post, I'll explain what Micromouse is, why it makes for an interesting embedded systems project, and the high-level roadmap for the series.
What is Micromouse?
Micromouse is an engineering competition in which a small autonomous robot must explore an unknown maze, locate its center, determine the shortest path, and then traverse that path as quickly as possible. Although the objective sounds simple, the robot must accomplish every part of the task without human intervention.
An example of a micromouse in a maze
The robot must sense its surroundings, control its own movement, estimate its position within the maze, and decide where to go next. Each of these capabilities introduces its own engineering challenges, and solving one often exposes the next. What begins as "build a robot that solves a maze" quickly becomes an exercise in system design.
Building a Micromouse
At a high level, the objective of a Micromouse is straightforward: build a robot that can navigate a maze autonomously. The challenge is that these problems don't exist independently. Every additional function introduces new design decisions and interactions with the rest of the system. Solving one problem naturally reveals the next, gradually transforming a simple idea into a cohesive design.
To illustrate what I mean, let's follow a single requirement through its first few engineering decisions.
Figure 1. A single engineering requirement naturally expands into multiple design decisions
Figure 1 illustrates this progression. Suppose we begin with a single requirement: the robot must detect a wall. That single requirement immediately raises several new engineering questions. What kind of sensor should we use? Once the sensor produces a measurement, how does that information reach the microcontroller? After receiving the data, how should the software interpret it? Finally, how does that information influence the robot's movement?
None of these questions exist in isolation. Answering one naturally creates another, and before long we've moved far beyond "detect a wall" into sensing, software, control, and system integration. Rather than trying to solve everything at once, this series will investigate those decisions as they arise, allowing the complete system to emerge gradually.
What this Series Will Explore
Every article in this series focuses on a single engineering question. We'll start with one requirement, dive into the decisions needed to satisfy it, and use those decisions in the hardware and software when necessary.
Some articles may focus on selecting hardware. Others may involve writing firmware, debugging unexpected behavior, or revisiting earlier design choices. As the robot becomes more capable, the technical constraints naturally become more sophisticated.
By the end of the series, I hope you'll not only have watched a Micromouse take shape, but also have a clearer understanding of the engineering decisions that turn individual hardware and software components into a functioning embedded system.
The Road Ahead
Building a Micromouse isn't something that happens all at once. We'll begin by giving the robot the ability to interact with the physical world before gradually adding the capabilities needed to solve the maze autonomously. As the robot becomes more capable, new constraints emerge, and each problem builds naturally on the last.
Figure 2. High-level roadmap for building the Micromouse throughout this series.
The sequence in Figure 2 isn't arbitrary. Before a robot can solve a maze, it first needs to move reliably. Before it can make intelligent decisions, it must first sense and interpret its surroundings. Each stage depends on the ones that came before it, which is why the series follows this progression rather than introducing topics in isolation. Some stages may span multiple articles, but every article will contribute another piece of the final system.
Conclusion
Engineering is an iterative process, and I don't expect every design decision to survive unchanged until the end of the project. Some ideas will work exactly as planned, while others will force us to rethink our assumptions. Rather than hiding those moments, I want to document them, because understanding why something didn't work is often just as valuable as understanding why it did.
With the project introduced, it's time to start building. In the next article, we'll tackle the first engineering problem and begin turning the Micromouse from an idea into a functioning robot.
