\section{Problems and Discussion}

During the development of the Micromouse robot, several practical problems were encountered that affected commissioning, debugging, and system integration. Some of these issues were resolved completely, while others remained as limitations of the final system behaviour. For this reason, the discussion in this chapter addresses not only the most relevant implementation problems, but also the main technical limits of the realised prototype. This distinction is important because the project should be evaluated not only by whether the robot functioned at all, but also by how robustly and under what constraints it was able to perform the intended task.

\subsection{Turning Accuracy and Motion Robustness}

One important limitation of the final system concerns turning behaviour. Straight driving was supported by closed-loop wheel-speed control and wall-based trim correction, but the turning manoeuvres themselves were executed with fixed motor commands and were terminated once a target encoder count had been reached. This approach was sufficient to realise left, right, and $180^\circ$ turns in practice, but it did not constitute full closed-loop orientation control during the turn itself.

As a consequence, the turning accuracy depended on factors such as floor friction, battery condition, wheel slip, and the exact mechanical response of the drivetrain. In practice, the turns were therefore only approximate. The robot was still able to recover from moderate errors once it re-entered a corridor with side-wall reference, because the wall-based correction could compensate some of the resulting misalignment. However, this also means that the straight-line controller partly compensated for imperfections that had actually originated in the turning process. From an engineering perspective, this is acceptable for a functional academic prototype, but it is also a clear limit of the present implementation. A more advanced system would ideally use dedicated closed-loop turning control, for example with more precise turn calibration or an additional orientation reference.

\subsection{Cell-Centre Detection and Localisation Sensitivity}

A second important limitation concerns the detection of cell centres and the resulting localisation consistency. The navigation software estimates the next cell centre using a combination of encoder-based travelled distance and front-sensor-based wall interpretation. This concept is technically reasonable because it combines internal motion estimation with external environmental information. Nevertheless, the method remains sensitive to disturbances in the underlying signals.

In practice, the reliability of cell-centre detection was influenced by controller-induced speed fluctuations, accumulated odometry error, and the threshold-based interpretation of the front sensor. If the decision was triggered slightly too early or too late, the internal cell index of the robot no longer matched its physical position exactly. Since the maze map is built incrementally from these position updates, even a small localisation error can affect the consistency of the later navigation decisions. This was one of the main reasons why the final system should be understood as a robust educational prototype rather than as a fully optimised competition platform. The implemented approach worked sufficiently well for the reduced maze and moderate operating speed, but its sensitivity would become more critical in longer runs or at higher speed.

\subsection{Reduced Maze Scope and Algorithmic Generality}

Another important point for interpreting the project results is the deliberately reduced problem scope. The classical Micromouse task is defined on a $16 \times 16$ maze, whereas the present project used a $6 \times 6$ maze with a predefined goal. This reduction was justified in the context of the available time and resources, because it made it possible to complete the full chain of hardware design, embedded implementation, control design, testing, and autonomous navigation within one academic project.

At the same time, this decision limits the generality of the final results. The implemented navigation software demonstrated successful map construction and goal-directed path execution, but it was not validated on the full classical problem size and should therefore not be interpreted as a competition-level Micromouse solution. In particular, larger mazes place higher demands on localisation robustness, systematic exploration efficiency, and overall repeatability of motion. The reduced scope was therefore an appropriate engineering trade-off, but it remains important to state explicitly that the reported results refer to this reduced task definition.

Besides these system-level limitations, several concrete implementation problems also occurred during commissioning and hardware integration. These are discussed in the following subsections because they significantly influenced the practical development effort and the available debugging workflow.

\subsection{ICSP Programming Interface Error}

A first major problem occurred during the initial programming of the microcontroller. Although the ICSP interface had been included in the schematic and PCB design, the component used in Eagle did not match the exact programming device available during implementation. As a result, the pin assignment on the board did not correspond correctly to the required ICSP signals. In particular, the supply pins and the programming-related connections were assigned incorrectly, so that the expected programming signals were not applied to the intended contacts. Consequently, the microcontroller could not be flashed successfully during the first commissioning attempts.

