36 lines
3.8 KiB
Markdown
36 lines
3.8 KiB
Markdown
# ToDo List
|
|
|
|
- [x] Inserire dati di navigazione dell'ownship nel file di salvataggio della simulazione
|
|
- [x] muovere il ppi in base al movimento dell'ownship
|
|
- [x] Aggiungere tabella dei dati cinematici dell'ownship nella schermata della simulazione
|
|
- [ ] Mettere nel file di comando inviato al srver l'ultimo timetag che è arrivato dal server
|
|
- [ ] Implementare il comando ping con numero indentificativo per verificare i tempi di risposta
|
|
- [ ] Mettere configurazione cifre decimali inviate nei json al server
|
|
- [ ] Se lat/lon passato dal server non è valido posso fare come fa mcs, integrare sul tempo e simulare il movimente dell'ownship
|
|
- [x] poter scegliere se visualizzare la mappa ppi fissa a nord o fissa con l'heading dell'ownship
|
|
- [x] salvare nei file delle simulazione i dati in lat/lon dei target così da poter piazzare su mappa oepnstreetmap le traiettorie e vedere come si è mosso lo scenario durante la simulazione
|
|
- [ ] vedere anche la simulazione in 3d usando le mappe dem e le mappe operstreetmap.
|
|
- [ ] Scrivere test unitari
|
|
- [ ] creare repository su git aziendale, usando codice PJ40906 come progetto
|
|
- [ ] aprire l'analisi direttamente cliccando sulla riga della tabella
|
|
- [ ] creare una procedura di allineamento tra server e client usando il comando di ping da implementare anche sul server
|
|
|
|
- [ ] funzione di sincronizzazione: è stato aggiunto al server la possibilità di gestire dei messaggi che sono di tipo SY (tag) che sono fatti per gestire il sincronismo tra client e server. In questa nuova tipologia di messaggi io invio un mio timetag che poi il server mi restituirà subito appena lo riceve, facendo così sappiamo in quanto tempo il messaggio che spedisco è arrivato al server, viene letto, e viene risposto il mio numero con anche il timetag del server. Facendo così misurando i delta posso scroprire esattamente il tempo che intercorre tra inviare un messaggio al server e ricevere una risposta. Per come è fatto il server il tempo di applicazione dei nuovi valori per i target sarà al massimo di 1 batch, che può essere variabile, ma a quel punto lo potremmo calibrare in altro modo. Con l'analisi sui sync possiamo sapere come allineare gli orologi.
|
|
|
|
- [x] Aggiungere un tasto per duplicare uno scenario da uno già presente e dargli un nome diverso
|
|
- [ ] aggiungere una funzione automatica durante il salvataggio dello scenario che cancelli quelli più vecchi di 10 salvataggi fa, per evitare che aumentino in numero senza controllo
|
|
|
|
- [ ] Aggiungere comunicazione con simulatore mathlab. Invece di mandare informazioni al server devo salvare in locale in una cartella un file csv con dentro le informazioni dei target da simulare.
|
|
<timetag>_<nome_scenario>.csv
|
|
|
|
|
|
|
|
|
|
# FIXME List
|
|
|
|
- [ ] sistemare la visualizzazione nella tabe simulator, per poter vedere quale scenario è stato selezionato
|
|
- [x] sistemare l'animazione della antenna che adesso non si muove più
|
|
- [ ] rivedere la visualizzazione della combobox per scegliere lo scenario da usare.
|
|
- [ ] quando è finita la simulazione i target nella tabella si devono fermare all'ultima posizione scambiata.
|
|
- [ ] quando la traiettoria si ferma deve comparire la x gialla e non deve sparire a fine simulazione
|
|
- [ ] IMPORTANTE: verificare la rotazione dei target quando durante la simulazione ruota l'aereo, in questo caso se ruota l'aereo ed i target sono parttiti con un certo angolo rispetto allo 0, poi la traiettoria dei target deve essere aggiornata rispetto al momento iniziale e non calcolata ad ogni step di rotazione. Al momento dello start, devo memorizzare l'angolo di rotazione dell'aereo e quindi quello è l'angolo con cui dovranno essere aggiornate sempre le traiettorie dei target e non quella corrente dell'aereo che potrà girare dove vuole ma a quel punto le tracce sono partite e quindi seguiranno la loro strada. |