Show Posts
Pages: 1 ... 499 500 [501] 502 503 ... 728
7501  International / Megatopic / Re: [Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo on: November 01, 2011, 10:08:48 am
Continuo a rimanere al buio...
Ho i pin in ingresso, che sono i canali della radio, e poi non dovrei quindi avere in uscita un solo pin?
Inoltre... in che maniera aumentano questi canali disponibili? Cioe' se la mia radio ha mettiamo 6 canali, verosimilmente avra' 6 controlli su questi canali, e quindi il ppm alla fine gestira' sempre 6 canali, non e' corretto?

un'immagine per capire:http://www.pabr.org/pxarc/1.1/doc/opwm_ppm.gif
e http://me-wserver.mecheng.strath.ac.uk/group2007/groupj/design/avionics/lower/image_communication/ppm.jpg

come puoi vedere in alto c'e' il segnale PPM vero e proprio, quello che noi chiamiamo PPMsum. In basso invece ci sono i segnali estrapolati, ovvero i singoli canali. Le riceventi ricevono il segnale PPM e lo dividono in canali, con la schedina di astro prendi i canali e li ritrasformi in PPM. In effetti alcune riceventi hanno dei tutorial su come ottenere il segnale PPM prima che venga suddiviso in canali, ma e' piu' comodo e immediato avere un circuito esterno, soprattuto se usi la ricevente anche su altri modelli o se e' un modello costoso smiley

ottima spiegazione di astro del magnetometro e del nord magnetico!
7502  International / Generale / Re: problema serial port on: November 01, 2011, 06:33:02 am
se parli di bug nello sketch ok, io intendo che non rimarrai mai con una board inutilizzabile grazie al boot-loader interno dell'8u2!
7503  International / Generale / Re: attribuire ip a ethernet shield con fastweb... (?) on: October 31, 2011, 10:38:20 pm
tutto il problema nasce da quì:
Code:
utility/types.h: No such file or directory

ovvero, nella libreria, c'è una cartella utility che dovrebbe contenere il file types.h, ma non c'è! o hai sbagliato e non hai copiato la cartella, o hai scaricato mezza libreria, ma mi pare strano di solito nello .zip ci sono tutti i file necessari
7504  International / Megatopic / Re: [Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo on: October 31, 2011, 10:36:01 pm
Quell'effetto e' dovuto a come il tuo monitor e' orientato rispetto al nord terrestre. Se punti il monitor verso il nord terrestre allora funziona.
La sensor fusion ti da come heading l'angolo tra l'asse X della IMU e l'asse X terrestre (che punta al nord terrestre). Se usi quell'heading direttamente nella GUI assumi che il tuo monitor sia puntato a nord. Questa assunzione viene meno nell'ultima FreeIMU library che usa il tasto H della GUI per impostare un punto di home da cui fare i calcoli.

Non mi e' chiaro come usando le rotazioni locali questo problema possa sparire come dici.

nono, io non ho il magnetometro, ma solo gyro e accelerometro.
in pratica nel tuo codice trasformi prima il quaternione in angoli elueriani (e fin quì ok), poi cambi il loro sistema di riferimento (e questo pezzo a me mancava).
Anziché buttarmi nella matematica di rotazione a testa bassa, ho usato un motore grafico che si occupa di fare questi calcoli al posto mio, in oltre ho tutti i vantaggi di usare un motore grafico per giochi. Per esempio, se non erro è incluso anche un motore fisico 3d: raccogliendo abbastanza dati in volo potrebbe essere possibile simulare il comportamento del quad al variare dei PID, fare da simulatore, etc..
senza contare che la complessità del progetto non è più un problema usando un IDE "avanzato" come netbeans o eclipse
7505  International / Generale / Re: problema serial port on: October 31, 2011, 10:25:18 pm
non me la sono sentita di rischiare il mio Arduino

l 8u2 possiede un boot loader interno, quindi non vai a flesharlo, ma a cambiare il suo "sketch". virtualmente non ci sono rischi
7506  International / Megatopic / Re: [Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo on: October 31, 2011, 07:56:06 am
Quote
Al contrario del codice processing, dove le rotazioni erano rispetto alla telecamera, ora il sistema Java effettua le rotazioni rispetto all'oggetto, rendendo molto più realistico il comportamento e il debug. (varesano, anche la tua versione del codice processing dovrebbe vere questo BUG)

Mmm.. che io sappia, in Processing le rotazioni vengono fatte tutte sul frame del monitor, quindi, a meno di fare qualche boiata con le API push e pop matrix, il metodo che ho usato io era l'unico possibile senza impazzire. Lo spiego qui.

Pero' non capisco come il tuo approccio possa rendere migliore l'output.. in fondo, applicare le rotazioni sul frame del monitor o sul frame locale all'oggetto, dovrebbe portare ad esattamente lo stesso risultato finale.. c'e' qualcosa che mi sfugge?

attenzione. se tu giri il sensore di 90°, e poi lo inclini, anzichè vedere il cubo che si ruota come nella realtà, su ruota come se l'asse di partenza non si fosse mai mosso. Insomma il sistema di riferimento delle rotazioni x e y non è solidale con la rotazione Z.. cosa che a quanto pare hai risolto col codice ce mi hai linkato.

A questo punto l'unico vantaggio che mi rimane è che uso un pannello a parte per l'inserimento dell'input e selezione della seriale, oltre che ad essere su un sistema più familiare.
7507  International / Generale / Re: Arduino assorbimento on: October 31, 2011, 07:33:11 am
Ah, praticamente impossibile  smiley-grin

osservi gli schemi elettrici di arduino, che puoi trovare su questo sito nella sezione hardware, e da lì capire cosa ti serve oppure no. Un'altra ottima lettura è "arduino on breadboard", che ti spiega i componenti più o meno base per fare un'arduino.
7508  International / Generale / Re: Domande su codice oscilloscopio on: October 31, 2011, 07:29:39 am
per completezza aggiungo che per i float (e quindi i double) la cosa non è semplice come un bitshif, e bisogna usare le union:

Quote
union u_tag {
    byte b[4];
    float fval;
  } u;

ora in u puoi settare fval, e quindi leggere il rispettivo valore in byte dall'array b, e viceversa. ovviamente la stessa cosa può essere usata anche con gli interi o long etc...
7509  International / Megatopic / Re: [Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo on: October 31, 2011, 06:55:21 am
Quote
Per contro, con il 328p, non sarà possibile usare la configurazione esa perché un pin pwm, il numero 11, è utilizzato dalla SPI per il segnale MOSI (DATA OUT su Arduino.

ma usa il PWM per gli ESC? mica il PPM?

e poi se fai il PPMSUM dalla ricevente, ti si liberano altri PIN, non so quali ma magari uno PWM c'è (ma continua a pensare che usino il PPM, magari hanno fatto come me che nell'inesperienza hanno usato il PWM, poi son passati al PPM ma hanno tenuto la numerazione dei PIN)... non posso controllare che devo preparare le ultime cose per la partenza, poi londra per 10 giorni...

Ah già che ci sono volevo farvi sapere che ho sistemato la DCM, in pratica la rotazione era data da 2 fattori errati:
1. la P della DCM era troppo alta
2. deltaT per l'integrazione non era un valore corretto. Ora viene settato prima di ogni ciclo, anche se è praticamente un valore fisso (vedi dopo)

novità che hanno dato buoni risultati sulla stabilità in ambiente grafico:
i sensori lavoravano a una frequenza molto più alta. anziché 140Hz (limite WMP), andavano a circa 300 (limite "fisico" del WMP), ma poi avevo un loop a 300Hz. Ora i sensori sono aggiornati ogni 140Hz, e il loop lavora a 25000Hz... (notare che i limiti dell'ADXL335 sono 550Hz per la Z e 1600Hz per la X e Y, quindi il WMP è molto limitante!)

Dall'interfaccia grafica:
è possibile passare a solo gyro (l'accelerometro è simulato sempre parallelo al terreno), solo acc, o giro + acc.

È possibile resettare la DCM alla posizione iniziale

È possibile impostare i valori P e I dell'algoritmo DCM

Al contrario del codice processing, dove le rotazioni erano rispetto alla telecamera, ora il sistema Java effettua le rotazioni rispetto all'oggetto, rendendo molto più realistico il comportamento e il debug. (varesano, anche la tua versione del codice processing dovrebbe vere questo BUG)

Non rilascio ora il codice perchè solo il progetto netbeans pesa 40MB (contiene un engine grafico!), 14MB in .7z, e non so dove upparlo. In oltre prima vorrei integrare questo famoso ADXL345, così potete usare il codice direttamente sulle vostre IMU per confrontare i risultati, infine per 10 non sarò in grado di dare assistenza tecnica
7510  International / Megatopic / Re: [Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo on: October 30, 2011, 03:56:55 pm
se lo shield è una millefori, non ci riesci ad aggiungere un'atmega? altrimenti puoi farlo su una seconda millefori che incastri sopra (in pratica trasformi una millefori in un arduino smiley )
7511  International / Megatopic / Re: [Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo on: October 30, 2011, 03:45:41 pm
se riesci a far meno della I meglio, da solo problemi se ti va in saturazione, evitala se puoi.

il link che hai dato è il PBC non popolato, quindi devi comprarti a parte tutta l'elettronica, dalle resistenze ai sensori. ma non vedo perchè dovresti cambiare PBC visto che a quanto pare quello che hai funziona già benissimo.

edit: domanda aperta a tutti: che sensori state usando attualmente?
7512  International / Megatopic / Re: [Multicotteri] Elettronica : IMU, MCU, Sensori ed algoritmi di controllo on: October 30, 2011, 03:12:42 pm
se voli bene senza impostare I e D, allora vuol dire che il quad è ben equilibrato e i sensori non soffrono dalle vibrazioni. Complimenti!
( o ad essere cinici possiamo dire che gli errori si compensano smiley )

la scheda che hai visto monta la freeIMU di Varesano, tra l'altro utente di questo forum: comprala direttamente da lui smiley

ps. evita di fare il cross-post, la sezione giusta per le tue domande è questa
7513  International / Generale / Re: Domande su codice oscilloscopio on: October 30, 2011, 01:06:12 pm
Quote
val >> 8 :
fa lo shift a destra di val; se per esempio val vale 00001000.00000000 (2048) diventa 00000000.00001000 (smiley-cool [ho messo i punti per distinguere i due byte);
& 0xff:
fa l'and con 11111111.11111111 ; ma a che serve??? non ritorna sempre il valore del primo elemento (in questo caso val >>smiley-cool;

hai ragione! forse serve per forzare il numero ad essere un byte? bho (leo conferma questa idea)

Quote
Ed in più, non sarebbe più veloce visto che si inviano, in tutto, 2 byte (mentre nel codice originale si inviano 4 byte)??

non si inviano 4 byte, ma 128!
sono andato a controllare:
Quote
Serial.print(78, BIN) gives "1001110"

ciò vuol dire che ogni 0 e 1 stampto è un char, ovvero un byte, ovvero 8 bit!!


sono andato a controllare male: lui fa BYTE, non BIN, qindi il codice è già ottimizzato.

Quote
E' un sistema "sicuro" per avere un risultato lungo 1 byte. Con val>>8 avresti lo shift a destra ma continueresti sempre a trattare un int.
vero, ma la pritnt (x, BYTE), dovrebbe già troncare.
7514  International / Generale / Re: Domande su codice oscilloscopio on: October 30, 2011, 11:52:37 am
Quote
val >> 8 :
fa lo shift a destra di val; se per esempio val vale 00001000.00000000 (2048) diventa 00000000.00001000 (smiley-cool [ho messo i punti per distinguere i due byte);
& 0xff:
fa l'and con 11111111.11111111 ; ma a che serve??? non ritorna sempre il valore del primo elemento (in questo caso val >>smiley-cool;

hai ragione! forse serve per forzare il numero ad essere un byte? bho (leo conferma questa idea)

Quote
Ed in più, non sarebbe più veloce visto che si inviano, in tutto, 2 byte (mentre nel codice originale si inviano 4 byte)??

non si inviano 4 byte, ma 128!
sono andato a controllare:
Quote
Serial.print(78, BIN) gives "1001110"

ciò vuol dire che ogni 0 e 1 stampto è un char, ovvero un byte, ovvero 8 bit!!

se posti anche il codice lato PC allora si capisce meglio!

invece facendo:

Code:
int numero=78;
Serial.write( &numero, sizeof(int) )
vai a scrivere solo 2 byte (o meglio sizeof(int), notare come sia comodo per cambiare il tipo di variabile, o un array ), notare anche la write al posto della print: la print forza tutto quello che viene stampato ad essere una stringa leggibile agli esseri umani usando la tabella ascii: invece la write scrive direttamente i bite fregandose allegramente, e permettendo di sfruttare al 100% la banda della seriale.

Certo, sei obbligato a interpretare i valori tramite un programma lato PC, che legga i 2 byte, li unisca e poi faccia la conversione in stringa da stampare, ma il processo a lato pc è molto più veloce che da lato arduino, e con la seriale al massimo (115200 baud), anzichè inviare 115200/128=900 letture al secondo, ne invii 115200/2=57600!!
7515  International / Generale / Re: Domande su codice oscilloscopio on: October 30, 2011, 10:42:50 am
sì, seinvii il numero come char, se ha una cifra devi inviare un byte per la cifra + uno di fine numero. totale 2 byte, se il numero è di 2, 3 o 4 cifre, impieghi un byte addizionale per ogni cifra.

Inviando invece parte bassa e parte alta, a priori sai che un int è di 2 byte, quindi non solo invii solo 2 byte, ma non ti serve nemmeno avere il byte i fine numero, se sincronizzi bene il programma PC con arduino, perchè sai che ogni 2 byte devi trasformarlo in int. Ovvio che se nopn è sincronizzato, rischi di leggere il bytedi un numero con un altro....


però mi sta venedo il dubbio che la print(x, BIN), stampi un carattere (quindi un byte) per ogni bit, quindi in realtà peggiorando la velocità della seriale stampando 64 caratteri per byte...
Pages: 1 ... 499 500 [501] 502 503 ... 728