Official topic: multicotteri con arduino!

che giroscopi usa?!?!

lesto:
che giroscopi usa?!?!

Chi e cosa ?

ah, mi son rotto di far andare il wmp e il nun, quindi, visto che ho 2 atmega, pensavo di usare il 2° per leggere il nun e inviare i dati al primo arduino che fa tutto il lavoro di codicica etc.. Problema... come faccio comunicare i due arduino? la seriale è lenta, nell'i2c sono entrambi master e se setto l'indirizzo non vanno i sensori, che altro potrei usare?

astrobeed:

lesto:
che giroscopi usa?!?!

Chi e cosa ?

il tizio del video... la coda è sempre ferma anche quando fa cambi velocissimi..

lesto:
nell'i2c sono entrambi master e se setto l'indirizzo non vanno i sensori, che altro potrei usare?

Setta il secondo ATmega come I2C slave, gli dai un suo indirizzo e lo fai funzionare in emulazione di un ADXLxxx.

il tizio del video... la coda è sempre ferma anche quando fa cambi velocissimi..

Quasi sicuramente un Futaba GY601, un giocattolo che costa oltre 400 Euro con il suo servo superveloce a 330 Hz.

eh, ma mi servono entrambi master, uno per wmp e uno per il nunchuck... pensavo magari di farli andare in SPI

lesto:
eh, ma mi servono entrambi master, uno per wmp e uno per il nunchuck... pensavo magari di farli andare in SPI

Sul secondo ATmega usi una I2C emulata a software per leggere il Nunchuk e quella hardware per dialogare con il primo ATmega.

è un'idea, ma sai che non riesco a trovare una cavolo di libreria? se cerco software escono esempi di codice, se cerco emulata trovo come simulare sensori con arduino... eppure avevo trovato qualcosa qualche giorno fa, ma non me la son salvata nei preferiti... conoscete qualche libreria? visto che devo comunicare solo 3 int pensavo di usare la simulata come ponte tra i 2 arduino, così i 400kB/s li uso per leggere i sensori che han "pacchetti" più gozzi.
Oppure potrei usare direttamente il sensore su i2c simulata, se è abbastanza veloce.

edit: do per scontato che l'I2c simulato sia assi più lento

stavo programmandomi una libreria apposta per comunicare, senza entrare troppo nel dettaglio ho controllato a priori la durata di una digital read... 4ms.
Troppo, viene un baudrate di 250.. Potrei usare gli input/output a livello di registro, ma tanto vale usare la NewSoftSerial, che arriva fino a 57600baud in ricezione e 115200baud in trasmissione. Quindi userò la seriale simulata per comunicare con il PC, tanto l'output è pensato per funzionare a 19200baud (ed ecco perché la seriale mi sembrava così lenta, pensavo di usare una delle velocità più alte... :grin:) )

lesto:
stavo programmandomi una libreria apposta per comunicare, senza entrare troppo nel dettaglio ho controllato a priori la durata di una digital read... 4ms.

Non so come hai fatto questa misura, però è totalmente sbagliata, sia la digitalRread che la digitalWrite richiedono un tempo di esecuzione leggermente inferiore a 2 us, sempre molto rispetto alla scrittura/lettura diretta del registro del port che richiede solo 62 ns, o 124 a seconda del tipo di indirizzamento, come avevo già fatto notare in un altro thread.

uhhh hai completamente ragione, ho confuso 4microsec con 4ms!!! mea culpa

void setup(){
  Serial.begin(19200);
}

void loop(){
    int a;
  unsigned long time2;
  
  pinMode(12, INPUT);
  unsigned long time1 = micros();
  for (int i=0; i < 1000; i++){
    a=digitalRead(12);
  }
  time2 = micros()-time1;
  
  Serial.print("1000 read duration:");
  Serial.println(time2);
  
  pinMode(12, OUTPUT);
  boolean stat=false;
  time1 = micros();
  for (int i=0; i < 1000; i++){
    digitalWrite(12, stat?HIGH:LOW);
    stat=!stat;
  }
  time2 = micros()-time1;
  
  Serial.print("1000 write duration:");
  Serial.println(time2);
}

