A solar tracker can know the Sun's expected path, calculate an angle and move its panel accordingly. Julián Caro Linares' version does something much easier to watch: it looks everywhere.
Two small servos carry the panel through a grid of orientations, pausing long enough at each stop for the Arduino to read both panel output and infrared light. Once the sweep is over, the strongest reading in the map determines where the mechanism goes back to work.1
The published sketch visits 135 measurement points during a complete sweep. On a tiny panel chasing a few volts, that is an extravagant amount of motion, yet in a classroom the excess becomes useful because the process of choosing an angle stays visible from beginning to end.
135 positions
Its two axes define the grid: 15° to 155° horizontally and 5° to 90° vertically, each advancing in 10° steps. Fifteen horizontal stops multiplied by nine vertical ones produce the 135 angle pairs.1
The software does not jerk straight from point to point. It moves the servos one degree at a time and waits 300 ms for the structure to settle before reading panel voltage through an analogue input together with infrared light from a Modulino Light sensor. The scan snakes across the grid, climbing one column and descending the next instead of repeatedly returning to the same edge.1
Settling delays alone consume 40.5 seconds before any servo travel is counted, so this is hardly a twitchy head correcting itself every second. Over the course of a scan the mechanism fills its map, remembers the maximum and returns to the winning orientation only after it has looked across the whole range.
This is also more revealing than the familiar tracker made from four light-dependent resistors around a small divider. Here the full map of readings can be displayed. You can literally see which regions of the sky produced more or less panel voltage.
Two brains
The project uses an Arduino UNO Q, a hybrid board combining a Qualcomm Dragonwing QRB2210 processor capable of running Debian with an STM32U585 microcontroller for real-time I/O.3
The division is more than a spec-sheet flourish: the microcontroller stays close to the hardware, reading the panel and Modulino sensors while driving the servos and handling immediate reactions, whereas Debian takes the web server, time-series history and weather logic, with Arduino App Lab's Bridge carrying messages between them.12
Open the local web page and the two-axis position sits beside the solar reading, infrared level, temperature, humidity, forecast and history. In practice, the scan heatmap is more useful than the pile of individual numbers because it shows the result of the sweep in one view.1
That visibility is the educational payoff. Someone at the bench can watch an angle change, read the corresponding voltage, compare the infrared value and come back later to the recorded series, keeping mechanics, sensing, decision and result in the same experiment instead of hiding the interesting part behind an API.
Beyond tracking
Tracking is only one state in the program. A low panel reading sends the mechanism home, temperatures above 60°C move it into a protective posture, a movement sensor watches for abnormal vibration, and a small vibration motor can shake the structure to dislodge dust or debris.1
The Linux side also queries a weather forecast. In the code currently published, a forecast categorised as "snowy" or "foggy" triggers an alert passed to the microcontroller.1
Arduino's blog description speaks more broadly about snow and sandstorms.2 The source is narrower at the moment, and a few prototype seams remain in plain sight. Weather is hard-coded to Turin; the scan-interval constant is 10,000 ms although its comment says ten minutes, and the published line currently lacks a semicolon.1
In a teaching build these are ordinary rough edges, but they are also useful warnings against reading the project as a roof controller ready for two decades of unattended service.
The missing gain
The tracker measures its own panel and chooses the best angle. The published data and code do not measure what a comparable fixed reference panel would have produced at the same time.1
There is therefore no basis for attaching a 20, 30 or 40 percent gain to this prototype. By contrast, tracker research does report substantial improvements in other systems: a 2025 review gives broad ranges of roughly 20–35% for single-axis and 30–45% for dual-axis installations over fixed panels, with the result changing sharply with latitude, climate and design.4 None of those percentages comes from this build.
A fair comparison would need another number as well: the energy consumed by the servos, computer, network and scanning routine. The cost of tracking is part of the experiment, since net yield only becomes meaningful after the energy spent on movement and computing is deducted from whatever extra energy the panel collects.
Print the mechanism
The repository includes Python code, the microcontroller sketch, web interface, 3MF/STL files and, usefully, the original FreeCAD model for the mechanism.1 The printed assembly starts from a pan-and-tilt design for MG90S servos and adapts it for the panel and sensor modules.
The README recommends PLA for short use but suggests PETG if the structure will spend long periods in sunlight because PLA can soften in heat. The plastic holding a solar panel, rather neatly, has its own problem with the Sun.1
That is where the project works best. Solar energy stops being a number on a specification sheet and turns into a chain of physical chores: fabricate the joint, choose its limits, wait for vibration to settle, read a sensor, preserve the history and define safe states. In the end, two orientations of the same panel produce two different electrical responses, and the reason for moving is no longer abstract.
The tracker teaches more than how to follow the Sun. It shows how a machine can inspect several outcomes, choose the best one and leave enough evidence behind for a person to understand why it moved.