Antares 3.0 [sviluppo]

Sto facendo dei timidi passi avanti, è tutta una questione di vettori Vedo come va oggi sennò chiedo aiuto!

Nulla da fare, tutto questo implica delle conoscenze in matematica che io non ho.. esiste su OF una discussione su come si dovrebbe fare a implementare una cosa del genere:

http://orbiter-forum.com/showthread.php?t=23368&highlight=vessel+rotation

ma sembra che i codici proposti siano parziali o semplificati, e comunque non funzionano... magari qualcuno di voi riesce ad illuminarmi.. intanto do un'occhiata ai codici sorgente di attitudeMFD...

Per trovare il vettore ti helpo volentieri

Per gli RCS sarà una noia, partiamo dal vettore

Provo un po' improvvisando perché sono in ufficio
Secondo me devi trovare un vettore in coordinate globali che punti da Antares alla terra, poi trovarne il versore (operazione unit sul vettore) e poi orientare Antares in modo che il suo vettore (0,0,1) sia parallelo al vettore trovato in precedenza.

quindi io farei così:

Codice:

OBJHANDLE hearth=oapiGetObjectByName("Earth");
OBJHANDLE hantares=GetHandle();
VECTOR3 relativepos;
oapiGetRelativePos(hearth,hantares,&relativepos);
relativepos=unit(relativepos);

e a questo punto dovremmo avere il versore da antares alla terra

poi calcoliamo l'assetto attuale di antares con

Codice:

VECTOR3 z=_V(0,0,1);
VECTOR3 zglob;
GlobalRot(z,&zglob);

e quindi nella stringa di debug puoi guardare i due vettori e vedere se tornano, cioè se quando punti la navetta verso la terra i numeri diventano uguali tra loro.

non ho idea se sia giusto o meno, l'ho fatto in 2 minuti senza provarlo, quindi ci saranno mille errori e non garantisco! ma magari ti può essere d'aiuto! nel weekend ci do un'occhiata più approfonditamente!

Il vettore di coordinate che punta verso la Terra l'ho trovato, e quello è già fieno in cascina. il problema è il resto continuerò la battaglia in trincea in attesa di rinforzi, chissà se mi riuscirà di guadagnare qualche posizione

Capisco e appoggio la voglia di trovare la soluzione da sè, ma secondo me (parlando da ex-programmatore scarso) il segreto è tutto nel sorgente di Attitude MFD.
Così, giusto per non "reinventare la ruota", come dicono gli anglofoni.
E a proposito di modi di dire, carino il "fieno in cascina"!

Ripley ha scritto:

Capisco e appoggio la voglia di trovare la soluzione da sè, ma secondo me (parlando da ex-programmatore scarso) il segreto è tutto nel sorgente di Attitude MFD.
Così, giusto per non "reinventare la ruota", come dicono gli anglofoni.
E a proposito di modi di dire, carino il "fieno in cascina"!

Si è vero ma non mi ero minimamente accorto che il codice sorgente era disponibile! Adesso lo studierò da cima a fondo!

Quel modo di dire è diffusissimo dalle mie parti, forse a causa della vocazione al risparmio che vige in Brianza Credevo comunque che fosse nazionalmente diffuso

A proposito di "caccia ai vettori", questo te l'ho già segnalato?
http://www.orbithangar.com/searchid.php?ID=3429

Grazie, utile tool!
Credo però di essere vicino alla soluzione del problema, intanto sempre grazie a Fred ho sarà aggiunta la carica della batteria sincronizzata con l'esposizione solare e il blocco del suntracking in zona di ombra

Allora, c'è una cosa che non capisco, chissà se qualcuno può aiutarmi..

Ho questa formula:

RadialVel = (RelPos * RelVel) / Mag(RelPos);

Premetto che RelPos e RelVel sono vettori, mentre RadialVel è una variabile double. Mag invece è una funzione che calcola la magnitudine di un vettore.

Non mi permette di fare il prodotto (RelPos*RelVel) con la motivazione che "nessun operatore * è corrispondente agli operandi". Però la medesima operazione nel progetto di AttitudeMFD è assolutamente consentita.. qualcuno ha un'idea del motivo?

tra due vettori si può fare prodotto scalare (dotp) il cui risultato è un numero, e prodotto vettoriale (crossp) il cui risultato è un vettore. oppure si possono moltiplicare i vettori per una componente scalare con l'operatore "operator*=" ma non si può fare il semplice *

se radial vel è un double allora il numeratore dovrebbe essere un prodotto scalare:

dotp(RelPos,RelVel)/Mag(RelPos);

Non sono però sicuro che qualcosa che si chiama "RadialVel" sia un double, controlla bene che non sia un vettore, altrimenti è crossp e non dotp!

Ho provato a chiedere su OF delucidazioni..

http://orbiter-forum.com/showthread.php?t=30719

ci ho dato un'occhiata, e ci avevo guardato anche a suo tempo. Il codice di AttitudeMFD non è molto user friendly secondo me. E' fatto molto molto bene, ma per cercare di capirci qualcosa c'è da perderci un sacco di tempo. Poi probabilmente il fatto che moltissime cose del c++ ancora mi siano oscure di certo non aiuta.

Secondo me la cosa migliore per impostare l'earth tracking è:

- trovare il sistema per determinare una coppia di vettori, uno che punti dal veicolo alla terra e l'altro perpendicolare ad esso che punti ad esempio verso il nord terrestre

