Official topic: multicotteri con arduino!

International Italiano Generale
#501

ma voi state contando solo i PBC o anche i costi di assemblaggio degli SMD? Perché a questo punto arduino, i sensori e tutto il resto li fai in SMD (che dovrebbero costare anche meno). Però se pensi di assemblarli in casa, inizia a pensare anche al numero di resi... magari si possono fare due versioni, una totalmente SMD per il commercio, e una con il minimo assoluto di pezzi SMD (solo i sensori?) che non viene venduta, ma uno si scarica il file e se la fa da solo..

Però non so un bromografo da casa che precisione ha, credo che dipenda solo fino ad un certo punto dalla qualità della stampa.

#502

Oppure si può pensare di fare fare il PCB ed anche montare i componenti da Seeedstudio.... sono cinesi ma fanno a dovere il loro lavoro... ho un paio di loro oggettini e vanno alla perfazione e la fattura è davvero buona....

#503

ratto93: Oppure si può pensare di fare fare il PCB ed anche montare i componenti da Seeedstudio.... sono cinesi ma fanno a dovere il loro lavoro... ho un paio di loro oggettini e vanno alla perfazione e la fattura è davvero buona....

la commercializzazione è l'ultimo dei problemi, prima direi che ci serve un hardware e un software prima di produrre una scheda ;)

quindi attendiamo astrobeed che metta giù i primi sistemi di equazioni che poi provvederemo a risolvere :P

#504

L'eventuale realizzazione di una scheda dedicata all inclusive è da prendere in considerazione solo dopo aver realizzato almeno una beta funzionante del software provata su hardware normale, adesso è prematuro parlarne. Non scordatevi che tutti i sensori sono in case qfn, praticamente impossibili da saldare in da soli senza disporre almeno di un forno preriscaldante e una stazione ad aria, e tocca pure saperlo fare altrimenti fate una bella frittura mista da qualche decina di Euro.

#505

superlol:

ratto93: Oppure si può pensare di fare fare il PCB ed anche montare i componenti da Seeedstudio.... sono cinesi ma fanno a dovere il loro lavoro... ho un paio di loro oggettini e vanno alla perfazione e la fattura è davvero buona....

la commercializzazione è l'ultimo dei problemi, prima direi che ci serve un hardware e un software prima di produrre una scheda ;)

quindi attendiamo astrobeed che metta giù i primi sistemi di equazioni che poi provvederemo a risolvere :P

Non volevo insinuare che si potrebbero commercializzare... ma solo che se ci servono a noi che li andremo a testare dei prototipi a basso costo andrebbe preso in considerazione seeedstudio tutto la... proprio per il fatto che questi micro sono in formati inutilizzabili a livello hobbistico...

#506

flameman: ho appena finito di far cuocere la scheda del dsp per la parte di componentistica che riportava Lead Temperature (Soldering, 10 seconds): 300°C 2 tqfp 44 2 tqfp100 12 ssop16 6 ssop8 4 TDFN (che sarebbe simile al soic, ma con i piedini tutti sotto) un paio di bga (particolarmente fastidiosi) e poco altro (escluso il masterista, e i suoi pbc) solo di saldature speso 110 euro

il kernel minimale che si e' confezionato per la scheda in questione permette una programmazione concorrenziale pthread posix facilitando la stesura, la modellazione, ed il controllo delle parti algoritmiche

tutto il design, sia hw che sw, e' a memoria condivisa

e il bello e' che il tutto compila su un host unix e si porta "quasi indolore" sul target

