ARTEMIS II seguiamola insieme in tempo reale!
OrionWatch: quando la telemetria spaziale
diventa una dashboard in tempo reale
Un progetto personale costruito attorno alla missione Artemis II, tra dati NASA, Three.js e qualche notte passata a debuggare parser diversificati.
Perché questo progetto
Il 2 aprile 2026 la NASA lancia Artemis II, il primo volo con equipaggio umano verso la Luna dai tempi dell'Apollo. Quattro astronauti — Reid Wiseman, Victor Glover, Christina Koch e Jeremy Hansen (il primo canadese a volare verso la Luna) — percorrono quasi 400.000 km su una traiettoria di 10 giorni.
Seguire la missione sui canali ufficiali significa aggiornare una pagina ogni tanto, leggere comunicati stampa, guardare stream sporadici. Volevo qualcosa di diverso: una finestra sempre aperta sulla missione, con dati reali che si aggiornano in autonomia, una scena 3D interattiva che mostrasse la posizione effettiva del veicolo nello spazio.
Così ho costruito OrionWatch.
Live demo: francescodibiase.com/orionwatch
Cos'è, in concreto
OrionWatch è una SPA (Single Page Application) che aggrega undici fonti di dati pubbliche — NASA, JPL, NOAA, CelesTrak — e le presenta in un'interfaccia stile Bloomberg Terminal: tutto visibile simultaneamente, zero scroll per i dati critici, aggiornamento automatico.
La schermata principale mostra:
• Scena 3D interattiva con Terra, Luna e il veicolo Orion sulla traiettoria effettiva
• Telemetria live: distanza dalla Terra e dalla Luna, velocità, Mach, ritardo di segnale, G-force, percorso totale
• Space weather in tempo reale: vento solare, indice Kp, brillamenti solari, previsione aurora
• Stato della Deep Space Network: quali antenne di Goldstone, Madrid e Canberra stanno puntando la missione e a che data rate
• Media: immagini della missione, blog NASA, foto della Terra da DSCOVR, APOD Supporta sei target: Artemis II (live), Artemis I (storico), ISS, Voyager 1, James Webb e una modalità demo offline.
L'estetica
L'ispirazione visiva viene dai terminali Bloomberg e dai sistemi HUD militari: sfondo quasi-nero (#080c16), accenti cyan (#00d4ff) e ambra (#ff6b35), tipografia Space Grotesk per i titoli e Space Mono per i numeri di telemetria. Pannelli con bordi sottili 1px, angoli decorativi, nessun gradiente sul testo, nessun elemento
skeuomorfico.
Su desktop (≥1280px) il layout è a tre colonne fisse — sidebar densa con tutti i metrici, scena 3D che occupa lo spazio centrale, pannello operativo a destra. Nessun tab, tutto visibile. Su mobile le stesse informazioni diventano sezioni accordion collassabili con scroll naturale.
Come si usa
La navigazione 3D è standard: drag per ruotare, scroll per zoom, click destro per pan. Il pulsante Locate riporta la camera sul veicolo. Il cursore playback permette di scorrere l'intera traiettoria di missione con velocità regolabile (fino a 5000x); LIVE aggancia di nuovo il tempo reale.
Sotto il cofano — la parte tecnica
Da qui in poi si parla di architettura, scelte implementative e problemi concreti risolti durante lo sviluppo.
Stack
React 19, TypeScript strict, Three.js 0.172, Recharts 2, Zustand 5, Tailwind CSS 4, Vite 6. Nessun backend, nessun server, nessun segreto. Tutto gira nel browser del visitatore, consumando solo API pubbliche.
Bundle iniziale: ~85 kB gzipped. Three.js e Recharts sono lazy-loaded dopo il primo paint.
Il problema CORS e la doppia pipeline dati
JPL Horizons — la fonte principale per effemeridi di veicoli spaziali e corpi celesti — non supporta richieste browser in modo affidabile. Invece di appoggiarsi a proxy runtime, ho scelto una soluzione diversa: script PHP con cron job lato server che scaricano i dati ogni 10 minuti e li scrivono come file JSON statici. Il frontend li carica una volta sola all'avvio.
Per Artemis II convivono due pipeline parallele:
• NASA AROW (Artemis Real-time Operations Window) — telemetria reale da Mission Control,
aggiornata ogni ~60 secondi, CORS nativo via Google Cloud Storage. Alimenta i numeri nella
sidebar.
• JPL Horizons — effemeridi pre-calcolate con risoluzione 10 minuti per l'intero arco di missione.
Alimenta la traiettoria 3D.
Le due fonti divergono di circa 43.000 km rispetto alla posizione reale vs. prevista. Usarle entrambe per la stessa cosa avrebbe mostrato il veicolo staccato dalla sua traiettoria. Usarle per scopi separati — numeri reali e visualizzazione coerente — risolve il problema.
Interpolazione Hermite e spline Catmull-Rom
I dati Horizons arrivano con campionamento a 10 minuti. L'interpolazione lineare produce un pulsing visibile della velocità durante il playback.
La soluzione usa spline cubiche di Hermite con tangenti di velocità agli estremi di ogni intervallo:
H(t) = (2t³−3t²+1)·p₀ + (t³−2t²+t)·v₀·Δt + (−2t³+3t²)·p₁ + (t³−t²)·v₁·Δt
I vettori velocità sono già presenti nei dati di stato, quindi non serve approssimarli. Il risultato è un moto C¹-continuo fisicamente plausibile tra i campioni.
La linea di traiettoria 3D usa invece la parametrizzazione centripeta di Catmull-Rom (α=0.5).
Il Catmull-Rom uniforme standard produce cuspidi e overshooting vicino alla Terra, dove i punti sono densi e l'orbita curva bruscamente. La parametrizzazione centripeta distribuisce i punti di controllo in base alla radice quadrata della distanza accordale, eliminando l'artefatto.
Piano orbitale lunare realeGli anelli di distanza di riferimento (60k, 150k, 280k, 384k km) e il percorso orbitale della Luna nella scena 3D sono allineati al piano orbitale effettivo, calcolato dal prodotto vettoriale di due posizioni reali della Luna prese dai dati Horizons (corpo 301). Sostituisce un'inclinazione hardcodata a 28.5° che avrebbe fatto sembrare la Luna fuori traiettoria nelle fasi della missione.
External time control pattern
La scena 3D (SceneCore) ha il suo loop di animazione per il rendering in tempo reale. Durante il playback, un secondo loop RAF in ThreeScene controlla le posizioni di Luna e Sole al tempo simulato. Senza coordinazione, i due loop si sovrascriverebbero, causando salti visibili nella posizione della Luna.
Il flag externalTimeControl inibisce gli aggiornamenti interni di SceneCore, cedendo il controllo esclusivo al loop di playback durante la simulazione.
Performance: oggetti pre-allocati e update throttled
Il loop di playback gira a 60fps ma scrive nello store Zustand solo a ~4Hz (ogni 15 frame). La posizione del Sole viene aggiornata ogni 30 frame. Gli array di punti traiettoria sono in cache su ref per evitare re-spread ogni frame. Le geometrie Three.js usano BufferGeometry con aggiornamento diretto dei buffer di posizione invece di ricreare oggetti. Lo heap rimane piatto nel tempo.
Texture senza CORS
L'hosting condiviso non invia header CORS per asset statici. TextureLoader di Three.js imposta
crossOrigin="anonymous" per default, scatenando un preflight che fallisce.
La soluzione aggira TextureLoader completamente: le texture vengono caricate tramite new Image() senza attributo crossOrigin, poi avvolte in new THREE.Texture(img). Il browser le carica come richieste same-origin normali.
Codice e licenza
Il progetto è open source con licenza MIT. I dati provengono interamente da fonti pubbliche NASA, JPL-Caltech, NOAA, CelesTrak. Le texture di Terra e Luna sono courtesy di NASA Visible Earth.
GitHub: github.com/Francescodib/OrionWatch
Francesco di Biase — francescodibiase.com
Il Blog di overnext non è il blog di una persona sola.
È uno spazio nato dalla collaborazione tra amici, ingegneri informatici, scienziati, ricercatori, designer, sviluppatori e appassionati di tecnologia che condividono la stessa curiosità: esplorare l’informatica e la tecnologia ad altissimo livello senza mai perderne il contatto con la vita di tutti i giorni.
Qui non troverai articoli scritti da un’unica voce, ma contributi che nascono dal confronto reale, dal lavoro di squadra e dalla voglia di mettere in comune competenze diverse. Ogni post è il risultato di discussioni, sperimentazioni, code review, notti passate a debuggare insieme e idee che passano da una chat all’altra fino a diventare contenuti concreti.
Parliamo di sistemi complessi, architetture avanzate, intelligenza artificiale, sicurezza, performance e innovazione tecnologica… ma sempre con un obiettivo chiaro: rendere queste conoscenze utili, comprensibili e applicabili nella vita quotidiana di chi lavora, studia o semplicemente ama la tecnologia.
Perché per noi overnext non è solo un nome: è l’idea che il futuro si costruisce insieme, condividendo sapere e progetti reali.
Benvenuti nella nostra crew.




Commenti
Posta un commento