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

[astrobeed]

cioè, mettendo il multiwii su quella scheda STM32 ci si accorgerebbe dell'hardware più potente?

Non ci metti Multi"nonsisacosa"Wii, ci metti un software per SMT32, p.e. quello della MultiPilot32 previo adattamento a questa scheda.

[cavde]

Non ci metti Multi"nonsisacosa"Wii, ci metti un software per SMT32, p.e. quello della MultiPilot32 previo adattamento a questa scheda.

c'è tanta differenza tra la scheda multipilot32 e quella che hai postato tu?

[lestofante]

che esita una libreria già fatta e open fa tantssimo piacere, ma ciò non prova che l'accoppiata sensori + libreria sia ottimale a quello che vogliamo fare.

Guarda i video di ST relativi alla sensor fusion dei loro sensori che poi ne riparliamo 
Comunque 1000 Hz sulla IMU sono un'utopia con i sensori di Invensense, è grasso che cola se arrivi a 150-200 Hz reali, stessi valori che ottieni con i sensori di ST.

io guardo i valori da datasheet (e via i2c ho toccato oltre 1kHz), poi come trovare i valori reali tra quello che leggo non ho idea

Non ci metti Multi"nonsisacosa"Wii, ci metti un software per SMT32, p.e. quello della MultiPilot32 previo adattamento a questa scheda.

c'è tanta differenza tra la scheda multipilot32 e quella che hai postato tu?

il procio è un STM32F1 contro un STM32F3, diciamo che c'è abbastanza differenza ma non troppa. un pò come tra un atmega8 e uno atmega328 moltiplicata per la complessità aggiuntiva di un procio a 32bit.

[astrobeed]

io guardo i valori da datasheet (e via i2c ho toccato oltre 1kHz), poi come trovare i valori reali tra quello che leggo non ho idea

Un conto è la velocità di comunicazione sul bus, ed è un bene che sia la maggiore possibile, e un conto è la reale frequenza con cui ottieni nuovi dati validi, il parametro DLPF_CFG, parliamo di ITG3200, ti permette di settare un rate massimo di 256 Hz con 8ksps interni, in realtà è meglio lavorare a 188 Hz se vuoi letture veramente stabili.

Edit: da notare che il sample rate in uscita del L3GD20 arriva fino a 790 Hz, cioè è nettamente maggiore di quello del ITG3200, però anche in questo caso è sicuramente meglio utilizzare il primo valore inferiore che è un ragguardevole 380 Hz.
Ovviamente tocca fare dei test reali per stabilire quale dei due sensori è migliore, cosa che per il momento non posso fare perché non ho a disposizione il sensore di ST, però non appena sono disponibili le STM32F3 Discovery la prendo e potrò fare tutte le prove e misure del caso.

[cavde]

il procio è un STM32F1 contro un STM32F3, diciamo che c'è abbastanza differenza ma non troppa. un pò come tra un atmega8 e uno atmega328 moltiplicata per la complessità aggiuntiva di un procio a 32bit.

quindi quando verrà commercializzata questa F3, bisogna fare un software adatto all'architettura del processore, o un porting da un software già esistente....quello che mi interessa è appunto se c'è qualcuno che svilupperà qualcosa con questa scheda, perchè al momento io non sarei capace

[astrobeed]

quindi quando verrà commercializzata questa F3, bisogna fare un software adatto all'architettura del processore, o un porting da un software già esistente....

Si possono fare tutte e due le cose, ovviamente si fa molto prima a fare il porting del software della Multipilot32, per uno esperto e che conosce già il software dovrebbero bastare pochi giorni per farlo, toccherebbe sentire Roberto (Redfox74), che fa parte del team di sviluppo, quali potrebbero essere i problemi a cui si va incontro.

[cavde]

tutto chiaro per adesso!!! grazie
non resta che aspettare la vendita

[astrobeed]

Ho dato una sbiriciatina al sito di Drotek, la loro IMU con  gli stessi sensori della STM32F3 Discovery costa 37 Euro
Da notare che i sensori di ST costano meno di quelli di Invensense e di Analog.

[sciorty]

