Sviluppo di un simulatore/data plotter per la missione Perseverance

Il mio nuovo simulatore per seguire la “Corsa a Marte 2021”:

https://jsfiddle.net/spacexplorer2020/5f0uqxe3/23/
( altro link )

E’ un po’ rozzo come sempre, perchè come sempre resterà in fase di sviluppo per sempre… :sweat_smile: comunque è già abbastanza utilizzabile: basta cliccare sul pulsante in alto e aspettare che si scarichino i dati. A quel punto è possibile ruotare il pianeta per osservare i 3 puntini che rapprsentano Tianwen, Hope e Mars2020: premendo il pulsante PLAY in basso a sinistra, inizierà l’animazione; la barra in basso mostra graficamente l’avanzamento della data, che è anche mostrata nell’angolo in basso a sinistra; la velocità dell’animazione si regola spostando la freccia che ruota intorno proprio a quella data.
Occhio perchè minore è lo step (che può variare da 1m (1 minuto) a xd (x giorni) ), maggiore è la quantità di dati che verrà scaricata, che può arrivare a svariati mega per ogni oggetto!

La texture di Marte è li praticamente per bellezza, perchè purtroppo non sono riuscito a implementare l’ora locale, o longitudine che dir si voglia, quindi tanto varrebbe che fosse una palla rossa omogenea…
Anche stelle e galssie stanno lì per bellezza, non ci fate caso, se ci riesco le spengo proprio, in una prossima versione…

Tutte le coordinate, sia di MRO che delle varie sonde in arrivo, sono relative al centro di Marte. Dev’essere per questo che MRO appare sempre fermo sulla stessa orbita.

I dati vengono direttamente da NASA Horizons, e volendo potete vederli anche qui in altra forma (tranne MRO, perchè quest’altra pagina era pensata per seguire il viaggio, non l’arrivo):

MARS 2020 around Mars
Hope around Mars
Tianwen-1 around Mars

A proposito dell’arrivo, vorrei aggiornare questa mia vecchia pagina su Insight usando invece i dati di MSL (così come quella di Insight usava quelli di Phoenix), ma non riesco a trovare tutte le telemetrie per tutta la durata dell’EDL, le trovo solo già graficate e parziali, mentre a me ovviamente servirebbero numeriche/testuali e total, e non riesco a estrarle dal sistema SPICE, se qualcuno ha suggerimenti…

Sennò mi tocca tirare fuori i dati a mano da questi documenti!
http://www.ssdl.gatech.edu/sites/default/files/ssdl-files/papers/conferencePapers/AIAA-2014-0385.pdf

11 Mi Piace