il prossimo passo sara' portare il target sull'host, cioe' aggiungere un cortex a9 linux/glibc porte usb da sfruttare fullspeed endpoint bulk urb dma (concentratore di dati sensori, sfruttando l'usb bus tree perennemente in full bulk) e addirittura un bus pcie cui appoggiare un modulo radio wifi (tanto ce l'ho gratis, e' gia' integrato, quindi si usa, anche se non hotplug)

l'ultimo passo sara', per motivi lavorativi, gia' che ci sono sperimentare un p2020 (dual dual core) al posto dell cortex a9 configurazione smp, o amp, poi vedro'

costo del tutto ? + o - un 2000 euro ripescando una scheda di sviluppo freescale

cioè stai usando un linux embedded? ti rende comodo per la questioni PCI (che non capsico che fai del wifi visto che ti servirebbero antenne direzionali per arrivare alle distanze che noi vogliamo anche se sarebbero infinite le nostre, dettate dalla durata della batteria) ma da quello che so un kernel rallenta il tutto (moooolto male), poi utilizzi processori potenti? consumi?

noi vogliamo creare macchine che volino più a lungo possibile il che implica massima leggerezza (il modello di astro è previsto sugli 800g fai tu..) dimensione contenute (io ho un 50cm interasse motori) che sia realizzabile da tutti con non troppi soldi almeno la parte base per cui un atmega un quarzo da 20MHz e un connettore per la programmazione via FTDI è fattibile da quasi tutti su millefori, poi sarà invece da far stampare e distribuire la parte gps ed avrà alti costi ma per ora è l'ultimo dei pensieri.

secondo me arrivi troppo alto coi consumi nella tua scheda (noi in tutto avremo circa 30mah nemmeno di assorbimento tra sensori e tutto, tu se già metti un dual core serve una batteria solo per quello ;))

almeno è quello che penso, anche io volevo optare per un linux embedded ma alcune persone sull'altro forum mi hanno fatto cambiare idea...

#507

superlol: almeno è quello che penso, anche io volevo optare per un linux embedded ma alcune persone sull'altro forum mi hanno fatto cambiare idea...

Infatti nella parte low lovel dei sistemi di controllo nessuno usa un sistema operativo come Linux, al massimo un RTOS, ultraleggero, specifico per la MCU in uso. Linux, Windows CE, QNX, giusto per citare i più utilizzati in ambiente embedded, hanno un senso su una SBC (Single Board Computer) dove c'è come minimo un ARM9 da 200 MHz con almeno 8 mega di flash e altrettanta ram, cioè un oggetto che va benissimo per gestire una comunicazione TCP/IP, porte USB etc, non va per niente bene per gestire un controllo low level come la gestione dei motori tramite pid e l'interpretazione dei dati di una IMU, per queste cose si utilizzano MCU dedicate. Sotto il profilo consumi una SBC non è molto esosa, ne ho una nel cassetto che monta un processore GEODE LX800 (x86), dimensioni 80x100mm, perfettamente in grado di far girare Linux o XP, compresa la ram da 512 Mega, una C.F. da 8 giga consuma mediamente meno di 1A a 12V, cioè poco meno di 12W, non è poco rapportato al consumo medio generale del quadricottero, però è accettabile se serve molta potenza di calcolo in volo.

#508

Mi spiace ma con + o - 2000 euro mi faccio la patente e mi compro la macchina e forse me ne avanzano :P

#509

ratto93: Mi spiace ma con + o - 2000 euro mi faccio la patente e mi compro la macchina e forse me ne avanzano :P

Non ci faremo carico dei tuoi problemi di adolescenza! ]:D

Scherzoni a parte... Va definito se quello che nasce dall'interesse per questo topic e' hobbystico o professionistico. Secondo me la quasi totalita' dei partecipanti segue e partecipa al discorso per hobby, e forse qualcuno puo' averne un ritorno economico. Quindi, pensando di progredire su un piano comune io scarterei alcune problematiche troppo evolute da un discorso di gruppo...

#510

Federico:

ratto93: Mi spiace ma con + o - 2000 euro mi faccio la patente e mi compro la macchina e forse me ne avanzano :P

Non ci faremo carico dei tuoi problemi di adolescenza! ]:D

Scherzoni a parte... Va definito se quello che nasce dall'interesse per questo topic e' hobbystico o professionistico. Secondo me la quasi totalita' dei partecipanti segue e partecipa al discorso per hobby, e forse qualcuno puo' averne un ritorno economico. Quindi, pensando di progredire su un piano comune io scarterei alcune problematiche troppo evolute da un discorso di gruppo...

confermo o ho un massimo di soldi da spendere in questa applicazione che sarà destinata all'uso con gopro (telecamera quindi) e ora circa ce la fa a tenerla, però se vi è la possibilità di maggior controllo volentieri direi, anzi subitoooo.

ora visto che vola avrò un piccolo finanzioamento che userò per comprare la freeIMU che ordinerò non appena arriveranno i soldi :P

#511