To diagnose and circumvent this problem, the fixed pin-header arrangement at the programming interface was temporarily replaced by individually routed jumper wires. This made it possible to rearrange the signal assignment manually between the board and the programmer until a working connection was found. In this way, the incorrect PCB-level mapping could be compensated externally without immediately redesigning the board. The workaround ultimately enabled successful flashing and therefore allowed further software development to continue.

A second complication arose during the rework of this interface. When the original header arrangement was removed, excessive heat damaged two solder pads, including the originally intended \texttt{VDD} connection. As a result, this contact could no longer be used reliably. The problem was resolved pragmatically by sourcing the required supply connection from another header on the same board that belonged to a different module of the system, while the remaining programming-related lines continued to use the ICSP area. Although this solution was improvised, it restored a functioning programming interface and remained usable for the remainder of the project.

Overall, this problem highlighted the importance of verifying not only the logical schematic design, but also the exact correspondence between library components, physical connectors, and the programming hardware used during commissioning. In addition, the incident showed that rework on densely soldered interfaces can easily introduce secondary damage if not carried out carefully.

\subsection{Bluetooth Module Configuration Error}

A further hardware-related problem occurred during the integration of the Bluetooth module. In this case, the issue was caused by confusion between the pins \texttt{P2\_0} and \texttt{P0\_2}, whose names are visually similar but whose functions differ substantially. One of these pins was intended to define the operating mode of the module and therefore had to be held permanently at a defined logic level, while the other was associated with a status indication function \cite{datasheet_bluetooth}. During implementation, these two pins were confused, and the LED-based indicator circuit was connected to the wrong signal.

As a consequence, the mode-selection pin did not receive a stable 3.3\,V high level as required for normal application operation. Instead, the connected LED path interfered with the intended signal level, so that the Bluetooth module did not operate correctly. The error was eventually identified by revisiting the module pin assignment and comparing the implemented connection against the intended configuration.

The practical fix was straightforward but irreversible in terms of debugging convenience. The resistor and LED associated with the incorrect connection were removed, and the line was bridged directly with solder in order to establish a permanent electrical connection. This modification restored the required logic level and made the Bluetooth module operational. However, the original LED-based activity indication was no longer available afterward. The problem therefore did not prevent further use of the communication interface, but it did reduce the available visual debugging support.

This issue illustrates how easily implementation errors can arise when documentation contains similarly named pins with very different roles. In such cases, even a small interpretation error in the pinout can render an otherwise correctly assembled module inoperative.

\subsection{BLE Communication and Range Limitations}

Another recurring difficulty concerned the practical use of the Bluetooth-based UART interface during debugging. Even after the hardware connection of the module had been corrected, it was initially unclear how the communication between the BLE-capable robot hardware and an external device should be accessed and interpreted in practice. In particular, the expected data stream was not immediately available through a simple terminal-like workflow on a laptop, and the interaction between the BLE peripheral on the robot and the corresponding host-side interface required additional investigation.

Two practical solutions were identified during development. One option was to use a BLE scanner application, specifically \emph{nRF Connect for Mobile}, which provides a general-purpose interface for discovering and inspecting Bluetooth Low Energy devices~\cite{nrfconnect}. This allowed the transmitted data to be observed directly on a mobile device. The second solution was the development of a custom Python-based host script on the laptop side, which was ultimately adopted for the intended debugging workflow. This script provided a more convenient and reproducible way of accessing the transmitted data in the development environment.

In addition to the software-side communication difficulty, a practical limitation of the wireless interface was observed in the physical range of the Bluetooth connection. In operation, the connection proved to be reliable only over a relatively short distance of approximately 0.5\,m. This was significantly less than initially desired for comfortable debugging and monitoring. It was suspected that the PCB environment, in particular the surrounding conductive structures and ground-plane configuration, negatively affected the radio performance of the module \cite{datasheet_bluetooth}.

Taken together, these communication-related issues did not prevent the use of the wireless debugging interface, but they did increase the implementation effort and reduced the practical convenience of the solution. The experience showed that integrating BLE communication is not only a matter of electrical connectivity, but also of understanding the host-side software workflow and the physical limitations imposed by the final hardware environment.