OUTPUT:

1000 write duration:5664
1000 read duration:4156

quindi dovrebbe venire un baud di circa 250.000 (in realtà raggiungere 200.000 credo sia già un bel traguardo)

boh mi sa che oramai vado di seriale, poi magari in un'altra discussione posto il codice che ho scritto finora, anche se è molto "hard coded". Usa due pin fissi, il lettore richiede i messaggi semplicemente alzando e abbassando un pin(una specie di clock che lavora su entrambi i fronti), lo scrittore riceve l'interrupt change dal pin di clock e scrive un bit nel pin "dati"

In questo modo il lettore NON conosce a priori se ci sono dati pronti, semplicemente legge sempre 0.

lesto:
uhhh hai completamente ragione, ho confuso 4microsec con 4ms!!! mea culpa

Comunque il test che fai è sbagliato lo stesso perché nel conteggio del tempo ci va pure il ciclo for, che si prende i suoi 2-3us, il tempo reale sono i poco meno 2us che ti ho detto, misurati strumentalmente a suo tempo sul tempo che ci mette un pin a cambiare stato tra due digitalWrite consecutive, stessa cosa per la digitalRead misurata come offset in mezzo a due digitalWrite.
In tutti i casi non puoi ottenere un baud rate pari ad 1/2 del tempo di commutazione perché in mezzo c'è pure il tempo per eseguire lo shift del registro da inviare/leggere bit a bit su un pin.
Non a caso ti ho detto di usare la I2C hardware come slave, a 400 kHz, per comunicare con il resto del sistema e usare la I2C emulata in software per leggere il Nunchuk.
Prima di tutto è più semplice emulare un master che uno slave, e poi c'è il fatto che il Nunchuk ha una banda limitata, mi pare al massimo 100Hz, quindi puoi prenderti tutto il tempo che vuoi per leggerlo, non ti serve spingere l'I2C master ad alte velocità, anche se lo leggi 1000 volte al secondo non cambia nulla, alla fine sempre 100 valori diversi, distanziati di circa 10 ms, ottieni.
Non scordarti che i valori 100kHz e 400kHz sono i limiti di velocità e non la velocità obbligatoria, ovvero l'I2C puoi farla funzionare con un clock che parte da poche centinaia di Hz, con alcuni device pure meno di 1 Hz, fino al limite massimo ammesso e non deve nemmeno essere costante perché è una seriale sincrona, ovvero tutto va in funzione del clock generato dal master.

ok, ma il problema è trovare una libreria software i2c. ne ho trovata una ma è molto basica e non specifica i propri limiti. vediamo se riesco a farci stare la newSoftSerial, altrimenti rimedio sull'i2c software

purtroppo l'i2c non l'ho mai usato se non per il wmp e il nunchuck, e quindi non sono pratico del protocollo, sopratutto per quanti riguarda controllare se una libreria è valida oppure no.

quella che ho trovato io è questa: http://www.bese.it/~segv/twi.tar.gz

Soluzione alternativa, intercetta le tre uscite analogiche dell'accelerometro e collegale direttamente all'ADC di Arduino, sempre 10 bit di risoluzione ottieni, anzi volendo ne puoi ottenere 12 con l'oversampling.

allora chi inizia a buttare giù qualche algoritmo di stabilizzazione? (PID, kallmann ecc..) XD

