Micromouse robots look deceptively simple from the outside. A small robot enters a maze, explores it, finds the shortest path, and eventually performs a high-speed run to the center. In practice, however, building a reliable micromouse involves several interacting systems working together in real time.
This post describes the software and control architecture I am planning for my micromouse project. The focus is not on the maze-solving algorithm itself, but rather on how the lower-level robotics stack will be organized to support reliable motion, localization, and future expansion.
The goal is to design the system in layers, where each layer abstracts complexity away from the layer above it.
At a high level, the software stack can be divided into several layers:
Maze Solving Logic
↓
Path Planning / Motion Commands
↓
Localization + State Estimation
↓
Motion Control Loops
↓
Motor Driver Interface
↓
Hardware
The maze-solving logic should not need to know how motors are driven, how encoder ticks are counted, or how sensor timing works internally. Instead, it should operate on higher-level abstractions such as:
Similarly, the lower-level hardware drivers should not know anything about maze-solving algorithms.
This separation makes the system easier to debug, extend, and optimize independently.
The bottom layer of the system consists of hardware drivers:
These components will expose clean interfaces to the upper layers.
For example:
The higher-level logic should never directly manipulate GPIOs or timers.
Wheel encoders are one of the most important sensors in the system because they provide local motion information.
The current plan is to connect the quadrature encoders directly to hardware timers configured in encoder mode. This allows the microcontroller to count encoder pulses in hardware instead of relying on software interrupts for every tick.
Using hardware timers provides several advantages:
From the encoder counts, wheel displacement can be computed:
d=\frac{2\pi rN}{P}
where:
These wheel displacements can then be used for odometry.
The micromouse can be modeled as a differential drive robot.
The robot pose consists of:
The state is represented as:
(x,y,\theta)
The robot motion model is:
\dot{x}=v\cos\theta,\quad \dot{y}=v\sin\theta,\quad \dot{\theta}=\omega
where:
Wheel encoder readings provide estimates of wheel motion, which can be converted into linear and angular velocity estimates.
Encoders alone are not sufficient for accurate localization because wheel slip and accumulated integration errors introduce drift over time.
To improve local pose estimation, the current plan is to fuse:
The IMU can provide short-term rotational stability, while the wheel encoders provide translational motion estimates.
The localization layer will combine these measurements to estimate the robot pose continuously during movement.
Initially, the fusion may use relatively simple filtering approaches, but the architecture should allow more advanced estimators later, such as:
The important design goal is to separate sensor acquisition from state estimation logic.
Different parts of the system operate in different coordinate frames.
Examples include:
The robot frame moves with the mouse, while the world frame remains fixed relative to the maze.
Higher-level maze logic should operate in the world frame. However, sensors naturally measure distances relative to the robot frame.
This means transformations between frames are required.
A point measured in the robot frame can be transformed into the world frame using rotation and translation:
\begin{bmatrix}x_w\y_w\end{bmatrix}=\begin{bmatrix}\cos\theta & -\sin\theta\sin\theta & \cos\theta\end{bmatrix}\begin{bmatrix}x_r\y_r\end{bmatrix}+\begin{bmatrix}x_0\y_0\end{bmatrix}
This abstraction becomes increasingly important as the system grows more complex.
For example:
Keeping frame transformations explicit helps avoid many localization and control bugs.
Instead of using a single controller for all movement, the current design separates the control system into multiple specialized loops.
Different movement modes require different feedback strategies.
The lowest-level motion controller regulates wheel velocity.
This loop uses encoder feedback to maintain target wheel speeds and compensate for battery voltage changes or motor inconsistencies.
When moving forward through a corridor, the robot must maintain heading stability.
This controller may use:
to keep the robot centered and aligned.
When walls are available, wall sensors provide additional positional correction.
This controller attempts to maintain equal spacing from nearby walls while moving forward.
This is particularly useful for reducing long-term drift.
Turns require a different control strategy from straight motion.
During turns, the robot primarily cares about rotational accuracy rather than wall alignment.
The turning controller may rely heavily on:
to achieve accurate 90-degree or 180-degree rotations.
The higher-level planner should not directly command PWM values.
Instead, it should issue higher-level motion primitives such as:
These abstractions isolate maze logic from low-level control implementation details.
This separation also makes simulation easier because the higher-level planner can operate independently from the physical hardware drivers.
The initial goal is reliability and modularity rather than raw speed.
Once the lower-level architecture is stable, future work may include:
A strong software architecture early on should make these improvements easier to integrate later.
One of the interesting aspects of micromouse is that it combines multiple engineering disciplines into a very small robot:
Even though the maze-solving algorithm often receives most of the attention, the lower-level control stack is what ultimately determines whether the robot moves accurately and reliably inside the maze.
This post mainly documents the current design direction and architectural ideas for the project. The implementation will likely evolve over time as the robot is tested and improved.
Repository: https://github.com/N1K0-micromouse/n1k0_v0.1 — private; util development complete.