gprs/umts

[elettro]

è possibile redirigere l'output della camera in una chiavetta internet o magari in un cellulare usato come modem? la velocità GPRS è un pò bassa, ma con l'UMTS dovrebbe essere più che sufficente (170kb/s), ovviamente la base deve possedere un collegamento internet almeno ISDN o un'altra chiavetta.
per pilotare invece pensavo di usare la classica tx 2.5ghz o magari addirittura una trasmittente USB tipo quelle dei simulatori che si trovano anche a 15€ (ma quì entra in gioco il PING(o LAG) e il ritardo provocato dai protocolli, TCP in particolare.
Il ping raramente supera i 200ms tra andata e ritorno tra due pc, credo che via GPRS al massimo si arrivi a 500ms(mezzo secondo) a cui bisogna sommare qualche maciata di ms per la gestione del protocollo dal microcontrollore, infatti pensavo per il video di usare l'UDP, che è mooolto più leggero, e non mi frega se qualche frame viene lasciato indietro ^^
per i comandi invece il TCP, ma il punto è: è fattibile? esiste un modo per collegarsi a una penna usb senza portare in volo un PC?
soluzioni on arduino particolarmente benvenute :-)

[pikappa]

Sbaglio o sul Forum di Arduino c'è qualcuno che pone lo stesso quesito ?

[elettro]

mava?, ma magari di qua conoscete qualcuno che l'ha gia fatto, anche usando sistemi diversi...
senza contare che non so ancora se l'UMTS è ok per l'FPV, anche se non vedo perchè non dovrebbe andare a parte il rischio caduta di seganle quando si passa da un'antenna all'altra

[merengue]

in generale direi di no.
In particolare, se usi una cam "classica" ovvero analogica, devi codificare il segnale in digitale a bordo dell'aereo (follia & inutile & provoca ritardo & ....)
e decodificare giù, il tutto.
"Redirigere l'input direttamente in una chiavetta", detto così non vuol dire niente, non si capisce dove vuoi far passare i dati. Direttamente non si può fare, passare attraverso la rete cellulare è follia (vedi parentesi sopra) sia per colpa della rete, che dei protocolli che degli apparati, tutti cose concepite non per dare una connessione continua e garantita quanto piuttosto un servizio discontinuo senza garanzia di ricezione questo perchè il protocollo IP è basato sul concetto di pacchetto, di routing e di best effort. Tutte cose che a te non servono e procurano solo peggioramento di ciò che vedi (video)
Insomma, c'è il sistema classico, vai con quello. Un canale tutto per te senza problemi di banda passante. Perchè complicarsi la vita?

[Guglio]

Sbaglio o sul Forum di Arduino c'è qualcuno che pone lo stesso quesito ?

Allora non era solo una mia impressione

Comunque secondo me è masochismo, io mi trovo spesso a usare la connessione UMTS e 3.5G della Vodafone e sono più le volte che non ha campo che quelle dove lo ha e quando ho tutte le tacche a volte bastano 4 metri per entrare nel cono d'ombra e passare da altissime velocità al fantastico 56k o connessione assente.

