Go Down

Topic: Official topic: multicotteri con arduino! (Read 362917 times) previous topic - next topic

FEDERICO

Come leggevo sul forum di baronerosso.it dove multiwii e' usato le informazioni di cui parliamo noi non arrivano all'esterno, quindi e' importante generare il wiki e magari aprire un canale di comunicazione con l'autore di multiwii per correggere il software alla luce delle indicazioni di astrobeed e le prove fatte. Per altro, se il codice di multiwii fa shifo, si potrebbe migliorare, proporlo o alla peggio, forkarlo. Per dire che oltre alla lamentela c'e' tutto un mondo quando si parla di free software  :smiley-mr-green:
Federico - Sideralis
Arduino &C: http://www.sideralis.org
Foto: http://blackman.amicofigo.com

astrobeed


assumerei la posizione attuale, come posizione 0;0 del piano cartesiano quindi:
x = longTarget - longAttuale
y = latTarget - latAttuale

quindi:
distanza = sqrt(x^2*y^2)


Sei totalmente fuori strada, magari fosse così semplice, prima di tutto longitudine e latitudine non sono ascissa e ordinata del piano cartesiano, sono una posizione angolare su uno sferoide, inoltre la distanza per ogni singolo grado non è una costante.

Quote

la distanza iniziale, non sara corretta, ed avrà un errore rilevante, ma ricalcolando la distanza, l' errore diminuisce, e siccome il tragitto effettivo, è maggiore di quello rettilineo calcolato, si arriverà ad un punto in cui il rov,


Esiste un principio fisico chiamato "propagazione degli errori" che inficia immediatamente il tuo ragionamento.


Scientia potentia est

FEDERICO

A proposito, sempre come idea GPS base, con un gps si potrebbe registrare tutto il viaggio che fa il velivolo e tenere una storia di dove hai volato, come diario di bordo. Che cosa romantica  :smiley-fat:
Federico - Sideralis
Arduino &C: http://www.sideralis.org
Foto: http://blackman.amicofigo.com

astrobeed


Per altro, se il codice di multiwii fa shifo,


Mai detto questo, ho detto che ci sono cose da rivedere, altre da modificare e migliorare, devo capire se vale la pena mettersi a correggere/modificare quel software oppure realizzarne uno nuovo, per il momento propendo più per la seconda.
Scientia potentia est

astrobeed


per quanto riguarda la lentezza, sinceramente per ora uso circa 7 o 8 classi, ma non ho assolutamente problemi di lentezza del codice, quindi non vedo perchè preoccuparsi (per ora).


La lentezza non dipende da quanti oggetti usi, questi semmai incidono sulla memoria usata, sia flash che ram, dipende da come devono essere gestiti a livello software di sistema, inoltre è wiring stesso ad usare gli oggetti.

Quote

per l'i2c ho notato che la wire è bloccante, e l'unico modo per non essere "bloccati" è usando gli interrupt (fornisce già le funzioni da "overridare")


Basta introdurre dei timeout senza scomodare gli interrupt, il blocco avviene perché le librerie usano un polling eterno sui flag della periferica e se c'è un intoppo non ne escono più.

Scientia potentia est

lestofante



assumerei la posizione attuale, come posizione 0;0 del piano cartesiano quindi:
x = longTarget - longAttuale
y = latTarget - latAttuale

quindi:
distanza = sqrt(x^2*y^2)


Sei totalmente fuori strada, magari fosse così semplice, prima di tutto longitudine e latitudine non sono ascissa e ordinata del piano cartesiano, sono una posizione angolare su uno sferoide, inoltre la distanza per ogni singolo grado non è una costante.

Quote

la distanza iniziale, non sara corretta, ed avrà un errore rilevante, ma ricalcolando la distanza, l' errore diminuisce, e siccome il tragitto effettivo, è maggiore di quello rettilineo calcolato, si arriverà ad un punto in cui il rov,


Esiste un principio fisico chiamato "propagazione degli errori" che inficia immediatamente il tuo ragionamento.



togliete quetse formule dal playground prima che qualcuno le usi e magari si faccia pure male...
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

milvusmilvus