Ho trovato un modo per tirare fuori da SPICE i dati di EDL dall’Entry Interface (tempo di bordo 397501714.953130 , che corrisponde (indicando come -76 lo Spacecraft Clock Id) a 2012-08-06 05:10:59.317018 UTC , fino al flyaway dello scycrane. I tempi risultanti sono un po’ diversi da quelli della tabella che ho messo sopra, che avevo ricavato mettendo insieme 5 o 6 documenti diversi, ognuno che dice una cosa diversa…

Ho suato questo sito:
https://wgc.jpl.nasa.gov:8443/webgeocalc/#StateVector

Con questi input:


image
(nota: ho usato uno step di 0.1 secondi solo per gli ultimi 20 secondi)

Kernel usati:
image

Alla fine ho ottenuto questi dati:

Adesso vedo di metterli nel simulatore, per “fare finta” che siano gli stessi di Mars 2020.

Edit:
Aggiungo i grafici relativi al rilascio del rover; purtroppo dopo le 05:18 non trovo nessun dato per la skycrane (in teoria MSL_DIMU_A, cioè la IMU di bordo, o forse ha un altro codice, chissà; nemmeno MSL_DESCENT_STAGE funziona).

6 Mi Piace

Sembra che stavolta forse potrò risparmiarmi la fatica di scrivermi da solo il simulatore di EDL, la NASA si è modernizzata :slight_smile:

Certo un paio di lancette analogiche potevano mettercele…

6 Mi Piace

chissà se una videoricostruzione così l’hanno fatta anche per MSL…

3 Mi Piace

Qualcuno riesce a capire come ottenere dal sito “testuale” di Webgeocalc questi dati?

  • roll
  • pitch
  • yaw
  • sideslip angle
  • bank angle
  • angle of attack
  • azimuth

Pensavo di esserci riuscito, ma quando metto i dati nel simulatore, la capsula assume posizioni assurde…

Tra l’altro pare anche che in un’altra notazione yaw, pitch e roll vengano invece chiamati heading, elevation e bank, quindi non ci sto capendo più niente…

Questi sono gli assi di riferimento della capsula:
image

E questi quelli di un normale velivolo:
immagine

ALFA = Angle of attack?
BETA = Sideslip Angle

Ho dovuto rileggere 6 volte la spiegazione su wikipedia… e alla fine riscriverla, perchè senza figure non si capiva niente, ma alla fine ho capito. In pratica c’è questa corrispondenza fra le trasformazioni fra tre diversi sistemi di riferimento: Bordo - Terra / Vento - Bordo / Bordo - vento

  • Yaw / Heading / Sideslip (Z axis, vertical)
  • Pitch / Flight path / Attack angle (Y axis, wing)
  • Roll / Bank / nothing (X axis, nose)

Cioè in tutti e tre i casi si tratta di rotazioni intorno all’asse Z, Y e X (in quest’ordine), ma cambiano nome a seconda se la rotazione è per passare da:

  • Terra a Bordo
  • Terra a Vento
  • Bordo a Vento

“Vento” nel senso che la direzione dell’aria rispetto al velivolo non è necessariamente parallela all’asse di simmetria dello stesso.

Gli assi del sistema-Terra hanno questa direzione:

  • X= Nord (roll)
  • Y = Est (pitch)
  • Z = Basso (yaw)

Con Webgeocalc si possono specificare i due sistemi di riferimento, ma non credo che si possa specificare quello del vento, quindi Sideslip e Attack angle probabilmente vanno ricavati tramite diabolici calcoli che non saprei… Però si può ovviamente specificare il sistema di riferimento del pianeta (IAU_MARS) e del velicolo (MSL_DESCENT_STAGE), quindi dal sistema si possono ricavare solo Yaw, Pitch e Roll.

Gli input per Webgeocalc sono differenti tra forma grafica e forma testuale:

image
(direi che c’è un errore, dovrebbero essere tre assi differenti)

In forma testuale ci sono 4 modi diversi di richiedere i dati, ma due mi sembrano identici:

La “convenzione standard”, stando a Wikipedia, è ZYX, quindi sarebbe “giusto” il metodo 1: anche se apparentemente i 3 assi sono al contrario, nella risposta vengono re-invertiti, quindi alla fine Yaw, Pitch e Roll dovrebbero trovarsi negli elementi 1, 2 e 3 dell’array “rows” risultante, perchè l’array “columns” contiene questo:

image

Quindi in conclusione, in teoria la faccenda potrebbe essere questa:

Input per questa pagina:

{
"kernels": [
 {
  "type": "KERNEL",
  "path": "pds/wgc/mk/latest_lsk_v0004.tm"
},

{
  "type": "KERNEL",
  "path": "pds/data/msl-m-spice-6-v1.0/mslsp_1000/extras/mk/msl_v25.tm"
}
],

  "timeSystem": "UTC",
  "timeFormat": "CALENDAR",
     "intervals": [
       {
         "startTime": "2012-08-06T05:10:00",
         "endTime":   "2012-08-06T05:19:00"
       }
     ],
  "timeStep": 1,
  "timeStepUnits": "SECONDS",


      "calculationType": "FRAME_TRANSFORMATION",
      "frame1": "MSL_DESCENT_STAGE",
      "frame2": "IAU_MARS",
      "aberrationCorrection": "NONE",
      "timeLocation": "IAU_MARS",
      "orientationRepresentation": "EULER_ANGLES",
      "axis1": "X",
      "axis2": "Y",
      "axis3": "Z",
      "angularUnits": "deg",
      "angularVelocityRepresentation": "VECTOR_IN_FRAME2",
      "angularVelocityUnits": "deg/s"
    }

Interpretazione output:

  • Yaw = result.rows[rowIndex][1]
  • Pitch= result.rows[rowIndex][2]
  • Roll= result.rows[rowIndex][3]

Restano però ancora i problemi che google earth per gli oggetti non usa Yaw, Pitch e Roll, ma Heading, Tilt e Roll, che non so in che direzioni mette +X, +Y e +Z, e che non so ancora in che direzione sono gli assi in IAU_MARS…

Per Google Earth ho trovato quest’immagine relativa all’oggetto “geometry”:


Con questa spiegazione:

The Orientation element specifies rotations of the model around the x (tilt), y (roll) and z (heading) axes. The y axis points North and is parallel to longitude lines, and the x axis points East and is parallel to latitude lines. Rotations are specified in degrees, with positive rotations as shown in the following diagram.

Cioè:
X = Est (tilt)
Y = Nord (roll)
Z = Alto (heading)

Invece Wikpedia dice:
X= Nord (roll)
Y = Est (pitch)
Z = Basso (yaw)

Cioè pitch e roll sono scambiati tra loto, e l’heading ha segno opposto…

Un vero macello.

3 Mi Piace

Forse ho trovato: per Yaw/Pitch/Roll non devo usare IAU_MARS, che è centrato al centro del pianeta e ha XY parallelo all’equatore:

image

Devo invece usare MARS_TOPO, che è centrato sulla superficie, per l’esattezza sul sito di atterraggio:

MSL Topocentric Frame

MSL topocentric frame, MSL_TOPO, is defined as follows:

  -- +Z axis is along the outward normal at the landing site ("zenith");

  -- +X axis is along the local north direction ("north");

  -- +Y axis completes the right hand frame ("west");

  -- the origin of this frame is located at the landing site.

Però ha gli assi messi in un altro modo ancora…

  • z = alto
  • x = nord
  • y = ovest

E’ un vero disastro; praticamente la situazione è questa, ma non so come uscirne:

5 Mi Piace

Primo file sperimentale per confrontare le traiettorie di EDL di varie missioni oltre a MSL:
http://win98.altervista.org/space/exploration/EDL/Mars%20EDL.kmz (warning: è un file apparentemente leggero ma contiene parecchi dati e può bloccare google earth su PC poco potenti)

Pagina di spiegazioni:
http://win98.altervista.org/space/exploration/EDL/index.html

2 Mi Piace

Finalmente completata la pagina per seguire in tempo reale la “corsa a Marte 2021”:
http://win98.altervista.org/space/exploration/3d/marsrace.html

Miglioramenti apportati:

  • eliminati pulsanti e controlli vari temporanei di debug

  • aggiunte linee delle traiettorie future

  • aggiunta possibilità di ritentare lo scaricamento dei dati in caso di errore

  • Purtroppo non sono riuscito a implementare la longitudine, dovrei usare proprio usare una sorgente di dati diversa, quindi la superficie del pianeta continua a non fare testo, cioè le traiettorie non intersecano/sorvolano Marte nei punti di atterraggio/flyby, è giusta solo la distanza e la latitudine.

La prima a tagliare il traguardo sarà Hope, seguita a ruota da Tianwen e da Mars2020:

8 Mi Piace