APM Copter

[Bobo67]

I cavi schermati di solito si utilizzano quando non ci sono segnali digitali ma analogici, teoricamente su cavi non troppo lunghi la schermatura in questo caso è ininfluente, anche se empiricamente è sempre meglio twistarli comunque.
Alcuni tipi di segnali digitali possono non avere problemi anche su cavi abbastanza lunghi, altri invece iniziano a scantonare, se ben ricordo ad esempio l'I2C è molto più pignolo rispetto all'SPI.

[Paolo - BT]

Ciao Paolo,
benvenuto nel mondo dei quadricotteri , confermo che Marco non ha alcun interesse a spingere una piattaforma piuttosto che un altra parlo di VRBrain vs Pixhawke , anche perchè giochiamo in casa siamo tutti parte dello stesso progetto ... e se ti leggi il milione di post su VRBrain vedrai che quando c'era da cazziarci il primo a farlo e' sempre stato lui .
Volevo farti i complimenti per i tuoi progetti di razzi modellismo , peccato che non si possa fare qualcosa con alette mobili , sarebbe interessante fare qualche sperimentazioni .... c'e' qualche "matto" nel nostro team che vuole portare a 40 mila metri con pallone una riproduzione di un x15 e poi mandarlo in orbita il tutto controllato da una VRBrain che controlla le fin , non so se si chiamano cosi , del x15 . C'e' gia' un codice modificato che e' in grado di controllare questo tipo di configurazione Pensi che con le normative europe possiamo fare qualcosa del genere anche in questa parte del mondo ? Magari sempre in spagna da dove hai fatto i tuoi lanci ? Lui ha un ranch vicino a Houston che ha chiamato rocket ranch per fare questi test ;)
un saluto
Roberto

Ciao Roberto,
ripeto è stata un'impressione di un utente medio senza nessuna cattiveria.
Ti ringrazio per i complimenti, comunque io conosco delle persone che hanno già lavorato sulle alette mobili, ma ti dico anche che un italiano ha già lavorato sulla stabilizzazione attiva indirizzando i gas di scarico.
Tutto questo circa una decina di anni fa, tanto che i suoi esperimenti sono stati ripresi da una rivista negli Usa.
Io non mi occupo di elettronica e quella che uso è strettamente commerciale e anche di questa ho dovuto fare una cernita, in alcuni casi perdendo tutto.
Le problematiche sono molte accelerazioni, vibrazioni di tipo meccanico e poi un certo rumore di fondo che viene creato da alcuni tipi di endoreattori che mandano in tilt i sensori delle schede.Certamente la grande maggioranza degli hobbysti in questo campo non sa neanche di cosa parlo e questi problemi non li toccano minimamente;dopotutto quello che io ho sviluppato nell'ultimo anno i grandi guru del settore non se lo sarebbero nemmeno sognato.
Probabilmente una APM o una VRBrain potrebbero dare dei problemi e bisognerebbe usare dei sensori diversi che esistono ed hanno altri costi, sicuramente per qualcuno che ci si volesse dedicare potrebbe essere un'occasione di crescita professionale non da poco.
Il progetto che mi dici tu non lo conosco ma penso che una volta in quota X15 venga lanciato con un motore commerciale solido e probabilmente le problematiche che ti ho descritto non sussistono.
Per quanto riguarda noi è un problema di trovare il posto libero da qualsiasi cosa, poi la burocrazia ti amazza.
Il mio sogno è quello di lanciare a quelle quote partendo da terra.
Scusate OT.

Saluti e Auguri
Paolo

[xwing]

Alcuni tipi di segnali digitali possono non avere problemi anche su cavi abbastanza lunghi, altri invece iniziano a scantonare, se ben ricordo ad esempio l'I2C è molto più pignolo rispetto all'SPI.

