OSD per ROV

Apro questo post per proseguire una discussione iniziata in spam bar, in modo che il tutto rimanga un po piu unito e comprensibile per quelli a cui puo interessare.

Come gia avevo postato in spam bar, lo scopo di questo progetto e' quello di poter aggiungere ad un segnale video (in questo caso, proveniente da un ROV), delle scritte che mi rimandino in superfice alcune informazioni, il tutto per un ROV che in origine non aveva questa possibilita' (o meglio, ha solo alcuni dei dati, e la sovrapposizione e' realizzata con un vecchio PIC il cui firmware e' protetto, ed il cui programmatore e' ignoto, e dalla scheda originale non e' possibile aggiungere altro).

La parte hardware e' relativamente semplice ed e' basata sul chip per video overlay MAX7456, pilotato da un 328 (piu o meno, la stessa configurazione usata anche nei vari minimOSD ed ArduCAM del vecchio ardupilot, da cui ho preso l'idea, modificata con l'aggiunta di ingressi extra in modo da sfruttare il piu possibile il 328) ... la sagoma della scheda e' strana perche' realizzata in modo da potersi impilare insieme a tutte le altre del ROV (il contenitore principale dell'elettronica e' un tubo in acciaio inox, in cui le schede sono impilate e fissate con due barre filettate, come nella maggior parte dei ROV commerciali), non so se servira' a qualcuno, comunque in allegato ci sono i files Eagle (se qualcuno ci trova errori, ditemelo per favore) ... appena riesco a finirla, iniziero' a fare alcune prove pratiche, comunque voglio nel frattempo portarmi avanti anche con la parte incasinata (software :P)

Come ultima modifica allo schema, ho portato fuori tutti i pin che sono riuscito a posizionare, in modo da averli a disposizione, quindi al momento la scheda dispone di 5 ingressi digitali e 3 analogici (protetti) liberi, un'ingresso extra per il blanking delle scritte (per attivare o disattivare la sovrapposizione delle scritte tramite un comando dalla superfice), piu un'altro pin insieme ai contatti alimentazione, TX ed RX sul connettore a cui andra' collegata la bussola (che realizzero' in RS485 con MPU6050 e HMC5883L gestiti da un secondo 328, come suggerito da Astro, che di queste cose se ne intende molto piu di me) ... purtroppo, non ci stava proprio la macchinetta per il caffe', mancavano un paio di millimetri :stuck_out_tongue:

E veniamo alla parte che mi crea davvero una marea di problemi, il software ... in origine volevo sfruttare il software di minimOSD, per semplicita', modificandolo in modo che mi rimandasse sul video i dati che servoono a me, che non provengono da un bus di volo, ma da sensori fisici, come bussola, profondimetro, temperature interna ed esterna, livello di tensione dalla superfice (da un'interfaccia a parte che legge l'alternata di potenza, che puo arrivare anche a 280V circa), piu alcuni allarmi (segnali on/off) ... ma mi sono reso conto del pietoso livello di impreparazione che possiedo, perche' studiando i files del minimOSD, ci ho capito un decimo scarso di come funziona, e pure quel decimo a fatica.

