astrobeed:
Premesso che pure a me non piace come è scritto MulitWii, ma per altri motivi, mi spieghi cosa c'entrano le classi col scrivere un programma diviso in più file ?
Guarda che nulla vieta di usare un file per ogni funzione con i relativi file.h, tecnica normalmente usata quando su un programma ci lavora più di una persona.
Lo stesso IDE di Arduino permette di dividere il programma in più file, cosa praticamente obbligatoria da fare quando lo sketch cresce troppo per via delle pesanti limitazioni dell'editor dell'IDE di Arduino, cosa a cui preferisco ovviare utilizzando un vero editor per programmatori esterno.
Per quanto riguarda le #define in buona parte servono per la compilazione condizionale, ovvero permettono di decidere quali parti del programma compilare in funzione dell'hardware utilzzato, pure queste non hanno nulla a che vedere con le classi e sono indispensabili, semmai poteva raggrupparle in un apposito file .h di definizione invece di lasciarle dentro il programma rendendolo ostico da leggere.io uso una classe per gestire i motori, contenuta nella classe del pid, poi una classe "stabilizzazione" che esegue l'algoritmo che contiene una classe IMU che legge i sensori, ed infine una classe che si occupa di leggere la radio tramite interrupt. ogni sensore/algoritmo di stabilizzazione/settaggio dei motori è (virtualmente, visto che per ora ce né solo una) una classe a parte. Il codice rimane molto più pulito e intercambiabile, e comunque un ciclo di aggiornamento dura meno di 2ms..
scusami ma quà non sono d'accordo. Il vantaggio delle classi, è che oltre a contenere funzioni possono contenere anche valori. In pratica sono una struct che oltre a contenere variabili, contiene anche funzioni (cosa possibilissima da fare in C usando puntatori a funzioni, credo che siano stati fatti proprio così i linguaggi ad oggetti...)
in oltre esiste una cosa chiamata ereditarietà ed overloading dei metodi. Per esempio, la mia classe astratta dei sensori non può essere usata (è astratta), ma può essere estesa. nell'estensione puoi scrivere tutto il codice che vuoi, ma sei costretto a fornire i metodi della classe astratta, ovviamente seguendo le linee guida contenute in essa. Quindi, nel mio caso, sei costretto a creare un metodo init() che eventualmente inizializza il sensore, un metodo update() che legge i volori dai sensori, e un metodo leggi() che ritorna un array di float dal sensore (come e cosa ci sia nell'array è una linea guida che varia dalla tipologia)
Il mio programma terrà la tua classe in una variabile di tipo superclasse astratta, quindi potrà usare solo i metodi che ti ho esplicitamente costretto a creare, ma questio metodi al loro interno potranno usare tutte le funzioni di classe. Quindi se vuoi cambiare un sensore, non modifichi le define, ma solo l'istanziamento della classe.
Così eviti tutta la storia della compilazione condizionale, anzi, se vuoi modificare un sensore, sai subito dove mettere le mani, anzichè impazzire in un pde chilometrico.
Poi ovvio che puoi usare le librerie, ma io sono un fan della programmazione ad oggetti (anche se un poco rallentano il codice)
astrobeed:
Quando finalmente riuscirò a fare il primo volo(cioè appena sistemo definitivamente il wmp+nunchuck) posterò tutto il codice.
Il mio consiglio è di lasciar perdere il Nunchuk come sensore accelerometrico, troppo bassa la risoluzione per essere realmente utile, con gli stessi soldi acquisti un sensore decisamente migliore e senza tutti i problemi di interfacciamento attraverso il WMP.
già, l'ho notato, ma è quello che ho in casa. E fare un ordine apposta spendo più dispedizione che di sensore. Certo ci fosse qualcosa che trovi al supermarket...
astrobeed:
superlol:
non per fare il pingolo ma le dev sono divise in diversi files ma poi nelle stable sono riuniti in uno per semplificare la vita poi a chi deve fare il quadri che non sempre è un esperto di arduino-elettronica.Guarda che il problema del MultiWii non è come è suddiviso in file, è una questione secondaria, il vero problema è che ci sono molte cose che sono scritte alla come capita capita e/o di puro copia incolla preso dal web, p.e. il pid non è vero pid, il kalman è molto generico e poco efficace, e tante altre cosette.
Intendiamoci non intendo denigrare il lavoro dell'autore, anzi tutt'altro, però ci sono grossi margini di miglioramento per le prestazioni, zero margini per aggiungere nuove funzionalità perché siamo al limite della CPU.
una cosa che non ho ancora capito è perchè hanno riscritto il protocollo i2c usando direttamente i registri...che gli costava usare la wire.h?
Stamattina sono buono, ricordati che le coordinate GPS sono referenziate ad un determinato modello geodetico, quindi per poterle utilizzare devi tenere conto anche del modello su cui lavorano.
Se pensi che determinare la distanza tra due coordinate GPS, anche di punti vicini, sia una cosa semplice e che esiste una formuletta semplice per farlo allora non sai in guaio ti stai cacciando smiley-grin
pensavo ad un atmega solo per il GPS... però devo ammettere che ancora non ho iniziato nemmeno a spulciare il protocollo e la sua "traduzione". Quando sarà tempo (ovvero il quad vola, con magnetometro e barometro che ancora devo comprare e implementare) sicuramente ci sbatterò la testa, e se ardino dovesse fallire (e le finanze lo permetteranno :P) mi prenderò volentieri qualcosa di superiore come il dsPIC33 o (non vedo l'ora) un'ARM.