io non ne sono in grado =(

superlol:
allora chi inizia a buttare giù qualche algoritmo di stabilizzazione? (PID, kallmann ecc..) XD

Prima di partire con un lavoro che richiederà molto impegno sarebbe il caso di capire chi è disposto a collaborare sul serio e se c'è realmente l'intenzione di sviluppare un hardware/software "made in Italy" per i quadricotteri.

io uso la DCM, leggera veloce e abbastanza semplice. Certo usa seni, coseni e una radice quadrata, e per poi passare dal quaternione di rotazione agli angoli euleriani è un'altra bella botta di seni/coseni... dovremmo mettere al confronto un kallman e una DCM, dopo pranzo controllo quanto mi dura un loop, ma se non erro era sui 700 microsec, DCM + conversione a euleriani. magari si può evitare la conversione, o magari sovrapporre i due metodi (se abbiamo abbastanza potenza di calcolo)

lesto:
io uso la DCM, leggera veloce e abbastanza semplice.

Per come la vedo io con la DCM ti sei solo complicato la vita senza trarre nessun reale beneficio, non ho dati per la combinata PID e Kalman su un ATmega, li uso per altre cose, in compenso ho dati molto precisi su i PIC serie 18, per un ciclo completo mi bastano meno di 200 us (pid e kalman ottimizzati sull'applicazione), dovrebbe essere lo stesso anche su ATmega 328.
Si può sempre prendere in considerazione di portare il clock del micro a 20 MHz, avevo già postato la cosa diverso tempo fa con tanto di bootloader modificato per tale frequenza, il 25% di velocità nei calcoli fa sicuramente comodo in questa applicazione.

ad occhio la DCM è più semplice da implementare, almeno per me che qualcosina di algebra lineare la so. Il codice che ho usato non l'ho scritto io, ho solo risolto un problemino quando l'accelerometro legge 0,0,0 (caso quasi impossibile, ma prevenire...)

io per tutto il ciclo (compresa lettura RX tramite interrupt, che probabilmente rallenta un pò tutto) trasformazioni e tutto mi pare che arrivassi a 1ms per loop

però è difficile trovare un paragone, bisognerebbe vedere anche la qualità dei dati in uscita

per i 20MHz mi sa che diventa un pò un casino per ci usa la board arduino, sarebbe obbligatorio usare un chip stand alone

ps. ho controllato l'idea del collegamento analogico... il chip è uno ADXL335B (perchè è un fake nunchuck) foglio dati: http://docs.google.com/viewer?a=v&q=cache:VtX3g1Lcf4wJ:www.sparkfun.com/datasheets/Components/SMD/adxl335.pdf+adxl335b+accelerometer&hl=en&pid=bl&srcid=ADGEESipeGlTX4n5OKnMEdGa4brKTPdTzKchHCT-2C0wRhDYJAKQJbdMyPC8xYrTH8104HBRChs5oNgoB8En7lcaWaQIftwDIIBmuRylYziVLbH9W4MViJDPDLD6qPlvR-l8qWc-8W20&sig=AHIEtbTugPuomcYswsiC2j8iBBhZFsvlTw
l'oversampling se ho capito bene è leggere più volte il dato prima che il sensore lo aggiorni, e fare la media di queste letture, giusto?
Quindi in questo caso facendo 3200 letture analogiche al secondo avrei un oversampling di 2 dati per x e y(1600Hz), e di ~6 dati per l'asse z(550Hz), giusto?

data la disposizione dei pin, credo che volendo riuscirei pure a saldarci sopra dei cavi volanti... è indubbio che fare una board apposita sia la soluzione migliore però.. rischio di rovinare il chip, magari "strappando" le piste?

io sono disposto a rischiare il mio quadricottero per gente come voi basta non mi facciate scherzi :wink:

per di più tra poco credo ordinerò la freeIMU di Fabio Varesano ]:smiley:
(questo volta definitivamente :~)

riguardo la clock vero che il 25% di velocità in più sarebbe davvero comoda ma come è stato detto renderebbe il tutto più complicato per chi si avvicina per la prima volta.

io direi intanto di dire:
che parti salviamo di multiwii? quali eliminiamo?

visto che è stato riscritta la parte riguardante l'I2C che non rallenti il software (almeno è quello che ho capito) si potrebbe tenere, così il sistema di leggere i segnali dalla ricevente sempre che non usi un misero pulsein :roll_eyes:

inoltre prevederei uno switch per abilitare oppure non la comunicazione seriale che porta via un sacco di tempo, se uno vuole poi collegarlo alla GUI si mette su ON lo switch e così in volo non si rallenta il programma sbaglio forse?