In the introduction I've explained the reason for the mirror, one of the key innovations of the project and the inspiration behind its name.

Another key innovation of this robot is the "finger-follower" feature: the finger position is tracked on the robot's touchscreen, and the ball follows it in real time. By watching the display, the ball continuously "lands" underneath the finger.

This feature was already in my mind during the early stages of the project, when I was considering using a large touchscreen display. By pure coincidence, ELECROW proposed a sponsorship and sent me a 7-inch DSI touchscreen display. The robot also works without a display, but the display is what really makes it enjoyable and complete.

Besides the real-time camera image, with overlayed ball detection, the GUI exposes several additional features:

• A set of predefined geometrical paths, where the robot tilts the platform to force the ball along specific trajectories. One of these is the "free-path", where the user defines the path on the fly by moving a finger on the touchscreen.
• Automatic ball color calibration. This is one of the robot's most elaborate functions. The platform image, including the background, is analyzed for dominant colors and contour shapes to estimate the ball color and automatically define an optimized color range, reducing background noise as much as possible.

The main characteristics of this robot are also explained in the below YouTube video:

In the video, several features aren't mentioned, like the PID, the sensorless homing and the custom I2C protocol...

• PID parameters adjustable via sliders, with immediate real-time effect. This makes tuning highly intuitive, since cause and effect are instantly visible. The Integral term is generally unnecessary when the platform is properly levelled, but it also becomes an educational feature when intentionally tilting the whole robot, where the Ki term helps compensate for the bias.
• Sensorless homing parameter adjustment (StallGuard sensitivity). The robot uses TMC2209 silent stepper drivers, whose StallGuard feature automatically detects the platform home position. From there, the motors move a predefined number of steps to reach the balancing position, where the motor arms are approximately horizontal, allowing about 40 degrees of platform tilt.

Custom I2C protocol (Python ↔ MicroPython, with pre-encoded parts in C)

This is another key area of the project, worth mentioning here despite being covered in detail across about 10 pages of documentation.

A Raspberry Pi 4B acts as the brain of the robot and sends commands via I2C to three RP2040-Zero boards controlling the stepper drivers.

I wanted to use RP2040-Zero boards because I really like the PIO features, here used to generate precise quantities of motor steps at the intended speed. However, I could not find a suitable MicroPython library to use the RP2040 as an I2C receiver, so I implemented code originally suggested by danjperron on a Raspberry Pi forum.

At a high level, the Raspberry Pi sends 2-byte packets containing speed and step-count information, encapsulated in a custom protocol using STX, escape characters, checksum validation, and ETX markers.

The RP2040 first validates the received packet and then decodes the data fields into speed, direction, and number of steps.

Since the I2C communication runs on core1 of the RP2040, while core0 handles the remaining tasks, the two cores exchange information through the mem16 shared-memory area.

Thanks to the PIO feature, despite the relatively limited execution speed of the MicroPython interpreter, the RP2040 boards operate very reliably. In practice, this reliability allowed me to design the communication as almost entirely mono-directional: the Raspberry Pi sends commands to the RP2040 boards and simply trusts the job gets done.