Sul bus I2C il limite è dato dalla capacità complessiva della linea, ovvero la somma delle varie capacità del cavo e dei device, che deve essere inferiore a 400 pF, inoltre sono molto importanti le resistenze di pull up che devono consentire una corrente di 3 mA in funzione della tensione usata sul bus, TTL 5V o CMOS 3.3V.
Sul bus SPI sono molto critici i fronti di salita/discesa del segnale, è decisamente più difficile da gestire della I2C, tutti e due sono stati pensati per collegamenti a livello dello stesso pcb o, al massimo, ad altri pcb tramite cavi corti, max qualche decina di cm.
Sia per I2C che per SPI va benissimo un cavetto flat con i segnali separati da un filo con GND.
Per bus a lunga distanza è meglio andare sulla RS485/RS422, qui addirittura si arriva a oltre 1 km, oppure sul CAN bus che è molto affidabile, però è abbastanza complesso da gestire come protocollo di trasmissione.
Non a caso in ambito automotive, nautico, aeronautico, i bus usato sono RS485, RS422 e CAN.

p.s.
Sto tentando di decodificare il protocollo DJI sul CAN in modo da slegarmi dai loro costosi gadget legati quasi esclusivamente agli iCosi Apple

[redfox74]

Sul bus SPI sono molto critici i fronti di salita/discesa del segnale, è decisamente più difficile da gestire della I2C, tutti e due sono stati pensati per collegamenti a livello dello stesso pcb o, al massimo, ad altri pcb tramite cavi corti, max qualche decina di cm.
Sia per I2C che per SPI va benissimo un cavetto flat con i segnali separati da un filo con GND.

p.s.
Sto tentando di decodificare il protocollo DJI sul CAN in modo da slegarmi dai loro costosi gadget legati quasi esclusivamente agli iCosi Apple

Mhhh i2c vs SPI , dieci mila volte meglio e piu' supportato spi , primo e' bidirezionale full duplex e i micro lo supportano in dma senza alcun problema , se hai a disposizione qualche pin in piu di chip select molto meglio .
La velocità dell'SPI arriva a svariate decine di Mhz senza problemi e i cavi di collegamente sono molto piu' lunghi , la comunicazione e' elementare , non devi diventar matto con i vari dialetti per capire chi occupa il bus e chi no .... io sconsiglio assolutamente per progetti affidabili i2c e' pensato per cose molto semplice non per bus di comunicazione ad alta frequenza .

In merito al protocollo CAN DJI molto interessante il tuo lavoro ... sopratutto in ottica retro engineering.

Sarebbe curioso capire cosa la Wookong si dice con la sua IMU e con il suo GPS

un saluto
Roberto

[redfox74]

Ciao Roberto,
ripeto è stata un'impressione di un utente medio senza nessuna cattiveria.
Ti ringrazio per i complimenti, comunque io conosco delle persone che hanno già lavorato sulle alette mobili, ma ti dico anche che un italiano ha già lavorato sulla stabilizzazione attiva indirizzando i gas di scarico.
Tutto questo circa una decina di anni fa, tanto che i suoi esperimenti sono stati ripresi da una rivista negli Usa.
Io non mi occupo di elettronica e quella che uso è strettamente commerciale e anche di questa ho dovuto fare una cernita, in alcuni casi perdendo tutto.
Le problematiche sono molte accelerazioni, vibrazioni di tipo meccanico e poi un certo rumore di fondo che viene creato da alcuni tipi di endoreattori che mandano in tilt i sensori delle schede.Certamente la grande maggioranza degli hobbysti in questo campo non sa neanche di cosa parlo e questi problemi non li toccano minimamente;dopotutto quello che io ho sviluppato nell'ultimo anno i grandi guru del settore non se lo sarebbero nemmeno sognato.
Probabilmente una APM o una VRBrain potrebbero dare dei problemi e bisognerebbe usare dei sensori diversi che esistono ed hanno altri costi, sicuramente per qualcuno che ci si volesse dedicare potrebbe essere un'occasione di crescita professionale non da poco.
Il progetto che mi dici tu non lo conosco ma penso che una volta in quota X15 venga lanciato con un motore commerciale solido e probabilmente le problematiche che ti ho descritto non sussistono.
Per quanto riguarda noi è un problema di trovare il posto libero da qualsiasi cosa, poi la burocrazia ti amazza.
Il mio sogno è quello di lanciare a quelle quote partendo da terra.
Scusate OT.