@flameman: superlol ha parlato di una discussione dove si è arrivati a delle stesse conclusioni. Ovvero: usare unix per la stabilizzazione impiega troppa latenza, e modificare il kernel porta vari possibili problemi di piantamento del sofware, che già è complesso di suo. Seguendo il ragionamento di "cio che non c'è non si può rompere/impallare", supporto l'idea di usare un micro che si occupi semplicemente della stabilizzazione, comandato da un sistema più complesso (unix o quant'altro), che se anche si mette a fare stream video, o si impalla da qualche parte, non pregiudica la "vita" del mezzo.

ora non la trovo, sinceramente non ricordo nemmeno se era su questo forum

#512

Il che significa che svilupparai l'interfaccia multiwii - freeIMU ?

#513

c'è assolutamente da modificare la wire, oggi sto facendo un po' di prove col WMP... leggere 6 byte da seriale: 16microsec elaborali in rad/sec: 108microsec codice che segue (richesta prossimo dato): 1005microsec!!!

Wire.beginTransmission(0x52);
  Wire.send(0x00);
  Wire.endTransmission();
  Wire.requestFrom (0x52,6);
#514

lesto: c'è assolutamente da modificare la wire, oggi sto facendo un po' di prove col WMP...

Per questa applicazione la wire la puoi pure buttare in quel posto dove ci sediamo tutti quanti almeno una volta al giorno :) Tocca riscriverla completamente.

#515

me ne sono accorto.. ora devo andar a dare da mangiare alle anatre (!), più tardi gioco con le funzioni usate dal multiwii:

// ************************************************************************************************************
// I2C general functions
// ************************************************************************************************************

// Mask prescaler bits : only 5 bits of TWSR defines the status of each I2C request
#define TW_STATUS_MASK  (1< prescaler = 1
  TWBR = ((16000000L / I2C_SPEED) - 16) / 2; // change the I2C clock rate
  TWCR = 1<0 && !(TWCR & (1< we don't insist
    TWCR = 0;  //and we force a reset on TWINT register
    neutralizeTime = micros(); //we take a timestamp here to neutralize the value during a short delay after the hard reset
  }
}

void checkStatusI2C() {
  if ( TW_STATUS  == 0xF8) { //TW_NO_INFO : this I2C error status indicates a wrong I2C communication.
    // WMP does not respond anymore => we do a hard reset. I did not find another way to solve it. It takes only 13ms to reset and init to WMP or WMP+NK
    TWCR = 0;
    if (!GYRO) {
      POWERPIN_OFF //switch OFF WMP
      delay(1);  
      POWERPIN_ON  //switch ON WMP
      delay(10);
      WMP_init(0);
    }
    neutralizeTime = micros(); //we take a timestamp here to neutralize the WMP or WMP+NK values during a short delay after the hard reset
  }
}

void i2c_getSixRawADC(uint8_t add, uint8_t reg) {
  i2c_rep_start(add);
  i2c_write(reg);         // Start multiple read at the reg register
  i2c_rep_start(add +1);  // I2C read direction => I2C address + 1
  for(uint8_t i = 0; i < 5; i++) {
    rawADC[i]=i2c_readAck();}
  rawADC[5]= i2c_readNak();
}

void i2c_writeReg(uint8_t add, uint8_t reg, uint8_t val) {
  i2c_rep_start(add+0);  // I2C write direction
  i2c_write(reg);        // register selection
  i2c_write(val);        // value to write in register
}

uint8_t i2c_readReg(uint8_t add, uint8_t reg) {
  i2c_rep_start(add+0);  // I2C write direction
  i2c_write(reg);        // register selection
  i2c_rep_start(add+1);  // I2C read direction
  return i2c_readNak();  // Read single register and return value
}

per esempio waitTransmissionI2C è bloccante, fa un reset di twint, ma non ho capito 1: perchè l'if (count<2) (notare il ; dopo il while, quindi l'if è fuori dal corpo di esso. 2: se fa quel reset, non deve reinizializzare la comunicazione?

devo ancora leggermi bene tutto il codice per capire come funziona questo protocollo, però piuttosto che fare una wait transmission alla fine, non conviene farla all'inizio (se la flag che sono stati inviati dati è settata a true)? in questo modo si rimarrebbe bloccati molto meno tempo. per il resto devo ancora leggere bene, mi sembra ok(ricordo che NON conosco il protocollo i2c)

#516

Stasera assemblo la IMU completa (giro,accelerometro,magnetometro,barometro) così da iniziare a scrivere i primi mattoni del software.

