[Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo

non vedo i video, sono blocato dal proxy, ma se vedi delle bande nere/freeze video, allora è erchè il video è trasmesso in analogico, e qualsiasi trasmittente che usa la stessa frequenza si sovrappone degradandoil segnale.

Soluzine è di cambiare frequenza dei trasmettitori o passare alla trasmissione digitale, cosa che purtroppo non ho ancora visto in giro, anche se con rasperry & co. ormai è una fosa fattibilissima.

No no io parla nella GUI di multiwii i valori che mi fa vedere che gli arrivano dalla ricevete sono tutti sballati vanno su e giu come matti senza che io tocco gli stick, se muovo gli stick loro si muovono però restano sempre molto instabili con incremente e decrementi veloci e vertiginosi !

Sono molto probabilmente delle interferenze radio.
Quello che Leo suggeriva era una probabile fonte di interferenza video, se usi trasmissione video tu o se ce n'è nelle vicinanze, sui 2.4GHz.

Non è davvero colpa del multiwii.
Altrimenti la trasmittente, ma su tutti i canali contemporaneamente non è un problema di potenziometri rotti.

io proverei altrove, così da confermare un disturbo radio.

Io nel frattempo vi aggiorno su quanto stavo facendo, così per aggiungere 2 centesimi..
Allora ho fatto una schedina di conversione con un atmega 328p, che prende un protocollo seriale da una APC220 (19200 baud per almeno 600mt forse più..) e lo trasforma in PPM SUM. Trasmetto il movimento di un joystick 4 assi letto tramite processing via pc, il refresh della draw() è di circa 17-18ms.

Devo dire funziona egregiamente, solo che poi ho scoperto che multiwii ha già un suo bel protocollo, e che si possono iniettare direttamente i pacchetti degli 8 canali, più un semplice checksum direttamente su qualsiasi altra UART, quindi ho tradotto il mio protocollo e adesso gli 8 canali sono direttamente spediti ogni 17-18ms, in digitale.
Non mi sembra una brutta cosa..
se uno avesse una scheda radio full-duplex immagino che con la stessa velocità potrebbe ricevere anche dati di telemetria..

Per ora comunque ancora niente voli, solo un pò di tarature dei PID, ma da verificare. Poco tempo a disposizione..

Ciao!

magari batterie scariche nella trasmittente??

ottimo lavoro dab!

Grazie! Anzi, giusto ora stavo provando ad aumentare il frameRate a 80 e poi a 100 fps in processing, senza disegnare niente, e ho una trasmissione ogni 8-10ms.. non male. anche se ogni tanto (1 al minuto) ho un singolo picco di 30ms..

bha, processing per cosetroppo in là...

si, lo so, lo so.. magari in python, però con processing ci metto un attimo. poi se i tempi di reazione diventano critici riscrivo, che con python ho già fatto delle cose con grafica e trasmissione seriale, ce la posso fare.
per adesso però processing va più che bene.

allora, piccolo problema; la mia board stm32f3 ouputta al massimo 3v. vedendo gli schemi di taulabs (un port openpilot su questa scheda) i ragazzi usano cvollegare i pin direttamente. Ok, in input ci sono 42 pin 5v tolerant, ma in output agli ESC vanno diretti con il pin. Ch, ripeto, è 3v. Ora, io SO chea bordo dei miei ESC c'è un atmega, che presumo lavori alla stessa tensione che gli entri dal connettore (quindi 5v). Problema; essendo l'1 logico dell'atimega a 3v,, non è una baggianata usarlo direttamente? non dovrei fare una open-drain con pullup a 5v, o ad almeno 3,3v?

concordo con la tua prudenza.
Se e' alimentato a 5V lavori sul limite minimo, e basta un oscillazione per perderti qualche "1"
C'e' da dire pero' che non sappiamo come e' fatto l'esc di cui parli, se internamente ha attiva la pullup sugli ingressi, ed il tuo sketch lavora a logica invertita, non hai problemi.

Salve a tutti, scrivo in questo forum proprio perchè sono disperato.
Durante la mia esperienza nella costruizione del primo quadricottero con configurazione ad X ho incontrato molto difficoltà, piccole e grandi ma questa proprio non riesco ad oltrepassarla.
Vi elenco le componenti:
4 motori rc timer 1000kv;
4 regolatori rc timer simonk 30 A
Lipo 3s 3300 mha turnigy
Centralina crius SE (rctimer) con software multiwii 2.3 :http://www.rctimer.com/index.php?gOo=goods_details.dwt&goodsid=761&productname=
radio turnigy 9x software originale e ricevente originale.

Prima di questa centralina utilizzavo arduino con imu GY-80.
Ho fatto delle prove e sembrava funzionare tutto alla perfezione a parte un motore difetto che rendeva il modello instabile.
Allora ho acquistato un nuovo motore ed ho sostituito arduino con questa centralina (crius SE).
Appena montato ho fatto un piccolo test sui motori e funzionava tutto anche dala GUI era tutto funzionante. Allora ho attaccato il modulo bluetooth(http://www.rctimer.com/index.php?gOo=goods_details.dwt&goodsid=764&productname=) per la configurazione dei parametri senza cavo usb, dopo aver scritto i dati di tuning PID, vado ad armare i motori e non girano, allora stacco il modulo bluetooth attacco l'FTDI e apro la GUI da pc. e noto che i valori dei motori armati non sono più 1150 come all'inizio ma 1064. Allora che faccio apro l'ide di arduino e programmo la scheda nuovamente controllando che il min throotle a 1150. vado nella GUI e non cambia nulla, allora ho programmato al scheda con uno sketch vuoto e poi con il multiwii ma niente ancora.
Oltre tutto ho notato che aumentando lo stick del gas i motori girano però soltanto due, con l'aumento progressivo si avviano tutti ma a velocità diverse, e non rispondono neanche all'inclinazione dell modello.

Io vi prego di aiutarmi, se c'è qualcuno che magari è disposto anche ad intraprendere un sistema di comunicazione più immedia del forum, non so skype o chat istantanea. ditemi voi.
Se c'è qualcosa che non è chiaro nel problema non esitate a contattarmi.
E-mail mia : riccardo.merli94@gmail.com

@RiccardoMerli94: ma la gui rissponde alle inclinazioni? se non erro ci dovrebbe essere un modelli 3d che ti mostra il tutto.

per il minimop/massimo è stranpo, magari quel bluethoot ha fatto sfasare le cose e hai rispogrammato gli esc, non hai sentitodei beep strani arrivare dai motori?

@Testato: NON lavora a logica invertita, ho guardato gli schemi della scheda afroEsc, che è open e pensata apposta per i quad, ha l'ingresso sul pin "12" (package TQFP, corrisponde al "nostro" 14), digitale.

ciò sarebbe particolarmente grave, per esempio la taulabs VENDE una scheda che collega diretto il PWM dei motori in uscita dalla scheda (3V, neanche 3.3V) agli ESC (e gli afro sono moolto usati)... Chissà quanti ESC "resettati all'improvviso" sono in realtà colpa di questi collegamenti. Normalmente sembra andare, però, il che è forse peggio.

Allora innanzi tutto ti voglio ringraziare perchè sei sempre molto disponibile, e rispondi sempre in maniera tempestiva.
Tornando al problema, si la gui riceve tutto correttamente e il modello 3D risponde coerentemente rispetto a quello reale. Gli Esc li ho ricalabrati manualmente uno per uno, ma non è un problema , almeno credo, dei regolatori, perchè non è che la centralina da lo stesso segnale a tutti i regolatori ma quest'ultimi non rispondono bene, è proprio il software che da dei segnali errati ai regolatori.
Per farti capire meglio magari possio farti vedere il problema attraverso teamviewer.
Io escluderei un problema di attuazione ( motori e regolatore) perche ne o acquistati molti dello stesso tipo proprio per evitare problemi quindi li ho sostituiti con dei nuovi, ma il problema persiste.

se hai un altro arduino, sarebbe interessante se leggessi le durate in microsecondi del segnale alto e basso che esce dalla schedina; in teoria dovrebbero corrispondere al numero impostato da gui, al minimo.

in oltre potresti provare ad usare gli esc uno per uno usando l'arduino con la libreria servo. Questo vale anche se hai un solo arduino, confrontando il comportamento usando un pin a caso vs i pin normalmente usati per comandare gli esc; magari sono saltati i pin! (in tal caso per il volo consiglio un nuovo arduino)

Do per scontato che hai risettato sugli esc il minimo e massimo del PPM, batteria lipo (o quella che usi), e no brake.

lesto:
@Testato: NON lavora a logica invertita, ho guardato gli schemi della scheda afroEsc, che è open e pensata apposta per i quad, ha l'ingresso sul pin "12" (package TQFP, corrisponde al "nostro" 14), digitale.

E' grave si, il datasheet parla chiaro, 3V e' la soglia minima, basta un niente n fase di produzione del micro, oppure sul regolatore, sull'alimentazione, a stare sotto.
Forse lo fanno apposta per far schiantare i velivoli :slight_smile:

io ho due arduino, ma quella che uso per volare non è un arduino (utilizza lo stesso processore di arduino nano).
se prendo ogni regolatore e motori e li provo singolarmente, attraverso la ricevente, funzionano bene, con arduino non ho provato a vedere se riesce a pilotarli, ma penso che non ci siano problemi, secondo me è una questione di scheda, perche anche se attacco la scheda al pc e sulla scheda ho collegato soltanto la ricevente, nella gui vedo sempre i stessi valori errati.
ora provo a sostituire la scheda con arduino e l'IMU, e poi ti faccio sapere, se mi da problemi anche cosi significa che sono i componenti altrimenti mi acquisto una scheda diversa. Se è la scheda proprio non mi capacito proprio di quello che gli può essere accaduto perchè proprio da un minuto per l'altro.
Va bè faccio queste prove e ti faccio sapere.
Grazie ancora sei gentilissimo.

aspetta, quindi sono i dati in arrivo dalla ricevente ad essere errati?

o parli dei valori di default dei motori?

cmq io intendevo di collegare il segnale che va agli esc al vero arduino, e da lui leggere il PWM che esce ( pulseIn() )

@Testato: 2.7V @5v per l'essattezza, con isteresi di 0.5V.... fuck!

perche' 2,7 ? di che micro parli ?

"Figure 29-71. ATmega88PA: I/O Pin Input Threshold Voltage vs. VCC" (pag, 364 della rev8161-D) (usano un atmega8, ma pag 412 dice la stessa cosa anche del 328P)

Che strano, guardando le curve e' come dici tu, ma guardando la tabella delle caratteristiche, al parametro Vih, abbiamo un bel 0.6VCC, cioe' i 3V che ti dicevo :fearful:
Quale e' la verita' ?