Il software originale del minimOSD sembra diviso in diversi moduli, richiamati da un main, probabilmente per comodita' di modifica ... mi e' stato suggerito, molto ottimisticamente (Astro, grazie, ma mi sopravvaluti in fatto di programmazione ;)), di riscriverlo da zero ... In effetti, il minimOSD originale e' piuttosto ben fatto, ma estremamente specifico per il volo, mentre per la mia applicazione, i dati di volo non c'entrano nulla, ed anche il posizionamento delle scritte e della bussola dovrebbe essere totalmente diverso ... inoltre essendo per applicazione subacquea, la velocita' che di solito e' necessaria per i modelli volanti (per evitare che si schiantino :P) a me non serve (considerate che in media i ROV, anche i piu professionali e costosi, aggiornano i dati inviati alla superfice al massimo 4 o 5 volte al secondo, e gia questa e' un'ottima velocita', per un'oggetto che se ne sta a fluttuare sott'acqua in assetto neutro :stuck_out_tongue: :D) ... quindi non so, magari rifare tutto da zero alla fine sarebbe piu semplice ... intanto la libreria per il MAX l'ho scaricata e sto cercando di studiarmela, insieme al datasheet, poi appena smette di uscirmi fumo dalle orecchie, vedremo ...

Un'altra cosa, che probabilmente semplificherebbe ulteriormente il lavoro ... a me tutti i 256 caratteri della tabella interna del MAX7456 non servono a nulla, mi servono solo lettere, numeri, e qualche simbolo, e studiando il datasheet ho visto che gia quelli che ci sono di default nel MAX potrebbero essere utilizzati (in pratica, l'unica componente "grafica" sarebbe il cursore della bussola, non indispensabile dato che i gradi li stamperei anche in formato numerico, ma sempre utile per vedere al volo dove e' diretta ... tutto il resto sono valori numerici e/o scritte) ... quindi, se e' possibile modificare solo alcuni dei caratteri della tabella interna, potrei ridisegnare qualche simbolo, altrimenti sfrutto quello che c'e' gia di fabbrica e amen, che vanno bene pure quelli ... poi verra' la parte "divertente" cioe' impazzire per scrivere il firmware :stuck_out_tongue: :smiley: ... In ogni caso, come informazione preliminare, cosa sarebbe piu funzionale, scrivere un singolo firmware che contiene tutto, o suddividere il tutto in diversi moduli come avevano fatto in origine gli ideatori dell'originale minimOSD ?

Astro: con la realizzazione pratica del tuo modulo bussola, hai dovuto per forza mettere gli stampati affiancati come nelle foto di quel post, oppure funzionerebbero lo stesso se fossero sovrapposti ? ... perche' se metterli sovrapposti non crea problemi, faccio uno stampatino per un 328 standalone in TQFP, cosi poi riesco ad inserirli in un contenitore stagno cilindrico piu stretto (data la pressione che dovra' sopportare, piu e' ridotta la superfice, meglio e' ) ... Inoltre, il tuo firmware richiede connessioni a pin particolari ? ... se si, quali ?

test-overlay.zip (234 KB)

x iscrizione

astrobeed:
Nessun problema, anche perché vista la lunghezza massima dei cavi si può far lavorare la 485 molto più veloce dei classici 115200 bps, nel tuo caso non serve visto che aggiornare l'OSD più di 10 volte al secondo è inutile.
Perché non prendi in considerazione di mettere la telemetria su un display LCD, magari grafico, sulla console di comando invece del OSD, molti meno problemi e in caso di perdita del segnale video, o cattiva ricezione dello stesso, ce l'hai sempre visto che viaggerebbe tramite RS485.

Il problema e' che il link con il 485 arriva solo fin dentro il bussolotto dell'elettronica principale, ma da li alla superfice c'e' solo un cavo schermato RG ... e su quel cavo passano gia due portanti (10 ed 11 MHZ) con i comandi dalla centralina al ROV, una portante video a circa 60MHz dal ROV alla superfice, e l'alimentazione dalla superfice, circa 280VAC ... sovrapporci qualsiasi altra cosa fin'ora si e' rivelato impossibile, per quello ho pensato all'OSD (ho provato alcune soluzioni, per aggiungere altri segnali sul cavo, ma fin'ora non mi e' riuscito nulla di decente)

Quindi il cavo funziona come una powerline? Alimentazione + segnale comandi e video?

PaoloP:
Quindi il cavo funziona come una powerline? Alimentazione + segnale comandi e video?

Si, esatto ... tramite un (pesante ! :P) trasformatore elevatore da 25A (che fa anche da isolamento galvanico) manda al ROV circa 280V massimi (serve per compensare in parte la caduta sui 300 e passa metri di cavo), poi la centralina gli sovrappone due portanti (una a 10 ed una ad 11 MHZ), modulate da due registri a 16 bit (il che permette di inviare al massimo 2 comandi contemporaneamente, uno per mano, 32 comandi in tutto), in piu un trasmettitore TV per cavo rimanda dal ROV alla superfice una terza portante a circa 60MHz modulata in PAL, con il segnale video della telecamera (che si visualizza tramite un normale TV analogico) ...