- determinare per tentativi dei valori di velocità angolare e "deadband" (cioè punti in cui non serve che il sistema intervenga) appropriati per antares (questa è la cosa più facile in assoluto)

- scrivere i comandi che azionano l'RCS.

Per l'ultimo punto ho già fatto pratica con l'azionamento dell'autoguida dell'ELIS. Per il primo c'è da ragionarci un po' su, io stavo pensando di mettere nel codice dei TDRS che ha fatto Vittorio la caratteristica che il satellite sia sempre puntato verso la terra, vediamo se mi riesce e a quel punto si può sfruttare per Antares 3.0

Soluzione postata da Hlynkacg:

http://orbiter-forum.com/showthread.php?p=411512&postcount=3

...che punta qua:
http://www.orbiter-forum.com/showthread.php?t=27280

L'orbinauta di OF Hlynkacg mi segnala gentilmente questo thread, in cui mi spiega, a quanto ho capito, come risolvere il primo punto citato da Fred nel precedente post:

http://www.orbiter-forum.com/showthread.php?t=27280

Ci darò subito un'occhiata!!

Ora il risultato è soddisfacente: gli RCS si accendono e trovano una precisa posizione.. che tuttavia è ancora sbagliata.
Questo perché l'autopilota mi cerca il vettore prograde, normal o antinormal che non punta verso l'obiettivo ma è rotato di 90 gradi rispetto al centro del target.
Come trovare il vettore che punta con l'asse Z direttamente verso il nostro pianeta?

Fausto, ci sto lavorando in diretta... ti passo una funzione che funziona, ma punta verso la terra impostando la velocità angolare manualmente invece di utilizzare gli RCS, provala un secondo, io intanto vedo se riesco a farti una funzioncina che attivi gli rcs nel modo corretto, anche se poi sarà da ottimizzare per consumi etc.

Va in postStep (hearth magari mettilo fuori a prescindere, ma è il meno)

Codice:

   OBJHANDLE hearth=oapiGetObjectByName("Earth");
    VECTOR3 rpos;
 oapiGetGlobalPos(hearth,&rpos);
 VECTOR3 gdir;
 Global2Local(rpos,gdir);
 gdir=unit(gdir);
 
 VECTOR3 angularvel1;
 
if(abs(gdir.x)>0.003){
    angularvel1=_V(0,0,-gdir.x);
 } else{
    angularvel1=_V((1-gdir.z)*gdir.y/abs(gdir.y),0,0);}
 SetAngularVel(angularvel1);

Si Fred funziona!
Ho provato a usare la funzione OrientForBurn(gdir) suggerita su OF ma il risultato è sempre un'orientamento sbagliato di 90 gradi, quindi sussiste qualche altro problema..

il fatto è che su OF ne sanno sicuramente un sacco di tutto ma io poi mi perdo e preferisco rimanere a fare le cose semplici partendo da un disegno su un pezzo di carta

Comunque questa funzione OrientForBurn detta così sembra molto utile, non l'ho mai sentita! hai provato a togliere qualche 0.5*PI da qualche parte?

tra poco comunque spero di mandarti la funzioncina che controlla gli rcs, poi andrà tarata coi valori adatti per Antares

Va bene mi affido a te, io non ho più idee!

Non c'è nessun 0.5*PI perché tutto è fatto in gradi, comunque sembra che in ogni modo la si giri la funzione OrientForBurn ti cerca si un bersaglio e lo mantiene ma l'orientamento è sempre sbagliato di 90 gradi, praticamente ad essere direzionato verso l'obiettivo è l'asse Y..

Ciao Fausto,

in teoria la funzione che attiva gli RCS e che orienta l'Antares l'avrei fatta, però è bella "grezza" , bisognerebbe sviluppare un controllore PID o una cosa fatta un po' meglio per un addon raffinato come Antares.

Così ho fatto una cosa: ho dato un'occhiata alla Orient For Burn che dicevamo ieri sera e mi sono accorto quale sia il problema:

all'interno della definizione di OrientForBurn c'è:

Codice:

VECTOR3 ThrustVector = {0,1,0};

ma per Antares il ThrustVector è (0,0,1)!

così l'ho camabiato in 0,0,1 e ho fatto OrientForBurn(gdir) e funziona perfettamente

Tra l'altro a questo punto la OrientForBurn è bella comoda!

Fammi sapere se anche a te funziona, così anche il capitolo Earth Tracking è archiviato

Beh ma allora questa è musica per le mie orecchie
Appena ho le mani sul mio pc principale lo provo subito!

annuntio vobis gaudium magnum,
habemus earth tracking!!
Ecco un'immagine:



Ho il sun tracking attivato, naturalmente l'earth tracking e ho aperto anche il plugin di Fred in cui abbiamo agganciato il DSN. Da notare il lag di 158 secondi nella trasmissione!

Ottimo lavoro! Grazie a Fred per l'aiuto prezioso!

Grandissimo lavoro, complimenti a tutti!

Aggiunta anche la luce di docking!

Per Vittorio: avrei bisogno anche delle textures delle luci di posizione sulla della capsula. Dove le mettiamo? E di che colore? Io direi gialle sopra i getti RCS dietro le finestre anteriori (e simmetricamente anche dalla parte opposta):



Che ne dite?

Mi piacerebbe sapere come fare a calcolare in base all'estensione dei pannelli solari quanto ci mette la batteria a caricarsi e quanto a scaricarsi completamente su un mezzo come Antares. Non so se qualcuno di voi ha un idea dove trovare un documento che lo spiega o almeno un metro di misura realistico..