Saluti e Auguri
Paolo

In merito ai sensori sicuramente come dici tu sottoposti a forti accelerazioni vanno in pappa ... bisogna vedere cosa succede ai giroscopi invece che sono piu' immuni a questo problema , una delle soluzioni potrebbe essere usare solo i giroscopi nel calcolo di assetto fin tanto che gli accelerometri non tornano in un range accettabile , di solito si taglia la velocità angolare per tenere in assetto l'oggetto , mi piacerebbe capire di cosa ha bisogno un razzo a livello di elettronica per stare in assetto ... tutta cultura ... e magari con qualche patch al codice di VRBrain si puo' fare qualcosa di simpatico ... sicuramente la propulsione ibrida e' un tema interessante ... c'e' una società di Padova che fa parte di una nostra società che fa' sistemi a propulsione ibrida per lanciatori di droni si chiama HIT09 non so se la conosci ....
saluti
Roberto

[danveal]

p.s.
Sto tentando di decodificare il protocollo DJI sul CAN in modo da slegarmi dai loro costosi gadget legati quasi esclusivamente agli iCosi Apple

Interessante, se non è un progetto segregato ( ora con il nuovo regolamento enac sapr questa parola è diventata di moda ) facci sapere gli sviluppi.

Per quanto riguarda I2C e SPI sono protocolli originariamente pensati per comunicazioni a breve distanza come quelle di un circuito stampato o il collegamento tra circuiti stampati all'interno di apparecchiature. Insomma qualche decina di cm.
Molto meglio il can bus appunto.

@Roberto dovresti pensarci al can bus nell' ottica del certificato di tipo ristretto o in serie ;-)

[redfox74]

Interessante, se non è un progetto segregato ( ora con il nuovo regolamento enac sapr questa parola è diventata di moda ) facci sapere gli sviluppi.

Per quanto riguarda I2C e SPI sono protocolli originariamente pensati per comunicazioni a breve distanza come quelle di un circuito stampato o il collegamento tra circuiti stampati all'interno di apparecchiature. Insomma qualche decina di cm.
Molto meglio il can bus appunto.

@Roberto dovresti pensarci al can bus in nell' ottica del certificato di tipo ristretto o in serie ;-)

Ciao Danilo,
nella v 4.x c'e' gia' il supporto CAN ma non c'e' il driver hardware montato a bordo ... nella v5 invece il driver potrà essere montato anche a bordo
Stiamo lavorando piu' che altro sul driver software in questo momento per gestire le comunicazioni in modo efficiente ...

Per quanto riguarda i test su i2c e spi ... su i2c andiamo al massimo a 25-30 cm mentre su spi fatto prove anche fino a un paio di metri.
un saluto
Roberto

[danveal]

Per quanto riguarda i test su i2c e spi ... su i2c andiamo al massimo a 25-30 cm mentre su spi fatto prove anche fino a un paio di metri.
un saluto
Roberto

Si ma tu mi insegni che su un multirotore in volo ci sono molti disturbi che impattano sul segnale digitale e su distanze lunghe, riferite al tipo di protocollo, dell'onda quadra originaria ne rimane ben poco, sopratutto su velocità di trassmisione elevata.
I rising e i falling edge soffrono

[xwing]

Mhhh i2c vs SPI , dieci mila volte meglio e piu' supportato spi , primo e' bidirezionale full duplex e i micro lo supportano in dma senza alcun problema

Concordo al 100%, inoltre l'I2C se non ben implementato a livello codice può facilmente portare al blocco del sistema per un loop infinito di attesa, ne sanno qualcosa quelli che usano Arduino

In
merito al protocollo CAN DJI molto interessante il tuo lavoro ... sopratutto in ottica retro engineering.