secondo me sul playground andrebbero messi progetti ga completati, o per lo meno  testati, quello che ho postato io, era un idea, un abbozzo che ho posto alla vostra attenzione

riguardo latitudine e longitudine, non sono ascissa e ordinata, ma il loro funzionamento è simile.

prova ad eseguire in maniera "automatica" quel algoritmo, e vedi che funzionalmente dovresti avere dei risultati forse però conviene che invece di calcolare la distanza per fermarsi, conviene cerificare che latitudine e longitudine rientrino entro un certo range di valori rispetto al target.

mi puoi dire che idea hai tu sul come implementare il sistema, senza avere limiti di potenza di calcolo, vorresti per carso calcolare la curva che unisce il punto di partenza e quello di arrivo, poi come faresti a farla rispettare al rov? controlleresti che ogni punto di rilevamento delle coordinate sia sulla curva? e in caso di errore ricalcoli l' itinerario?? secondo me avresti lo stesso problema che cercare di eseguire una traettoria rettilinea (ed obliqua tra i due punti, dovendo gestire potenza dei motori per lo spostamento in avanti, e per variare la quota)

non so magari il metodo è piu semplice o piu complesso, ma a me per ora sono venute in mente solo queste 2 idee, comunque domani, provero il mio algoritmo, con il gps in mano una calcolatrice ed una bussola.... e vedo se riesco ad arrivare ad un punto prefissato :D, sembrerò un pazzo che cammina in un campo con un gps in mano :D ma fa niente :D

lestofante

#352
Jul 30, 2011, 02:34 am Last Edit: Jul 30, 2011, 02:37 am by lesto Reason: 1
no, se ho capito bene il metodo è sbagliato perchè tu usi quei dati come coordinate cartesiane, ma in realtà sono coordinate sferiche (polari se in 2d).
in pratica nelle cartesiane usi X e Y, nelle sferiche usi distanza e angolazione (rispetto all'asse delle ordinate)

quì trovi una lettura sia su poliari che sferiche. http://it.wikipedia.org/wiki/Sistema_di_coordinate_polari.
per ottenere X, Y e Z, devi fare:
X = distanza*seno A*coseno B
Y = distanza*seno A*seno B
Z = distanza*coseno A

poi in realtà c'è anche una difficoltà aggiunta, non so bene da cosa... ecco uno spunto: http://usenet.it.rooar.com/showthread.php?t=4452133
e quì un pò di esempi concreti in pseudocodice: http://williams.best.vwh.net/avform.htm

Quote
secondo me sul playground andrebbero messi progetti ga completati, o per lo meno  testati, quello che ho postato io, era un idea, un abbozzo che ho posto alla vostra attenzione

approvo alla grande, per sprerimentare c'è il forum
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

astrobeed

#353
Jul 30, 2011, 08:56 am Last Edit: Jul 30, 2011, 09:39 am by astrobeed Reason: 1

per ottenere X, Y e Z, devi fare:
X = distanza*seno A*coseno B
Y = distanza*seno A*seno B
Z = distanza*coseno A


Decisamente meglio, ma ancora non ci siamo  :)
Inoltre c'è sempre il piccolo problema che in questi conti manca il punto di riferimento e che la distanza che intercorre tra due coordinate con eguale differenza non è una costante, vi ho già detto di guardare un mappamondo e di osservare come cambiano gli spicchi inclusi tra due paralleli e due meridiani al variare di latitudine e longitudine.
Tra oggi e domani, più domani, vi posto io tutta la parte matematica necessaria già semplificata per l'uso sulle piccole distanze (15-20 km) grazie al "trucco" di usare come riferimento dei valori presi da una LUT in funzione della latitudine.
Piccolo dettaglio, la sola LUT occuperebbe quasi tutta la flash di un ATmega328, sono quasi 29 kByte

Quote
secondo me sul playground andrebbero messi progetti ga completati, o per lo meno  testati, quello che ho postato io, era un idea, un abbozzo che ho posto alla vostra attenzione


Concordo, sul playground vanno messe solo le cose già analizzate a fondo e confermate, p.e. la questione collegamenti I2C con le relative pull up, le warning sulla tensione di alimentazione e su come mischiare, se necessario, device a 3.3V e 5V sullo stesso bus.
Scientia potentia est

