Inspiration

Full credit to WillsBuilds on YouTube, who built a stunning 8-inch magnetic ISS tracker that really sparked the idea. His build is beautiful — we highly recommend watching it.

The Orbigator set out to solve two specific limitations of that design:

• The globe rotates around the mechanics. The key design inversion: rather than an arm pointing out from fixed electronics, the Orbigator puts the two-axis gimbal inside the acrylic globe, and the globe itself turns on the EQX (azimuth) axis as part of the mechanism. The sphere is simultaneously the display and the tracker — no cable fighting rotation.
• Continuous tracking, no rewind. Because the globe turns continuously with the satellite, the arm never needs to reset or skip. The ISS orbits indefinitely and the Orbigator follows every pass without interruption.

The Orbigator is a kinetic art piece and precision instrument — a two-axis servo-driven arm inside a 30 cm acrylic globe that points continuously at the International Space Station (or any tracked satellite) using real-time SGP4 orbital propagation.

How It Works

A Raspberry Pi Pico 2W runs a full SGP4 orbital propagator in MicroPython. Every second it fetches the current satellite position using a cached Two-Line Element (TLE) set downloaded from CelesTrak. The result — inclination angle and right-ascension angle — is sent to a pair of Dynamixel XL330 servo motors via RS-485, driving a two-axis gimbal arm inside the globe to point directly at the satellite.

• Motors: Dynamixel XL330 × 2 (Extended Position Mode, 1° resolution)
• MCU: Raspberry Pi Pico 2W (MicroPython)
• Display: 128×64 SH1106 OLED
• RTC: DS3232 with battery-backed SRAM for state persistence across power cycles
• TLE source: CelesTrak, auto-refreshed every 12 hours over WiFi

Overhead Alert Radar — New Feature

The latest firmware addition wakes the OLED display automatically when the tracked satellite rises above your local horizon. Rather than waiting for a scheduled pass, the Orbigator continuously runs a trig-free dot-product horizon test on every tracking tick (six multiplies and three adds — no atan2, no sqrt). When the satellite crosses zero elevation, a three-second dwell confirms it’s a real rise rather than a noise event, and the display wakes showing a radar-style sky plot:

• Left panel: Az and El in degrees, updated every second
• Right panel: Radar circle (horizon = outer ring, zenith = centre) with the satellite’s trail arc and a current-position dot
• The trail records one point per minute, covering the full pass from rise to set
• The display stays on for the entire pass, then returns to normal idle-timeout behaviour

Observer location is determined automatically at boot by querying the Wyolum geolocation endpoint, which returns latitude and longitude based on the device’s public IP. The ECEF station position and local East/North/Up unit vectors are precomputed once from that fix and held in RAM — zero per-tick overhead.

Software Architecture

The firmware is structured as a layered stack in MicroPython:

• sgp4.py — pure SGP4 propagator (TLE → ECI coordinates)
• satellite_position.py — ECI → ECEF → geodetic (WGS-84)
• propagate.py — motor angle engine (orbital elements → AoV/EQX degrees)
• observer_frame.py — station ECEF + local ENU unit vectors (precomputed)
• overhead_watcher.py — hysteresis state machine for horizon crossing
• radar_display.py — sky plot renderer with ring-buffer trail
• modes.py — mode stack (settings, homing, SGP4 tracking, radar alert)

Full source code is available on GitHub: github.com/wyolum/orbigator.

# Orbigator Dev Log: From Simulation to Reality

It’s been a while since the last update, and the Orbigator has evolved from a collection of parts and Python scripts into a fully integrated, silent, and precise satellite tracking machine.

Here is the story of how we got here.

## 1. The Hardware Pivot: Steppers vs. Smart Servos
We started where most builds start: **Stepper Motors**. They are cheap and ubiquitous. But for a device meant to sit on a desk and track the ISS silently 24/7, they had drawbacks. They vibrate, they make noise (“singing”), and crucially, they are **open-loop**—if the arm gets bumped, the system loses its place and stays lost.

We pivoted to **Dynamixel XL330** smart servos.
* **Silence**: They are virtually silent at tracking speeds.
* **Closed-Loop**: They know their absolute position. If you push the arm, it fights back (torque!).
* **Cabling**: They daisy-chain on a single bus, drastically reducing the rat’s nest of wires.

## 2. The Brain Transplant: MicroPython on Pico 2W
We moved the logic from a desktop PC to the **Raspberry Pi Pico 2W**. This brought its own set of challenges, primarily **Floating Point Precision**.

Standard SGP4 libraries assume full 64-bit float precision. On a microcontroller payload, 32-bit floats aren’t precise enough to handle Julian Dates (numbers like `2460678.12345`) while keeping second-level accuracy. Our initial tracks were off by thousands of kilometers!

**The Fix**: We refactored the satellite math to use **Integer Unix Timestamps** for the heavy lifting, only converting to small relative offsets when necessary. We verified this against NASA’s own trackers, bringing our error down to a negligible **~50km** (on a global scale).

## 3. The Interface: Web & OLED
A tracker isn’t fun if you don’t know *what* it’s tracking.
* **OLED HUD**: We added a tiny 128×64 display on the base for immediate stats: Latitude, Longitude, and current satellite name.
* **Web Dashboard**: Since the Pico 2W has WiFi, we built a hosted React dashboard. You can connect to the Orbigator from your phone to see a 3D visualization, change the tracked satellite (ISS, Hubble, Tiangong), and tweak settings live.

## 4. Tuning the Mechanics
The Arguement of Vehicle (AoV) arm (the part that looks like a closed pair of scissors) completes one revolution per orbit.  It is counterweighted to balance the system and alievate motor wear.  Physics caught up with us. Adding the AoV assembly—complete with magnets and pennies for counterweights—introduced a pendulum effect. The motor would “wobble” as it tried to hold position.

We wrote a custom auto-tuning script (`tune_wobble.py`) to cycle through PID profiles. We landed on a stiff-but-smooth profile (`P=600, D=0`) and capped the speed. Now, it glides.

## 5. What’s Next?
The mess of wires you see in the photos is “development aesthetic.” It works, but it’s fragile.

The next phase is purely hardware. I’m teaming up with **Anool** and **Kevin** to design a custom **Orbigator Control Board** that integrates the Pico, the RTC (Real Time Clock), and the motor drivers into a single, clean PCB.

The code is committed, the math is integer-perfect, and the motor is zeroed. Onward to proper PCBs!

Open Source Repo: https://github.com/wyolum/orbigator/

Working on a satellite tracker inspired by WillBuilds. Thanks will for posting your awesome globe. This one is base on a 13″ globe that spins instead to keep the wires from getting wrapped around the poles. Each axis turns at a constant rate (assuming a circular orbit). The setup can accommodate any circular orbit by setting the orbital inclination manually before placing the globe. The cart is held in place by to steel ball-bearings that will be aligned by two internal magnets on the orbital arm. Should be pretty neat.

Full video of Will’s Build is here: https://www.youtube.com/watch?v=nbEe-BCNutg