P.S. Se proprio vuoi farlo è meglio l'UDP perchè risparmi molto in dati non essendoci la conferma dell'arrivo del pacchetto (almeno a me l'hanno spiegato così)

[biv2533]

La soluzione della trasmissione digitale magari integrata o convivente sulla stessa banda dei 2,4Ghz insieme ai dati del radiocomando risolverebbe un sacco di problemi e garantirebbe maggior qualita' e sicurezza.

Il sistema richiesto presenta sulla carta notevoli svantaggi.

Prima di tutto sarebbe auspicabile gia' una codifica digitale da parte della cam, altrimenti e' necessaria una codifica analogica digitale, inoltre la banda passante UMTS non credo sia sufficiente per un flusso come minimo di una immagine di 640x480 ripetuta almeno 25 volte (circa) al secondo.

Se non avete voglia di fare i calcoli pensate solo al fatto del perche' le video chiamate con i telefonini non hanno una risoluzione di 640x480 ma sono poco piu' grandi di un francobollo il refresh dei frame avviene con protocolli di compressione solo sui piexel cambiate rispetto ai frames precedenti e di sicuro non 25 volte al secondo.

Altro piccolo problema, i 200ms aggiunti ai 500ms, piu' un pizzico di sale in piu' per ogni ospite, portano ritardi che nel pilotaggio di sicuro non aiutano.

Non siamo sicuramente ai livelli dei campioni di 3d di elicotteri o aerei acrobatici che notano differenze di tempo tra comando impartito e risposta del servo di qualche millisecondo, pero' aggiungi di qua' e aggiungi di la', e trovarsi a pilotare un mezzo che esegui le manovre con parecchio ritardo di sicuro non aiuta.


A livello di sperimentazione tuttavia e' sicuramente fattibile e anzi auspicabile he qualcuno si cimenti in qualcosa di nuovo.

@guglio
Cortesemente non riportare notizie o dati se non sai di cosa si sta' parlando.
UDP e TCP sono due dei tanti protocolli di trasmissione dati con caratteristiche differenti e non e' che uno sia meglio o peggio dell'altro, dipende dalla applicazione che li usa o dal supporto sul quale devono viaggiare.

[Ludo91]

tecnicamente è fattibilissimo, gli attuali protocolli usati dalle chiavette posso tranquillamente sostenere un flusso dati adatto a una cosa del genere, e un buon autopilota ocme ardupilot può tranquillametne farsi carico dell aereo in caso di caduta del segnale... il fatto che nessuno lo abbia ancora fatto non implica per nulla che sia impossibile. Il fatto è appunto trovare strumeti in grado di fare quel che vogliamo in un peso decente. Mettere a bordo un portatile con webcam e multiplexer per comandare i servi è fattibile senza troppe difficoltà tecniche, per chi ha una preparazione elttronica SERIA. Il fatto è che il pc pesa troppo, ma non credò sia difficile torvare alternative sufficientemente compatte, uno stesso iphone 3gs potrebbe tranquillametne fare lo "sporco lavoro"

[elettro]

lasciamo stare tcp e udp, diciamo che per il video è meglio l'udp per rosicare anche quei 130bit (circa 16 byte) di header

il GPRS si aggira ai 30/70kb/s, mentre l'UMTS si aggira ai 384 kb/s e 7.2 Mbit/s con dispositivi HSDPA. (fonte wikipedia)

{TEST TIME}
osservando i video fatti con il cellulare, a una risoluzione 176*144 occupano 500kb per 20 secondi circa, il che fà 25kb/s, e confermato da un video da 1 sec. al monitor bello colorato che pesa 33kb, il formato è 3gp(con audio) che divengono dai 16 ai 18 kb/s senza audio (varie prove), fattibile pure via GPRS!
{/TEST TIME}

a conti fatti i 640*480 occupano 3.5 volte tanto i 176*144, quindi con audio occupano 150kb/s, senza 70kb/s(limite del GPRS!), calcolati con la media peggiore (35kb/s con audio e 20kb/s senza, evviva l'arrotondamento in eccesso)

ultimo inghippo la LAG.. ovviamente i 500 ms sono già tutto copreso (anche del sale), comunque considerando che la piattaforma è autostabilizzante non dovrebbe precipitare anche se perde il segnale.
Normalmente il PING dovrebbe aggirarsi sui 100ms, vuol dire che l'immagine la vedi con 50ms di ritardo... che sale a 250 nel caso peggiore stimato(PING 500), ma lì è facile che perdi la comunicazione perchè in cono d'ombra.

@Guglio: ma da dove ti colleghi? non è che sei tra palazzi alti? o magari proprio al limite del campo dell'antenna? magari dentro casa? io la internet key non l'ho mai usata, sò che non è un buon affare ma fino a questo punto...
fammi un bel favore, quando sei collegato via chiavetta fai start->esegui->cmd oppure start->tutti i programmi->accessori->prompt dei comandi
ti si aprirà una shell (scritte bianche sfondo nero, il dos per chi lo conosce) e scrivi "ping www.google.it" (il comando è lo stesso pure su mac o linux)
comparirà una cosa del genere:

Esecuzione di Ping Google [72.14.234.104] con 32 byte di dati:
Risposta da 72.14.234.104: byte=32 durata=28ms TTL=55
Risposta da 72.14.234.104: byte=32 durata=29ms TTL=55
Risposta da 72.14.234.104: byte=32 durata=29ms TTL=55
Risposta da 72.14.234.104: byte=32 durata=30ms TTL=55


quello che ci interessa è la durata, in questo caso circa 29ms (andata e ritorno, quindi circa 15ms di solo andata...) fai varie prove per ogni posizione, con e senza tacche, insomma vediamo un pò la reattività della rete!

[merengue]

lasciamo stare tcp e udp, diciamo che per il video è meglio l'udp per rosicare anche quei 130bit (circa 16 byte) di header
il GPRS si aggira ai 30/70kb/s, mentre l'UMTS si aggira ai 384 kb/s e 7.2 Mbit/s con dispositivi HSDPA. (fonte wikipedia)

Le prestazioni reali (quando è tutto ok) sono UN DECIMO di queste che hai citato, che sono quelle "di targa".
poi ci sono le conversioni analogico-digitale e viceversa...

[biv2533]

tecnicamente è fattibilissimo, gli attuali protocolli usati dalle chiavette posso tranquillamente sostenere un flusso dati adatto a una cosa del genere,

Ottimo, allora cosa state aspettando?

Io posso solo dire che quando ho iniziato io 4 anni fa' tutto questo scambio di idee ed esperienze non c'era.

Allo stato dell'arte noto (con soddisfazione), che molti piloti si sono avvicinati al FPV senza conoscerne una benemerita cippa, hanno fatto un paio di domande e con 800 euro hanno il loro bel sistemino perfettamente funzionante.

Ai miei tempi, a scrivere qua si era in pochi e se devo buttar li una cifra approssimativa, considerando le varie prove e test su telecamere, trasmettitori, antenne, monitor LCD, occhiali LCD probabilmente siamo intorno ai x000 euro (la cifra non la scrivo perche' la moglie potrebbe leggere)

Quindi se qualcuno ha voglia di sperimentare in altre direzioni, diciamo non convenzionali, per l'amor del cielo e' benvenuto, pero' la mia pratica e la pratica di tutti coloro che hanno iniziato piu' o meno insieme a me, non e' di tanto conforto alla sua teoria.

Per cio' che concerne i dati dichiarati in centro citta' (ah gia' che scalogna, e' vero che il segnale 3G spesso in campagna non c'e'), posso solo dire che tanto vale sperimentare dal vivo e di persona.

Io qualche prova con qualche web cam collegata via UMTS la ho fatta e ho notato che gli standard sono standard solo sulla carta.....

Comunque come ripeto, a patto che non si faccia cascare poi il velivolo addosso a qualche casa o persona, le esperienze nuove sono le benvenute

P.S. Il dos, uhm vediamo un po' il dos ah si ora ricordo, avevo 17 anni e credo di aver fatto girare il mio primo programma ,su una piattaforma tipo questa e credo che il dos ancora non fosse stato comprato dal signor Guglielmo Cancelli




Commodore PET 2001

[dtruffo]

uno streaming audio video su rete , anche se di bassissima qualita', monodirezionale , elaborato con CPU di un certo livello introduce come MINIMO un ritardo di 3 o 4 secondi..... Se poi ci mettiamo un supporto (come quello radio) in mezzo, arrivare ai 10 secondi e' abbastanza normale.
Se nella visione di un filmato su internet cio' e' assolutamente trascurabile (tranne vedere un gol dopo che si sa gia' che e' stato segnato !!!) nel pilotaggio sarebbe a dir poco intollerabile !!

[elettro]

bhè il commodore ce l'aveva il mio fratellone , bhe magari non proprio questo modello

esattamente come voi sperimentavate con la tecnologia dell'epoca, io sperimento con la mia, che fortunosamente è più economica (chissa all'epoca del commodore quanto costava una VGA 800*600)
dunque anche se l'UMTS rendesse 1/5 ce la farebbe comunque, e problemi di segnale, essendo in provincia di milano, non ce li ho, anzi credo di avere copertura per due o tre km in ogni direzione.
come camera volevo usare una 640x480...
il formato analogico occupa 2byte per pixel, per un totale di 614400 byte a fotogramma... azz! 600kb tondi! il microcontrollore non ne tiene in memoria 1/300! quindi la conversione o la fa un integrato a parte, che sicuramente esiste per i cellulari ma sarà SMD oppure A.A.A. cercasi modulo telecamera che abbia un'output 3gp!

Non so, voi che dite? con una 2.4ghz quant'è la banda disponibile?

@dtruffo: wee calma, pensa alle videochiamate, ok magari non hanno risoluzione 640*480 ma comunque anche meno basta, l'importante è che si veda qualcosa, o no?

[dtruffo]

bhè il commodore ce l'aveva il mio fratellone , bhe magari non proprio questo modello

esattamente come voi sperimentavate con la tecnologia dell'epoca, io sperimento con la mia, che fortunosamente è più economica (chissa all'epoca del commodore quanto costava una VGA 800*600)
dunque anche se l'UMTS rendesse 1/5 ce la farebbe comunque, e problemi di segnale, essendo in provincia di milano, non ce li ho, anzi credo di avere copertura per due o tre km in ogni direzione.
come camera volevo usare una 640x480...
il formato analogico occupa 2byte per pixel, per un totale di 614400 byte a fotogramma... azz! 600kb tondi! il microcontrollore non ne tiene in memoria 1/300! quindi la conversione o la fa un integrato a parte, che sicuramente esiste per i cellulari ma sarà SMD oppure A.A.A. cercasi modulo telecamera che abbia un'output 3gp!

Non so, voi che dite? con una 2.4ghz quant'è la banda disponibile?

@dtruffo: wee calma, pensa alle videochiamate, ok magari non hanno risoluzione 640*480 ma comunque anche meno basta, l'importante è che si veda qualcosa, o no?

Certo, le videochiamate.... se ritieni che la definizione, il ritardo e il frame rate come quello delle videochiamate sia sufficiente per pilotare, allora non ci sono problemi, ma a mio modesto avviso ci fai ben poco.
Se basta, allora metti un cellulare a bordo modello, inizi la videochiamata e vai in volo, cosi' puoi verificare se e' utilizzabile

[elettro]

in effetti come test una videochiamata non è male :-)