Premesso che non mi manca la strumentazione specifica per analizzare il CAN, rimane il fatto che questi signori si sono inventati un modo tutto loro per trasmettere i dati, ovviamente uno strato ulteriore al normale protocollo CAN, il che rende abbastanza difficile capire come funziona la cosa.
Ho appena iniziato a lavorarci sopra, però qualche risultato l'ho già ottenuto e se non saltano fuori problemi strani in tempi relativamente brevi dovrei riuscire ad interpretare buona parte del loro protocollo, il che permetterebbe sia di attingere i dati dalla NAZA M che utilizzare i loro device aggiuntivi anche con altre elettroniche.
Ovviamente tutto il lavoro sarà reso disponibile open source.

[Bobo67]

Siamo un pochino OT, ma molto interessante.
Riusciresti a rendere disponibile il codice del loro protocollo di comunicazione?
Non rischieresti d'imbatterti in problemi di copyright?
Che sia chiaro, sarebbe veramente una manna!

[danveal]

Su rcgroups sono riusciti a decodificare il segnale gps+compass e tramite un arduino a ricodificare i dati in mavLink oltre che associare un minimosd per fare un osd. Per il pitch e roll prendono i dati dall'uscita gimbal mentre il resto dal gps e compass. Ma riuscire a decodificare i dati dal can bus sarebbe tutta un altra cosa

[xwing]

Su rcgroups sono riusciti a decodificare il segnale gps+compass

Solo parzialmente, alcune cose di come il GPS invia i dati sulla porta EXP del NAZA non sono note, il "trucco" di intercettare il PPM dei servo per il gimbal funziona, però non è la stessa cosa di avere a disposizione le reali letture della IMU.

[Paolo - BT]

In merito ai sensori sicuramente come dici tu sottoposti a forti accelerazioni vanno in pappa ... bisogna vedere cosa succede ai giroscopi invece che sono piu' immuni a questo problema , una delle soluzioni potrebbe essere usare solo i giroscopi nel calcolo di assetto fin tanto che gli accelerometri non tornano in un range accettabile , di solito si taglia la velocità angolare per tenere in assetto l'oggetto , mi piacerebbe capire di cosa ha bisogno un razzo a livello di elettronica per stare in assetto ... tutta cultura ... e magari con qualche patch al codice di VRBrain si puo' fare qualcosa di simpatico ... sicuramente la propulsione ibrida e' un tema interessante ... c'e' una società di Padova che fa parte di una nostra società che fa' sistemi a propulsione ibrida per lanciatori di droni si chiama HIT09 non so se la conosci ....
saluti
Roberto

Sicuramente la materia sarebbe vasta e molto interessante ma non è il caso di parlarne qui.
Per quello che riguarda HIT09 so chi sono e adirittura ero presente al loro primissimo test a fuoco, non avevano molto chiaro quello che stavano facendo .
Poi abbiamo fatto un bando insieme per lo sviluppo tecnologico indetto dall'ASI.
Comunque stiamo parlando di cose che stanno su piani diversi; loro sono degli scienziati io un semplice hobbysta dilettante .
Chiudo OT perche a ragione mi bastonate.

Ciao
Paolo

[Bobo67]

Primi test di stabilità sul codice "APM Copter V3.1" e la board Pixhawk V2.4, prima di volarci seriamente deve andare bene in hovering, riscontrati e già segnalati piccoli glitch di pitch random, stiamo cercando di capire se è la scheda che li genera, ma al 99% si, con VR Brain non lo fa, sullo stesso setup.
Vi tengo aggiornati.

[redfox74]

Primi test di stabilità sul codice "APM Copter V3.1" e la board Pixhawk V2.4, prima di volarci seriamente deve andare bene in hovering, riscontrati e già segnalati piccoli glitch di pitch random, stiamo cercando di capire se è la scheda che li genera, ma al 99% si, con VR Brain non lo fa, sullo stesso setup.
Vi tengo aggiornati.

Ciao Marco,
visto il video , mi sembra anche che ondeggia molto a destra e sinistra come se il mag non fosse tarato bene ... scusa ma se non mi sbaglio hanno cambiato anche il magnetometro non montano piu' l'hmc5883 e nemmeno l'hmc5983 ... usano quello di ST giusto ? Vedrai che nella prossima release cambiano di nuovo anche il mag ... dopo aver rimesso mpu6000 come da consiglio spasionato di 6 mesi fa

saluti
Roberto