voglio dire se comincia a diventare un ARM magari in package strani da 200 pin diventa complicato l'uso per utenti normali e non super accessoriati... e per di più non è più arduino
Esistono molte board con ARM che costano relativamente poco e sono già dotate di tutto quello che serve per farlo funzionare. Ho già linkato a titolo d'esempio l'mBed che ha i connettori a passo 2.54 pertanto facilmente utilizzabile, oltretutto ha una filosofia di programmazione molto simile ad Arduino anche se non usa Wiring, ovvero non è necessario sapere esattamente come funzionano le periferiche interne e la miriade di registri macchina per farlo funzionare. Arduino ha i suoi limiti, la navigazione real time con GPS è uno di questi.
Fino a domani tarda mattinata sono incasinato con un lavoro che devo assolutamente finire, dopo vi passo la matematica di base necessaria per calcolare il vettore 3D, quindi modulo e due angoli, tra due coordinate GPS non sulla stessa quota, così finalmente vi rendete conto della quantità di calcoli e della loro complessità.
p.s. Anche volendo semplificare la cosa ragionando solo in 2D non è che cambia molto la complessità del tutto, per passare dal 2D al 3D finale basta applicare Pitagora.
Punto 7, nel caso in cui il concorrente, contro ogni previsione, sia ancora in vita dopo la soda caustica si può passare alla folgorazione finale tramite tesla coil da 10.000.000 di Volt, fulmini di qualche metro e barbecue garantito
Una cosa di questo tipo, però senza calzamaglia metallica messa a terra di protezione.
scusami ma quà non sono d'accordo. Il vantaggio delle classi, è che oltre a contenere funzioni possono contenere anche valori
Voglio sperare che non stai cercando di spiegare a me cosa sono e a cosa servono le classi ?
Quote
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.
Ecco qui ti sfugge completamente il senso della compilazione condizionale, che tra parentesi si usa anche in C++.
Quote
ma io sono un fan della programmazione ad oggetti (anche se un poco rallentano il codice)
Un poco ? Il peso, in termini di memoria usata, sia flash che ram, e di rallentamento velocità d'esecuzione è molto alto, sopratutto su una piccola MCU a 8 bit, e questo è uno dei motivi della lentezza di Wiring. Per lavorare in modo efficiente, parliamo di software di sistema e controllo di processo, su una piccola MCU, ma anche su un super micro, il solo ed unico linguaggio, a parte l'assembly, è, e almeno per il momento rimane, il C ANSI, tutto il resto è fuffa
Quote
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...
Ovvio che non ha senso spendere 10 Euro di corriere per 15-20 Euro di merce, però alla prima occasione metti in conto la sostituzione del Nunchuk con un normale accelerometro.
Quote
una cosa che non ho ancora capito è perchè hanno riscritto il protocollo i2c usando direttamente i registri...che gli costava usare la wire.h?
Non ho ancora approfondito il discorso I2C del MultiWii, ma credo abbia riscritto le routine per renderle più efficienti ed evitare alcune condizioni di blocco che ci sono nelle wire.h
Quote
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".
Il problema non è interpretare le sentenze NMEA, sono solo delle stringhe ASCII con un certo formato e i dati sono scritti in chiaro, ecco un esempio:
$GPRMC è l'identificatore della sentenza, ne esistono molti tipi diversi perché si usano anche per altra tipologia di strumenti. 151036.999 ora UTC (hhmmss.sss) A stato: A = Active, valido; V = Void, nullo 4536.81050 latitudine (ddmm.mmmmm) N N = nord; S = sud 00857.63140 Longitudine (dddmm.mmmmm) E E = est; W = ovest 0.09 Velocità in nodi 27.90 Direzione di movimento in gradi reali 260308 Data (ddmmyy) Variazione / Declinazione Magnetica in gradi (*) Versi della variazione / declinazione (*) A Tipo di rilevazione: A = Autonomous *5F Checksum
Alcuni campi possono non essere presenti, sono quelli vuoti tra le virgole, dipendono dalle caratteristiche tecniche del GPS, in pratica basta un parser per estrapolare in un vettore i dati reali che ci interessano. Il vero problema è tutta la parte matematica necessaria per calcolare la distanza tra due coordinate GPS e che, per via della risoluzione richiesta, è obbligatorio l'uso della matematica a 64 bit.
no, però non esiste un modo per sapere se la comunicazione seriale è stata stabilita, a meno che non si ricevano dati. In pratica non puoi sapere se dll'altra parte qualcuno ti sta ascoltando (al contrario del TCP o altri protocolli)
La seriale è un mezzo fisico, il TCP/IP è un protocollo, sono due cose molto differenti, il secondo si usa sul primo, per assurdo nulla vieta di utilizzare il TCP/IP con le comunicazioni seriali. Per sapere se una comunicazione è andata a buon fine con la seriale basta implementare un protocollo minimale, p.e. un semplice timeout entro il quale chi riceve i dati deve rispondermi con un "ok", è sufficiente anche un singolo carattere, se questo non avviene vuol dire che c'è stato un problema.
Perché mai dovrebbe essere un problema il fatto che AvrStudio prevede per l'STK500 solo 9 porte seriali (da COM1 a COM9) ? Se la nostra scheda con Com virtuale, ma anche fisica se è una scheda aggiuntiva su bus PCI, ha un numero maggiore di 9 basta andare nel pannello di controllo e cambiarlo con un numero che rientra nel range ammesso.
allora, se mi dai qualche output di esempio del gps (latitudine, longitudine etc..)
L'hai detto da solo, il GPS ti fornisce latitudine e longitudine, in più l'orario, la velocità e la quota, quest'ultima può avere grossi margini di errore. Non devi fare altro che ragionare sulle coordinate espresse come meglio preferisci, per fare i conti è sicuramente più pratico usare il formato in gradi con i vari decimali, almeno otto (matematica a 64 bit obbligatoria), piuttosto che il formato gradi, minuti, secondi e millesimi di secondi. Non ti scordare che al variare della latitudine e della longitudine cambia la distanza tra i meridiani i paralleli descrivono aree sempre più piccole andando verso i poli, buon divertimento Se non ti è chiaro il concetto osserva attentamente un mappamondo e guarda come cambiano gli spicchi compresi tra due meridiani e due paralleli.
p.s. 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
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.
Quote
comunque allora buttiamo giù qualche equazione per il GPS? io sono un novellino in questo campo, posso fare qualcosina sul codice ma non molto
E come intendi gestirlo il GPS ? Ovvero ti basta rimandare i dati a terra per visualizzare la posizione del multicoso su una mapppa tramite pc oppure vuoi implementare una vera e propria navigazione autonoma ? Nel primo caso non ci sono particolari problemi, nel secondo caso scordatelo di farlo con una MCU 8 bit qualunque essa sia, come minimo serve un dsPIC33, meglio ancora utilizzare un ARM di medio livello, p.e. un Cortex M3 sotto forma di modulo mBed.
Non oso pensare a quale probabilità esiste di trovare una lipo con questo difetto proprio quando si fa un test... va beh... la prossima volta controllero' meglio prima di collegare
In effetti è veramente un caso più unico che raro e un vero colpo di sfortuna, probabilmente se lo collegavi prima al caricatore te lo diceva lui che qualcosa non quadra, parto dal presupposto che hai un caricatore intelligente con display e equalizzatore integrato.
Non mi piace come è scritto il multiwii, tutto in un unico pde.... poteva creare un paio di classi, altro che mille define!
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..
Quote
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.
pin 8 ti dice il consumo, credo. butta fuori 377micro ampere per ogni ampere usato.(a 12 volt, quindi non usarlo)
Da quando una corrente ha una specifica tensione senza essere rapportata su una resistenza ? Quella è un'uscita che fornisce una piccola corrente proporzionale alla corrente che scorre sul motore, ci va collegata una opportuna resistenza per trasformarla in una tensione da misurare con un ADC, il valore della resistenza dipende dal fondo scala amperometrico e dalla tensione massima desiderata, p.e. 2650 (R con precisione 1%) ohm per un fondo scala di 5A con 5V out
Quote
pin 9 se diventa basso l'integrato sta scaldando troppo (12 Volt, occhio ad usarlo
Ma no, è un'uscita open drain, ci va una pull up che determina la tensione per il livello logico 1.
Quote
il pin PWM controlla la velocità. al 50% stai fermo, a 0% tutto inditro e al 100% tutto avanti. C'è anche una tabellina che ti mostra cosa succede quando freni/cambi direzione.
Vero al 50%, il 18200 si può usare sia un modo LAP che in modo S/M, nel primo modo si collega PWM a 1 logico fisso e si modula con il PWM DIR, nel secondo modo si collega il PWM a PWM e a seconda dello stato logico presente su DIR il motore gira in un senso o nell'altro.
Quote
Comunque è proprio al limite, io avrei preso qualcosa di più potente così sarei stato tranquillo che non scaldava troppo da andare in protezione termica.
Il 18200 regge 3A continui e fino a 6A di picco per 200 ms, se il motore è da 3A, e quasi sicuramente è la corrente di stallo/picco, non ci sono problemi per comandarlo tramite il 18200.
p.s.
IL 18200 può comandare un solo motore, per comandare due motori occorrono due 18200.
ma avrstudio non supporta arduinoisp come programmatore (a causa della configurazione limitata delle seriali, di avrstudio).
No, il problema è che l'implementazione del protocollo STK500 nello sketch ISP non è completa ed è questo il motivo per cui AvrStudio non può utilizzare Arduino come programmatore.
1 - prende la scossa a 380 (solo mezzo secondo, deve restare vivo per dopo ) 2 - da sotto la sedia parte il laser che gli fora le p.... 3 - da dietro la nuca accendi un accendino, meglio se del tipo al napalm 4 - sotto la sedia si apre la botola 5 - Arrivato giù trova l'alligatore o, se non vuoi essere brutale, l'antropofago che ti fai prestare dagli inglesi (in fondo per un gioco una libera uscita ad un'assassino si può anche dare )
Nel fortuito caso che il giocatore alla fine del trattamento sia ancora in vita si può prevedere il punto 6:
6 - Versare attraverso la botola 50 kg di soda caustica
Mi raccomando, fai presentare il gioco a Fiammetta Cicogna e usa come giocatori i suoi "tamarri"
Show Posts
)
)