ho dato un'occhita agli xbee ma siamo sempre sui 250 kb/s con un raggio massimo di 1,5KM

comunque dubito che una video chiamata abbia una lag > 200 msec, anzi, senza contare che, sempre secondo la santa wikipedia:

Le applicazioni tipiche attualmente implementate, usate ad esempio dalle reti UMTS in Italia, sono tre: voce, videoconferenza e trasmissione dati a pacchetto. Ad ognuno di questi tre servizi è assegnato uno specifico transfer rate, per la voce 12,2 kb/s, 64 kb/s per la videoconferenza e 384 kb/s per trasmissioni di tipo dati

quindi noi inviando immagini senza audio con una velocità di anche solo 120kb/s (banda massima in uso al 30%) possiamo permetterci il doppio della definizione, se non erro :-)

se dici che ancora non ci siamo col framerate/banda, posso sempre usare il bianco e nero :-)
per quanto riguarda la LAG tutto dipende dal PING! aspetto test su qesto punto di vista, se mi procuro il materiale lo farò io e vi faccio sapere

[dtruffo]

in effetti come test una videochiamata non è male :-)

ho dato un'occhita agli xbee ma siamo sempre sui 250 kb/s con un raggio massimo di 1,5KM

comunque dubito che una video chiamata abbia una lag > 200 msec, anzi, senza contare che, sempre secondo la santa wikipedia:

quindi noi inviando immagini senza audio con una velocità di anche solo 120kb/s (banda massima in uso al 30%) possiamo permetterci il doppio della definizione, se non erro :-)

se dici che ancora non ci siamo col framerate/banda, posso sempre usare il bianco e nero :-)
per quanto riguarda la LAG tutto dipende dal PING! aspetto test su qesto punto di vista, se mi procuro il materiale lo farò io e vi faccio sapere

il lag non e' dato dalla banda, ma dai tempi necessari alla compressione / decompressine dell'immagine