Purtroppo quel sistema e' di un vecchio modello, e gia farlo funzionare cosi a volte e' da piangere (non ti dico il casino che c'e' voluto ad aggiungere un commutatore video a 4 canali, per poter scegliere piu di una camera) ... ci ho provato in parecchi modi, ma non sono riuscito ad aggiungere nessun'altra portante, o vanno in conflitto, o cancellano i comandi, o non arrivano a terra ... l'unica alternativa a quel punto era sperare di poter sostituire l'OSD originale, che e' "chiuso" e non modificabile (invia solo profondimetro e velocita' impostata dei motori, nient'altro, la bussola e' una bussola "fisica" tenuta da un braccetto in modo da essere inquadrata dalla telecamera :P) con una scheda mia, dove potessi inserirci un po piu dati ...

Etemenanki:

Astro: con la realizzazione pratica del tuo modulo bussola, hai dovuto per forza mettere gli stampati affiancati come nelle foto di quel post, oppure funzionerebbero lo stesso se fossero sovrapposti ? ...

Premesso che ho usato roba che avevo nel cassetto, in pratica un Arduino Pro mini 5V, una breakout con l'MPU6050 e una con il HMC5883L, non c'è nessun problema nel montare tutto impilato, però ho qualche dubbio sul fatto che il magnetometro riesce a funzionare, previa calibrazione, correttamente all'interno di un cilindro in acciaio, è da verificare.

astrobeed:
... all'interno di un cilindro in acciaio ...

No, no, mi sono spiegato male io ... il contenitore della bussola deve per forza essere un cilindretto separato, per il fatto di doverlo piazzare in un punto in cui non venga influenzato dalle masse dei motori (o almeno, in cui l'influenza sia la minore possibile, per quello poi avra' un cavo di un paio di metri), e dovremo farlo realizzare apposta (ancora non so in che materiale, derlin, dralon, nylon, quellochetroviamodiabbastanzarobustoechecostapoco :P) ... il fatto di poterli montare impilati, realizzando uno stampato apposta per il 328 standalone in TQFP (una cosa tipo lilypad, anzi, se potesse funzionare, potrei addirittura usare una lilypad e risparmiarmi di realizzare lo stampato), mi permetterebbe di disegnargli un contenitore il piu piccolo possibile, minimizzando i problemi di resistenza alla pressione (o almeno di provarci)

Forse il FLORA è più piccolo del Lilypad ma va a 3.3V e monta l'ATmega32U4 (qui).

Non mi serve microscopico, solo piu "rotondo" delle schede normali ... il lilypad, se utilizzabile, ha gia i pin TX ed RX sui pad, va a 5V, e lo posso pure modificare se serve, altrimenti butto giu una schedina su misura e ci saldo un vecchio 328P che dovrei avere ancora in giro, uno per l'altro per me e' lo stesso ... :wink:

Domanda: il MAX7456 scalda realmente cosi tanto ?

Stavo cercando informazioni su alcuni siti, e sono "inciampato" in alcuni post di altri utenti che lamentavano guasti e bruciature dei modulini di Sparkfun che montano il MAX7456, per scarsa dissipazione e surriscaldamento ... se cosi fosse, mi converrebbe modificare lo stampato principale e realizzarmi a parte una specie di "breakout board" su misura, prima di tutto perche' se l'integrato si brucia una volta saldato sulla scheda grande, e' un macello a rimuoverlo per sostituirlo, e poi perche' in questo modo, potrei sia ampliare che moltiplicare la superfice di dissipazione, e come terza cosa, anche se non so che utilita' potrebbe avere, la breakout potrei realizzarla in passo standard 2.54, con la parte dei componenti indispensabili gia montati sopra, in modo da poterla usare anche con le breadboard o come componente a se ... pareri ?

Etemenanki:
Domanda: il MAX7456 scalda realmente cosi tanto ?

Per scaldare scalda abbastanza, diciamo che la temperatura di lavoro è attorno ai 40°, però non è assolutamente vero che salta e che richiede chissà quale dissipazione assurda.
Il MAX7456 in condizioni gravose di impiego arriva a consumare un paio di Watt, circa 200 mA sul +5V, cosa che ovviamente produce calore.
Basta prevedere una striscia di rame sotto il MAX, su ambedue le faccie con vias per lo scambio termico, che ha la stessa superficie del IC, ovviamente ambedue connesse a GND con opportuni thermals, e saldare bene la placca metallica sotto il MAX al pcb, è il suo dissipatore termico.

Be', io mi ero messo a fare il routing della breakout, nel frattempo, male che vada lo alleghero' cosi se serve a qualcuno c'e' ...

A proposito, dato che devo acquistarli entrambi, per i modulini MPU6050 e HMC5883L, e dato che ho visto che ce n'e' una marea di modelli diversi, sai se ce ne sono di migliori (o comunque di quelli da evitare) o vanno bene uno per l'altro? ... pensavo di prenderli con il regolatore incorporato, per evitare un'altro regolatore a 3.3v ed alimentare tutto con il 5V, ma nessuno dei vari venditori che ho trovato dice nulla sul fatto che siano 5V tolerant come ingressi ed uscite, tu sai se lo sono ? ... anche i datasheet dei componenti non lo specificano (o meglio, quello della MPU6050 parla di "absolute maximum rating" che arriva a 6V, il che farebbe pensare che sia 5V tolerant, anche se non lo dice chiaramente, mentre il datasheet dell'HMC come absolute maximum mi indica 4.8V, il che farebbe pensare che NON sia 5V tolerant ... e' il caso di prevedere dei buffer/convertitori ? ... o di alimentare a 3.5V il tutto e piazzare i buffer verso la scheda dell'overlay ?)

Al posto della coppia MPU6050 + HMC5883L perchè non prendi una MPU9150, ha tutto integrato in un unico componente.
Qui il datasheet --> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/IMU/PS-MPU-9150A.pdf
A pag. 19 trovi i parametri elettrici.

EDIT:
Cambiando chip...
Ad esempio questa (http://www.robot-italy.com/it/adafruit-9-dof-accel-mag-gyro-temp-breakout-board-lsm9ds0.html) ha gyro, accelerometro e magnetometro e convertitore di livello già nel modulo.

Perche' pensavo di usare il sistema proposto da Astro, ma soprattutto perche' per me la difficolta' maggiore sta nello scriverci un firmware decente, ed Astro si era offerto di aiutarmi per quella configurazione ...

Volendo usare una singola scheda, ho gia da qualche parte in casa una schedina di queste qui, ad esempio (devo solo trovare dove l'ho seppellita, perche' l'avevo presa mesi fa', poi non ho piu avuto tempo di giocarci, ed ora sinceramente non mi lo ricordo piu dov'e' :P), che in uscita darebbe gia la direzione come numero compreso fra 0 e 3599 (oltre ai dati grezzi, se necessari), e quindi a livello firmware mi semplificherebbe la vita, ma non ne conosco molto il funzionamento ... la terro' come alternativa se non riesco a far funzionare l'altro sistema (sempre ammesso di ritrovarla :P)

Intanto, dato che ho finito la breakout, la allego, cosi se serve a qualcuno ce l'ha :wink:

Solita licenza del "fatene quello che volete", con l'opzione che se ci fate i milioni, voglio almeno una pizza :stuck_out_tongue: :smiley:

breakout-max7456.zip (76.1 KB)

breakout-max7456-brd.png

Etemenanki:
A proposito, dato che devo acquistarli entrambi, per i modulini MPU6050 e HMC5883L, e dato che ho visto che ce n'e' una marea di modelli diversi, sai se ce ne sono di migliori (o comunque di quelli da evitare) o vanno bene uno per l'altro? ... pensavo di prenderli con il regolatore incorporato, per evitare un'altro regolatore a 3.3v ed alimentare tutto con il 5V.

Come moduli prendi quelli di Sparkfun, sono ottimi e sei sicuro che i componenti montati sono originali e non dei cloni.
Sia l'MPU6050 che il HMC5883L devono lavorare a 3.3V, vale anche per la I2C, ti consiglio di prevedere un traslatore di livelli sulla I2C per convertire quella nativa a 5V del Atmega con quella a 3.3V dei sensori.
Per fare delle prove puoi tranquillamente disattivare le pullup del Atmega sulla I2C, la libreria le attiva di default, e mettere delle pullup esterne da 1.5K collegate al 3.3V, in questo modo funziona però non è molto affidabile perché lavori al limite delle specifiche, anzi sei leggermente fuori, per i livelli di tensione I2C sul lato Atmega.
In pratica con le pullup a 3.3V rischi facilmente che la I2C va in errore con rischio di blocco del bus se sono troppi.
Il mio codice non si blocca in caso di errore di lettura dal device, come fa la libreria wire di Arduino, però troppi errori consecutivi portano ad una condizione irrecuperabile con conseguente stop del bus, in tutti i casi il micro continua a lavorare senza entrare in un loop infinito come avviene con la wire.

PaoloP:
Al posto della coppia MPU6050 + HMC5883L perchè non prendi una MPU9150, ha tutto integrato in un unico componente.

La MPU9150 contiene un MPU6050 e un magnetometro, non mi ricordo quale, collegato sul bus I2C aux del MPU6050, però questo magnetometro ha caratteristiche inferiori al HMC5883L, in una applicazione dove l'uso primario è una bussola molto meglio usare l'HMC.
Da test fatti personalmente si arriva ad una precisione di +/- 0.5°, risoluzione 0.1°, per la bussola con compensazione tilt/roll di +/- 45°, oltre l'errore comincia ad aumentare sensibilmente.
Nota tecnica, quando sono stati rilasciati gli MPU6050 non si sapeva nulla del DMP interno, sopratutto non si sapeva come usarlo visto che tocca caricare sopra il relativo codice ogni volta che si alimenta il sensore, perché Invensense rilasciava queste informazioni solo agli sviluppatori accreditati, poi qualcuno ha caricato in rete il manuale del dmp e il relativo SDK e dopo qualche mese Invensense li ha resi disponibili per tutti.
Attualmente è possibile usare gli MPU6050 e il loro DMP anche con Arduino, il che scarica l'ATmega da tutti i complicati calcoli per la DCM(1) e/o l'EKF(2), ci pensa il DMP a farli, concentrandosi solo sull'uso dei dati assetto e non come ottenerli partendo da quelli raw, inutile dire che l'EKF su qualunque processore a otto bit è una utopia se si vuole eseguirlo in tempo reale. :slight_smile:

  1. DCM, Direct Cosine Matrix
  2. EKF, Extended Kalman Filter

astrobeed:
Come moduli prendi quelli di Sparkfun,

ARGH ... nel frattempo mi ero fatto prendere la mano, ed ho ordinato un paio di moduli al volo su ebay (da gaetano_f, solo perche' era in Italia e perche' montano gia il regolatore a 3.3V, spero non siano una ciofeca)

Come traslatori di livello, posso metterli indifferentemente o sulla schedina del 328 che andra' insieme alle due breakout (ed in questo caso alimenterei il 328 ed i moduli a 5V), oppure fra il 328 della bussola e quello dell'OSD (ed in questo caso arriverei con i 5V al bussolotto della bussola, ma alimenterei tutte le schedine della bussola, compreso il 328, con i 3.3V tramite un LDO) ... dato che devo farle entrambe da zero, metterli in un modo oppure nell'altro non mi causa particolari problemi, secondo te' quale sarebbe la soluzione migliore ?

EDIT: pensandoci, il 328 viaggia meglio a 5V, come velocita', giusto ?

E riguardo all'interfaccia RS485 ? ... meglio emulazione software, o meglio piazzarci un paio di SP3485 ?

astrobeed:
Attualmente è possibile usare gli MPU6050 e il loro DMP anche con Arduino, il che scarica l'ATmega da tutti i complicati calcoli per la DCM(1) e/o l'EKF(2), ci pensa il DMP a farli, concentrandosi solo sull'uso dei dati assetto e non come ottenerli partendo da quelli raw

C'è già una libreria che carica il codice e li usa?
Questa --> i2cdevlib/Arduino/MPU6050 at master · jrowberg/i2cdevlib · GitHub

Astro: una cosa, ho dimenticato di chiederti, cosi faccio anche il routing della MCU ... il tuo sketch, con i due modulini, usa dei pin particolari, o posso usare una connessione qualsiasi, a parte i pin TX - RX - SDA - SCL ? ... ad esempio, lo schema allegato, con il tuo sketch andrebbe bene ? (i mos sono per traslare i livelli fra le schedine a 3.3V e la MCU a 5V) ... perche' se va bene, dovrei riuscire a far stare tutto in un diametro di 35mm circa ...