Step 0, definizione della struttura base del programma e inizializzazione dei vari file. Step 1, funzioni I2C ottimizzate. Step 2, funzioni per la lettura dei sensori che compongono la IMU. Step 3, funzioni di base per la telemetria. Steo 4, prima GUI semplificata per la verifica dei dati tramite telemetria. Step 5, Kalman e funzioni per la determinazione assetto.

Solo per questi punti ci vorranno diversi giorni di lavoro, però sono la base per sviluppare il tutto, senza questi non si va da nessuna parte.

#517

lo schema base potrebbe essere

aggiorna sensori se aggiornati leggi sensori aggiorna orizzonte (kallman?) leggi input RX aggiorna PID (con input RX e orizzonte) aggiorna motori (con valori PID) se ci sono dati disponibili in seriale esegui funzione di comunicazione (lettura sempre, scrittura ad 1Hz) se è in debug_mode se è trascorso abbastanza tempo (50 o 60Hz) stampa angoli di inclinazione attuali(per debug grafico)

#518

astrobeed: Stasera assemblo la IMU completa (giro,accelerometro,magnetometro,barometro) così da iniziare a scrivere i primi mattoni del software.

Step 0, definizione della struttura base del programma e inizializzazione dei vari file. Step 1, funzioni I2C ottimizzate. Step 2, funzioni per la lettura dei sensori che compongono la IMU. Step 3, funzioni di base per la telemetria. Steo 4, prima GUI semplificata per la verifica dei dati tramite telemetria. Step 5, Kalman e funzioni per la determinazione assetto.

Solo per questi punti ci vorranno diversi giorni di lavoro, però sono la base per sviluppare il tutto, senza questi non si va da nessuna parte.

mi raccomando documenta tutto nel playground e passa il link che vogliamo essere partecipi (tutti o sicuramente io :P )

poi dicci se incontri difficoltà, il perchè di certe scelte se hai tempo così impariamo qualcosa anche noi comuni mortali :)

inoltre che scheda usi alla fine che non ho capito?

#519

superlol:

astrobeed: Stasera assemblo la IMU completa (giro,accelerometro,magnetometro,barometro) così da iniziare a scrivere i primi mattoni del software.

Step 0, definizione della struttura base del programma e inizializzazione dei vari file. Step 1, funzioni I2C ottimizzate. Step 2, funzioni per la lettura dei sensori che compongono la IMU. Step 3, funzioni di base per la telemetria. Steo 4, prima GUI semplificata per la verifica dei dati tramite telemetria. Step 5, Kalman e funzioni per la determinazione assetto.

Solo per questi punti ci vorranno diversi giorni di lavoro, però sono la base per sviluppare il tutto, senza questi non si va da nessuna parte.

mi raccomando documenta tutto nel playground e passa il link che vogliamo essere partecipi (tutti o sicuramente io :P )

poi dicci se incontri difficoltà, il perchè di certe scelte se hai tempo così impariamo qualcosa anche noi comuni mortali :)

inoltre che scheda usi alla fine che non ho capito?

Esatto... Noi neofiti io più di tutti dobbiamo e vogliamo imparare :P

#520

superlol:
mi raccomando documenta tutto nel playground e passa il link che vogliamo essere partecipi (tutti o sicuramente io :stuck_out_tongue: )

Sono allergico all’editor del playground :slight_smile:
Il software è open source ed è mia abitudine commentarlo molto, le varie scelte e le soluzioni le discutiamo qui, serve un volontario che riporta le cose importanti sul playground e che scrive la documentazione estesa, quest’ultima non ho il tempo per farla io.

inoltre che scheda usi alla fine che non ho capito?

L’hardware è quello che ho già indicato, per la Fli.C una qualunque scheda UNO like, anche standalone, fino a salire alla Mega 2560, cosa sarà possibile fare solo con la UNO non posso dirlo adesso, ma di sicuro non meno di quello che fa MultiWii.
Per la IMU utilizzo tutti i sensori, sotto forma di singola breakout board, presenti sulla 9 d.o.f. di Sparkfun con in più il sensore di pressione BMP085, però per la prima stesura uso il WMP come giroscopio al posto del ITG3200 (al momento non l’ho disponibile), finiti i primi step integro anche l’ITG che mi dovrebbe arrivare la prossima settimana.