Chiedo scusa ma vorrei una delucidazione.
Ho scaricato lo sketch multiwii da caricare sull'arduino giusto per dargli un'occhiata. devo essere sincero ma pensavo che l'occhiata sarebbe diventata un'esitazione alla scritturo di un codice (perchè no) magari mio, e invece sembra a me leggibile

Ma arrivo al dunque, ho visto che ad ogni motore si assegna un valore che arriva a 2000,

Code: [Select]

motor[FRONT] = 1500 + rcCommand[THROTTLE] - axisPID[PITCH] ;
per poi essere riportato massimo a 255 cioè il massimo valore ammissibile per il pwm(per pilotare l'ESC, no?).

Code: [Select]

analogWrite(FRONT_PIN, motor[FRONT]>>3);
Perchè questo e sopratutto perchè usare il bitshift e non una proporizione?


Un'altra cosa,
Ci tenevo particolarmente a scrivere del codice perchè altrimenti il progetto non mi darebbe molte soddisfazioni.. cioè una qualcosina fatta ad hoc!
Ho visto che il codice multiwii è molto corposo anche perchè è in grado di gestire diverse configurazioni. Secondo voi sarebbe quindi troppo difficile scrivere un codicino? Niente di particolare, nessuno UAV, solo un qualcosa che mi permetta di farlo alzare e girare senza nessuna particolare stabilità!
Ovviamente prima caricherei sull'hardware il multiwii, ma poi..? Qualcuno ci è già riuscito? No perchè se non ci siete riusciti voi.. 
Se usassi degli xbee al posto della trasmittente classica? Collegherei un joystick della playstation al pc che elabora tramite python e invia a bordo i dati già pronti degli stick, senza dover smanettare sui PPM della ricevente. I canali sarebbero molti di cui 4 per gli stick, che sono l'indispensabile no?

Grazie, ma sto solo valutando l'idea

[lestofante]

1500 circa è il valore di metà stick (in millisecondi), a cui somma le varie componenti (sempre in millisecondi)

poi usa il bitshift perchè è molto più veloce della proporzione.

Quello che vuoi fare è fattibile, se studi il codice del multiwii non so, ma di quello aeroquad trovi sul loro repositori la versione in lavorazione che vedrai è divisa in tante piccole compoenti, che poi vengono unificate solo alla fine. In questo modo puoi partire a modificare solo la parte che ti interessa.

[sciorty]

Grazie, allora vedrò anche quello

Avevo già chiesto qualcosina riguardo la logica di stabilizzazione e mi avevi parlato di PID però ora che ho capito più o meno cos'è mi viene spontanea una domanda: Se alla fine il PID diventa un valore che vado ad aggiungere o sottrarre alla "velocità" dei motori, e quindi indica quanto agire sui motori, non potrei semplicemente agire sui motori fino a quando la posizione attuale è uguale a quella voluta?
Mi spiego meglio: Giro a destra di X con lo stick, ricevuto il segnale so che il mezzo deve avere inclinazione X e quindi con il PID so quanto agire sul motore per ottenere l'inclinazione.
Non potrei invece: Giro a destra di X stick, ricevuto il segnale so che il mezzo deve avere inclinazione X e quindi inclino il mezzo fino a quando il giroscopio mi dice che l'inclinazione è stata ottenuta?

Poi un'altra cosa, dove trovo un qualche link utile riguardo i movimenti che devono fare i motori per andare avanti, indietro, ruotare su se stesso ecc?

[lestofante]

studiati bene come funziona il pid e ne riparliamo. per il movimento dei motori basta un minimo di logica.

[sciorty]

Un'idea di come si muova ce l'ho, volevo solo vedere se fosse giusta :\
Studierò il PID, però lasciandolo un attimo da parte, perchè non si può usare quel metodo?

[lestofante]

si tratta di un gioco di inclinazione di vettori per il movimento, e di inierzia angolare per le rotazioni sul posto.

[FEDERICO]

EuHM... ho montato come sono riuscito questo coi i primi video di un anno fa... :-)

http://www.youtube.com/watch?v=y21jatFRLok