1-Context
For those who haven’t come across it yet, u-blox recently introduced the ZED-X20D, a dual-antenna GNSS heading module based on the X20 high-precision GNSS platform.
While determining a heading solution was already possible with the ZED-F9P using a traditional moving-base/rover configuration, the key difference lies in how it is implemented.
With a conventional F9P solution, two separate GNSS receivers are required. One is configured as the moving base and the other as the rover. The two receivers need to exchange the appropriate RTCM correction data, while the host system collects the position and heading solution from the rover.
The ZED-X20D takes a more specialized and integrated approach, by providing two RF inputs for the two GNSS antennas, while the moving-base and rover functionality is handled and preconfigured internally. The receiver can therefore determine the relative vector between the two antennas and derive the orientation of the platform directly.
The result is an “out of the box”, true-north-referenced heading solution from a single GNSS module, while retaining the high-precision positioning capabilities of the X20 platform.
2-Objective
When thinking about GNSS heading, the obvious applications are moving platforms: vehicles, UAVs, boats, agricultural machinery, autonomous robots, and so on. But I wanted to find an application where the heading information itself was the interesting part, rather than simply another input to a navigation system.
Then it occurred to me that Ryan Gosling apparently has some issues with the Sun and has to keep an eye on it!
So there it is.
Build a system that tracks the Sun using the heading provided by the ZED-X20D.
The idea is simple: Give the system its position and orientation, calculate where the Sun should be, and point a camera in that direction.
3-System architecture
The setup consists of:
- ZED-X20D
- Two GNSS antennas ANN-MB2
- ESP-EYE camera
- ESP32-based Pan-Tilt controller
- Waveshare Pan-Tilt mechanism
- Host computer running the control software
The objective of the demonstration is to continuously point a camera toward the Sun.
Ideally, the Sun should appear at the center of the captured image.
The system therefore needs three main pieces of information:
- UTC Time, provided by ZED-X20D.
- GNSS position, provided by ZED-X20D.
- The heading of the antenna’s baseline, also provided by ZED-X20D.
Once these values are available, the script calculates the Sun’s azimuth and elevation using the Astropy library. The required pan and tilt angles can then be calculated and sent to the motorized camera mount.
The resulting architecture is therefore simple:
ZED-X20D -> heading + position -> control application -> Pan/Tilt controller -> camera
For the camera, I used an ESP-EYE. Its small size was convenient for the prototype, and it can provide images over Wi-Fi.
For the mechanical part, I used a Waveshare Pan-Tilt Kit. The kit normally comes with its own camera, but I wanted to keep the system based around an ESP32 rather than introducing a Raspberry Pi.
The ESP32 motor controller already provides an HTTP server allowing the pan and tilt motors to be controlled using JSON commands. I extended its firmware with a TCP server to establish a bidirectional link between the ZED-X20D UART interface and the computer running the application.
The two ZED-X20D antennas are mounted with a fixed baseline, allowing the receiver to determine the orientation of the platform from the relative GNSS measurements.
4-From GNSS heading to Sun position
The Sun’s position in the sky can be described using two angles:
- Azimuth: the horizontal direction of the Sun, referenced to true north.
- Elevation: the angle of the Sun above the horizon.
The GNSS receiver provides the UTC time, the geographical position and true-north heading of the platform through these messages:
- UBX-NAV-PVT
- UBX-NAV-DAHEADING
Using the current UTC time and the GNSS position, the application calculates the Sun’s azimuth and elevation using the Astropy astronomy library.
The control problem can then be reduced to a coordinate transformation:
- Camera pan angle = Sun azimuth − platform heading
- Camera tilt angle = Sun elevation
There are a few practical details hidden in this simple calculation.
The GNSS heading is referenced to the antenna baseline, while the Pan-Tilt mechanism and camera each have their own mechanical and optical references. Therefore, the software applies calibration offsets to compensate for mechanical and optical misalignment. These offsets are determined manually by aligning the Sun with the center of the camera image.
5- Software
The control application is implemented in Python.
The main tasks run independently:
- Collect GNSS data from the ZED-X20D
- Obtain position, time and heading information
- Calculate the Sun’s azimuth and elevation using Astropy
- Convert the astronomical coordinates into pan/tilt angles
- Send the corresponding commands to the Pan-Tilt controller
- Capture an image from the ESP-EYE
- Provide a web interface for monitoring the system
The camera is not used to determine where the Sun is optically. The system is completely open-loop with respect to the Sun: it predicts where the Sun should be based on GNSS-derived position, time and heading, and then points the camera there. The image is not part of the control loop. It is simply the visual proof that the calculation worked.
6- The demonstration
I designed three tests to progressively demonstrate the system, with an unexpected fourth test provided by nature itself.
6.1- Test 1 : Initial positioning
The first test starts with the platform in an arbitrary position and orientation, with the pan and tilt angles set to zero.
The system starts collecting GNSS data and obtains its position and heading from the ZED-X20D.
It then calculates the current position of the Sun and immediately commands the Pan-Tilt mechanism to point the camera toward the calculated direction.
This is probably the money shot.
As shown in the video, after acquiring the required GNSS information, the camera moves to the calculated position and points directly toward the Sun.
6.2- Test 2: Dynamic heading correction
For the second test, I manually rotate the camera platform.
This changes the relationship between the platform’s mechanical reference and true north, while the Sun itself obviously hasn’t moved significantly during the test.
The ZED-X20D detects the change in heading.
The application recalculates the required pan angle and commands the motor to compensate for the rotation.
This test is particularly useful because it demonstrates the role of GNSS heading independently from the Sun-position calculation. During the test, the astronomical target remains essentially unchanged; only the reference orientation of the platform changes.
6.3- Test 3: Autonomous Sun tracking
The final test is the real objective of the project.
The camera is placed in a fixed position and the system continuously calculates the changing position of the Sun.
As the Sun moves across the sky, the camera follows it.
The system was allowed to run for approximately three hours, from 06:26 UTC to 09:26 UTC.
The GIF below contains one image captured approximately every 20 minutes.
At 06:26 UTC, the calculated Sun position was approximately:
Azimuth: 85° Elevation: 18°
As a sanity check independent of the tracking software, SunCalc gives very similar values for the same location and UTC time.
But the most important validation is much simpler: The camera is actually pointing at the Sun.
6.4- Test 4 : The cherry on top
In a coincidence worthy of Tintin predicting a solar eclipse to save his life from the Incas, I happened to build this Sun tracker during the exact week of a solar eclipse. Either absurdly good luck or a cosmic sense of humor. Either way, today’s celestial alignment provided an unexpected real-world test of the system.
Unlike a tracker that relies on the Sun’s apparent brightness to determine its direction, this system does not use optical feedback at all. The target coordinates are calculated from position and time, so the eclipse itself has no effect on the pointing solution.
The test did, however, highlight some of the limitations of the demonstration setup. The low-cost camera and improvised solar filter are by no means suitable for imaging the changing profile of the Sun as the Moon moves across it. As a result, the partial eclipse itself is impossible to resolve clearly in the captured images.
Nevertheless, the sequence clearly captures a secondary effect of the event: the progressive reduction in the Sun’s recorded brightness between first contact (C1), maximum eclipse and sunset. From my location, observing the complete event up to C4 was not possible, as the Sun had already dropped below the horizon. To make this comparison meaningful, the camera exposure was fixed throughout the experiment and all automatic image adjustments were disabled. The observed intensity variation therefore reflects an actual change in the illumination reaching the camera rather than automatic exposure compensation. Of course, this cannot be attributed to the eclipse alone: the decreasing solar elevation, increasing atmospheric attenuation toward the horizon also contribute to the recorded brightness variation
7- System Limitations & Error Budget
For a prototype built with hobby-grade actuators, the dominant error sources are mechanical and optical rather than GNSS-related:
- Camera-to-platform alignment
- Pan/tilt mechanical accuracy and resolution, the servo is controlled by 1° step.
- Mechanical backlash and platform slight vibration, the tripod-mounted structure tends to wobble slightly when the servomotors move.
- Optical imperfections, the low-cost, improvised filter used to reduce the Sun’s exposure on the camera introduces some glare and distortion.
Interestingly, the Sun is a rather forgiving target for this demonstration, so these imperfections have little impact on visually demonstrating successful tracking. With an antenna baseline of approximately 0.5 m in this setup, the expected heading accuracy of the ZED-X20D is around 0.2°, already significantly better than the angular resolution and mechanical accuracy of the Pan-Tilt mechanism.
8- Takeaway
The main takeaway from this project is how easily a GNSS heading solution can be integrated into an application when the heading solution is already handled inside a single, compact GNSS receiver.
With a traditional two-receiver moving-base implementation, the system designer has to deal with two GNSS receivers, inter-receiver communication, moving-base configuration and the associated software architecture.
With the ZED-X20D, the dual-antenna architecture and heading solution are integrated into a single module, significantly reducing the amount of system-level integration required.
9-Where could this go next?
Sun tracking is obviously a use-case in itself.
A similar approach could be used for solar-panel orientation, where the goal is to keep a photovoltaic panel optimally aligned with the Sun.
But the same principle can be applied to more technically demanding applications, for example:
– Directional antenna alignment, a directional RF antenna could be automatically oriented toward a known geographical target, for example when establishing temporary point-to-point communication links.
– Satellite tracking, the same principle can be extended to a moving astronomical target by replacing the Sun-position calculation with orbital propagation. Applications could include mechanically steered C- or Ku-band antennas.
Food for thought!
Disclaimer
Test results shown in this article are only indicative, repeatability is not guaranteed.