superlol

io penso che il playground serva anche a tenere uina traccia di ciò che si fa, non solo progetti finiti ma anche in evoluzione in quanto le cose andrebbero perse nel topic e ritrovarle sarebbe difficile.

la questione su resistenze di pullup WMP e alimentazione l'ho messa se guardate, mancano tutti gli altri sensori  XD
http://www.aug-altogarda.it/ <- Il nuovo AUG per basso trentino e dintorni!

astrobeed


io penso che il playground serva anche a tenere uina traccia di ciò che si fa, non solo progetti finiti ma anche in evoluzione in quanto le cose andrebbero perse nel topic e ritrovarle sarebbe difficile.


L'evoluzione va bene, magari specificando che si tratta di versioni alfa/beta dell'eventuale software, di test/prototipi per l'hardware e di informazioni parziali e/o da verificare per la parte teorica.

Quote

la questione su resistenze di pullup WMP e alimentazione l'ho messa se guardate, mancano tutti gli altri sensori  XD


Vista, c'è da aggiustarla, la foto la faccio io sul mio WMP evidenziando meglio i vari contatti/cavi, così evitiamo di usare le solite immagini che si trovano sul web
Scientia potentia est

superlol

perfetto, io non avevo il mio sotto mano per quello l'ho presa da internet.

Comunque come ho detto sentitevi liberi anzi obbligati di modificare quello che volete  ;)
http://www.aug-altogarda.it/ <- Il nuovo AUG per basso trentino e dintorni!

ratto93

#357
Jul 30, 2011, 12:12 pm Last Edit: Jul 30, 2011, 12:14 pm by ratto93 Reason: 1
Scusate ancora se rompo riguardo l'MCU... questa andrebbebene ?
http://shop.pinguino.cc/index.php?route=product/product&product_id=50
usa lo stesso identico linguaggio di arduino....
Oltretutto è open-suorce e open-hardware ... e costa molto poco....
Se corri veloce come un fulmine, ti schianterai come un tuono.

milvusmilvus


no, se ho capito bene il metodo è sbagliato perchè tu usi quei dati come coordinate cartesiane, ma in realtà sono coordinate sferiche (polari se in 2d).
in pratica nelle cartesiane usi X e Y, nelle sferiche usi distanza e angolazione (rispetto all'asse delle ordinate)

quì trovi una lettura sia su poliari che sferiche. http://it.wikipedia.org/wiki/Sistema_di_coordinate_polari.
per ottenere X, Y e Z, devi fare:
X = distanza*seno A*coseno B
Y = distanza*seno A*seno B
Z = distanza*coseno A

poi in realtà c'è anche una difficoltà aggiunta, non so bene da cosa... ecco uno spunto: http://usenet.it.rooar.com/showthread.php?t=4452133
e quì un pò di esempi concreti in pseudocodice: http://williams.best.vwh.net/avform.htm

Quote
secondo me sul playground andrebbero messi progetti ga completati, o per lo meno  testati, quello che ho postato io, era un idea, un abbozzo che ho posto alla vostra attenzione

approvo alla grande, per sprerimentare c'è il forum


si ma io la "lunghezza dei cateti" la so in base alla differenza delle coordinate, a me serve sapere di quanto devo ruotarmi, per trovarmi rivolto verso il target

astrobeed


Scusate ancora se rompo riguardo l'MCU... questa andrebbebene ?


E' la brutta copia delle chipKIT di Digilent, decisamente meglio gli originali  :)
Per quanto riguarda il discorso potenza di calcolo, si un PIC32 è idoneo per la navigazione real time con GPS, potrebbe esserci il problema ingombro per mettere sul multicoso una scheda aggiuntiva grande come una UNO.
Verso fine della prossima settimana mi arriva una chipKIT Max32, l'equivalente a 32 bit della MEGA2560, così vediamo quali sono i reali problemi di compatibilità software con Arduino, l'ultima release dell'IDE per questa scheda ha corretto svariati bug e incompatibilità rilevate dagli utenti.
Scientia potentia est

Go Up