spacer.png, 0 kB

Torna indietro   Roboitalia.com - Il primo portale in Italia sulla robotica amatoriale > Progetti di Robot > Progettazione > Progetto robot MODDI (forum chiuso)

 
 
Strumenti discussione Modalitŗ† visualizzazioe
  #41  
Vecchio 14-09-2006, 08.49.29
L'avatar di sergio_camici
sergio_camici sergio_camici non è collegato
Administrator
 
Data registrazione: 24-05-2002
Residenza: Binasco (MI)
Etŗ†: 53
Messaggi: 2,665
Potenza reputazione: 298
sergio_camici La sua reputazione Ť oltre la sua famasergio_camici La sua reputazione Ť oltre la sua famasergio_camici La sua reputazione Ť oltre la sua famasergio_camici La sua reputazione Ť oltre la sua famasergio_camici La sua reputazione Ť oltre la sua famasergio_camici La sua reputazione Ť oltre la sua famasergio_camici La sua reputazione Ť oltre la sua fama
Predefinito

Citazione:
Orginalmente inviato da astrobeed
Che ci fai ?
Le interfacce USB presenti sui micro sono solo del tipo device, non possono fare da host, anche ammesso di usare un PC come cervello primario ti servirebbero tante porte USB quante sono le schede.
Per non parlare della difficolt√* di programmazione della USB, ti garantisco che non √® per niente semplice, per√≤ una volta che hai imparato ad usarla l'apprezzi.
Non ultimo il fatto che l'USB richiede un polling continuo e veloce, almeno 100 interrogazioni al secondo altrimenti vieni distaccato, questo comporta vari problemi nella stesura del firmware che deve essere multitasking quasi real time, non devono esserci delay troppo lunghi e tantomeno polling bloccanti.
Ok bocciata... in effetti le tue argomentazioni sono corrette, solo mi affascinava l'idea, ma non si adatta la progetto.
__________________
ciao
Sergio
---
Hai deciso di costruire un robot? Bene...
Cominciamo dalle brutte notizie: non e' facile...
  #42  
Vecchio 14-09-2006, 11.03.22
L'avatar di saveriop
saveriop saveriop non è collegato
Robottaro master
 
Data registrazione: 16-08-2005
Residenza: firenze
Etŗ†: 45
Messaggi: 428
Potenza reputazione: 78
saveriop E' una stupenda persona in cui credere
Predefinito

Faccio anche io il primo intervento avendo seguito con interesse.

Alla proposta di nonno, aggiungerei al messaggio anche un id messaggio che deve essere "ribattuto" nella risposta. Questo puo' essere un semplice progressivo gestito dal master.

Nel nostro caso specifico e' difficile che una stessa periferica abbia 2 messaggi pendenti a cui rispondere, pero' l'id facilita poi la gestione sul master (epia?) dei messaggi inoltrati.
  #43  
Vecchio 14-09-2006, 17.36.33
nonno_62 nonno_62 non è collegato
Robottaro sostenitore
 
Data registrazione: 25-11-2005
Residenza: sardegna
Etŗ†: 68
Messaggi: 572
Potenza reputazione: 77
nonno_62 E' un faro della comunitŗ
Predefinito

Non volevo rispondere ma non mi sono saputo trattenere .........

r2d2 .... facciamo così:

Definisci "analisi del sistema"! Elenca per noi poveri mortali cosa dobbiamo definire per pensare ad una rete e ad un sistema distribuito per un bot.

Poi andiamo avanti, ovviamente definando i parametri in base ad una analisi.

-------------------------------------

Ti sei domandato perch√® alla proposta di una base rotonda nessuno ha chiesto spiegazioni .... magari chi ha partecipato al discorso sa gi√* la risposta.

Cosa far√≤ quando la il display non ne vorr√* sapere? Intano credo/spero che ne vorra sapere, ma nella malaugurata ipotesi che non vada, prima ci sbattero il muso fino a rompermelo e poi chieder√≤ aiuto. Sperando di trovare gente che ha voglia di aiutarmi.

Mi √® gi√* successo di rinunciare come penso a tutti, per√≤ √® stata dura da mandare gi√Ļ ... quindi ......

Per ultimo, oviamente, non posso pensare di farmi cinque anni di universit√* per fare una rete per un bot, ma se cos√¨ deve essere dovr√≤ forzatamente rinunciare .........

Anche io quando mi diletto a fare qualcosa cerco di modificare piano piano ed una cosa alla volta (parlo anche di cose semplici ovviamente) però da qualche parte bisogna pure iniziare, o no?

---------------------

Per Astro:
E' ovvio che chi fa inesorabilmente finisce per essere criticato, ma sono sicuro che io avrei assorbito, le nozioni da te esposte, come una carta assorbente, nonostante i miei capelli bianchi. Inoltre le critiche servono se sono costruttive e documentate, altrimenti si possono ignorare, le persone sterili non fanno figli (non vuole offendere nessuno che legger√* queste righe, ma credo che renda l'idea di cosa voglio dire).

L'avevo anche detto in un altro post, Mi sembra che astro abbia le idee chiare e che sia l'unico, quasi l'unico, che tiri avanti la baracca, che senso ha criticarlo, si può lavorare parallelamente e scambiarci nozioni, soluzioni e perchè no imparare dalle soluzioni dei diversi bot. Alla fine invece sia tu che self vi siete rotti e adesso guardate da lontano, e cosa ci abbiamo guadagnato .... io credo che ci abbiamo solo rimesso.

--------------------------------------------------

x Guiot
Come al solito sempre puntuale ..... dici di saperne poco, ma io non ci credo!

----------------------------------

x Saverioop
Credo sia una buona idea, se iusciremo a capire cosa dovr√* fare la rete


Ciao Nonno
  #44  
Vecchio 14-09-2006, 19.28.01
nonno_62 nonno_62 non è collegato
Robottaro sostenitore
 
Data registrazione: 25-11-2005
Residenza: sardegna
Etŗ†: 68
Messaggi: 572
Potenza reputazione: 77
nonno_62 E' un faro della comunitŗ
Predefinito

Mi sono riletto il post precedente e mi sono accorto che può sembrare polemico, ma lungi da me dal volerlo aver fatto.

Quello che volevo dire in relazione al progetto della rete è che non so cosa devo fare per realizzarlo.

O meglio si è definito che bisogna analizzare la rete, però io non so cosa significa? Non so quali sono i parameti o gli aspetti che bisogna conoscere per poi progettare la rete, io non lo so.

Chiedevo dunque di definire quali cose bisogna sapere per progettare la rete, e come utilizzare queste informazioni, e lo chiedevo anzi lo chiedo anche adesso a chi ne sa pi√Ļ di me, in modo di definire queste informazioni e poi poter progettare la rete, tutto online a beneficio di chi vuole imparare.

Saluti Stefano
  #45  
Vecchio 14-09-2006, 20.03.10
L'avatar di selfservice
selfservice selfservice non è collegato
Moderator
 
Data registrazione: 16-11-2003
Residenza: Foligno
Messaggi: 1,183
Potenza reputazione: 90
selfservice E' circondato da una spettacolare aurea
Invia un messaggio via MSN a selfservice
Predefinito

Citazione:
Orginalmente inviato da nonno_62
L'avevo anche detto in un altro post, Mi sembra che astro abbia le idee chiare e che sia l'unico, quasi l'unico, che tiri avanti la baracca, che senso ha criticarlo, si può lavorare parallelamente e scambiarci nozioni, soluzioni e perchè no imparare dalle soluzioni dei diversi bot. Alla fine invece sia tu che self vi siete rotti e adesso guardate da lontano, e cosa ci abbiamo guadagnato .... io credo che ci abbiamo solo rimesso.
finalmente qualcuno l'ha capito, se per√≤ continua di questo passo gi√* vedo come va a finire
__________________
Beatu chi lu pota, beatu chi lu zappa, na paralise secca a chi ce mette l'acqua!
  #46  
Vecchio 14-09-2006, 22.34.58
L'avatar di R2D2
R2D2 R2D2 non è collegato
Administrator
 
Data registrazione: 05-12-2002
Residenza: Milano - Corsico
Messaggi: 746
Potenza reputazione: 80
R2D2 E' per ora ancora un mistero
Predefinito

Nonno_62,
forse mi sono espresso male io ma non intendevo analizzare la rete. Se era quello il problema lo avremmo gia' fatto

Io credo che le specifiche per realizzare la rete (o meglio il protocollo di comunicazione) scaturiscano dall'analisi dell'architettura del robot.

Per architettura del robot intendo lo studio di quali saranno le parti che lo compongono e delle loro relazioni.
Il fatto di dire che avra' 5 schede dice poco. Bisogna vedere che schede sono. Quali sono i loro compiti. Di che cosa hanno bisogno per funzionare correttamente.

Per esempio la scheda controllo motori avra' bisogno che qualcuno gli dica il profilo del movimento. Che gli dica quando partire e quando fermarsi.

La scheda dell'IA (cito queste perche' le ho lette nei post precedenti) implementera' una logica di funzionamento ma avra' bisogno della scheda motori e di leggere i sensori. Ma la scheda dei sensori di cosa ha bisogno? etc.etc.

Una volta che sappiamo questo possiamo renderci conto se un bus e' la cosa migliore o magari, ipotizzo, e' conveniente avere due bus e suddividere le utenze. Etc.Etc.

Vabbe' adesso ricomincio daccapo. Io il mio suggerimento l'ho dato.
Se qualcuno ha voglia di parlarne trovera' sempre una mia risposta (spero in un thread piu' appropriato).
  #47  
Vecchio 15-09-2006, 09.02.03
L'avatar di saveriop
saveriop saveriop non è collegato
Robottaro master
 
Data registrazione: 16-08-2005
Residenza: firenze
Etŗ†: 45
Messaggi: 428
Potenza reputazione: 78
saveriop E' una stupenda persona in cui credere
Predefinito

La mia impressione e' che per un progetto che le caratteristiche di questo, non sia possibile, o almeno facile, definire a priori il tipo di dati che devono passare.

Questo perche' per sua stessa natura non e' un progetto organico ne' tantomeno strutturato come i tipici progetti in ambito business.

Infatti da questo punto di vista la cosa non va avanti. Il meglio che si puo' fare e' definire le caratteristiche massime e adattarci a quelle:

qual e' la funzione che attualmente stressa di piu' il bus? Tariamoci su quella e definiamo i messaggi in modo "aperto" come del resto gia' proposto da nonno. Ci sara' un'header del messaggio standard e una parte di rawdata che sara' specifica di ogni scheda.

Per chi e' abituato a lavorare in modo piu' strutturato questo suona come un'eresia, ma e' il modo migliore per portare a casa dei risultati quando i progetti sono distribuiti e portati avanti a livello amatoriale.
  #48  
Vecchio 17-09-2006, 01.13.39
nonno_62 nonno_62 non è collegato
Robottaro sostenitore
 
Data registrazione: 25-11-2005
Residenza: sardegna
Etŗ†: 68
Messaggi: 572
Potenza reputazione: 77
nonno_62 E' un faro della comunitŗ
Predefinito

Dopo un pò di elucubrazioni mentali, qualche chiaccherata con amici e dopo essermi riletto i vari post ho deciso di fare un riepilogo di quanto finora detto e di fare qualche proposta per arrivare a qualche definizione del protocollo.

1) Analisi del sistema:

a. I presupposti di base di ogni scheda sono che la stessa deve essere autonoma nel lavoro che svolge. Ad esempio la scheda controllo motori deve essere in grado di gestire i due motori (parlo di PWM, PID e Odometria) cos√¨ come la scheda sensori (ad esempio radar) dovr√* essere in grado di orientare il sensore di leggere e interpretare i dat rilevati. e cos√¨ via. Per ultimo si potrebbe ipotizzare di avere una scheda che per motivi di velocit√* di risposta, vedi un allarme, ha al suo interno un piccolo stato decisionale, ad esempio alla scheda controllo motori si potrebbero collegare anche dei sensori davanti alle ruote antiscale o antiminiostacolo, con relativo controllo decisionale di arresto motori.

b. Le comunicazioni fra le varie schede o "moduli" devono avere la caratteristiche di semplicit√* e di priorit√* di accesso, dovuta al fatto che alcune schede possono avere cose pi√Ļ importanti/critiche da dire rispetto ad altre schede.

c. Non dobbiamo pensare di trasmettere flussi di dati quali stream video, una eventuale telecamera avr√* la sua scheda che far√* le proprie analisi e che alla fine inviera solo le conclusioni al sitema. Nel caso le immaggini siano necessarie, alla scheda cervello, in formato completo, o si opter√* per collegare la telecamera alla scheda cervello stessa, ovvero si potr√* pensare ad un bus dedicato a quel tipo di trasmissione.

d. Quali priorit√* dare alle varie comunicazioni, o meglio come pensare di usare il bus. Qui ci sono due modi vedere il sistema, bus libero fino ache una scheda non decide di dover dire una cosa ad un'altra scheda (anche senza passare per la scheda cervello), che denominiamo sistema multimster o possibilit√* di gestire il bus attraverso un controllore che procede al polling (chiamata ciclica) di tutte le altre schede al fine di gestire il traffico dei messaggi. In quest'ultimo caso il controllore pu√≤ essere la scheda cervello oppure si pu√≤ pensare ad una scheda dedicata a tale attivit√* . I pr√≤ e i contro non li elenco perch√® dai discorsi fatti credo siano gia noti.

e. Le informazioni che dovranno passare sul bus sono la comunicazione dei dati rilevati dalle singole schede, comunicazione di settaggi/comandi e infine una serie di allarmi.

f. Il protocollo, nella versione base, deve essere cos√¨ semplice di poter essere riciclato su un sistema di diversi bot comunicanti fra loro tramite rete via etere (vedi moduli aurel che hanno velocit√* abbastanza basse, almeno per quanto riguarda quelli di basso costo) .Possiamo poi pensare ad una seconda parte di protocollo pi√Ļ complessa utilizzabile per comandi mnemonici.

2) Proposte:

Ci ho pensato e ripensato e credo che si possa partire con un sistema master slave, pi√Ļ semplice da realizzare e forse da portare a casa, con struttura dei byte fatta da 9 bit, il nono bit come suggeriva Astro per il controllo dell'indirizzo/dato. La struttura comandi di 6 caratteri di header (mittente, destinatario, numero messaggio in relazione al mittente, comando, lunghezza eventuali dati), dati per un max di 24 byte e 2 caratteri di controllo, per un buffer massimo di 32 caratteri. Per i messaggi inviati si prevede sempre una risposta immediata (acknoledge) di due caratteri (due volte l'indirizzo mittente) e successivamente (opzionale) con la ripetizione dell'header di 6 byte (il quinto a ff) i dati di risposta e i 2 byte di controllo, velocit√* di 115 kbps.
La priorit√* a schede di particolare importanza si esplica con l'accesso alle stesse con maggior frequenza da parte del master.
Se in linea di principio, in relazione alle premesse, il sistema √® condiviso si pu√≤ pensare di cominciare a buttare gi√Ļ un p√≤ di specifiche. (io mi rifarei sempre al picnetplus, adattandolo a noi)

Ultime due considerazioni:

1) Il sistema deve essere pensato per crescere e diventare multimaster a comnciare dalla struttura del messaggio stesso, ammesso che ne avremo voglia, proprio per essere sfruttato sui mini robot formica (io comunque ci lavorerò, ci volesse pure qualche anno ) ..........

2) Aspetto consigli, proposte e critiche utili per buttare gi√Ļ una nuova bozza di protocollo per Moddi.

Saluti Nonno

Ultima modifica di nonno_62 : 17-09-2006 alle ore 01.18.28
  #49  
Vecchio 17-09-2006, 09.40.31
L'avatar di saveriop
saveriop saveriop non è collegato
Robottaro master
 
Data registrazione: 16-08-2005
Residenza: firenze
Etŗ†: 45
Messaggi: 428
Potenza reputazione: 78
saveriop E' una stupenda persona in cui credere
Predefinito

Citazione:
Orginalmente inviato da nonno_62
La struttura comandi di 6 caratteri di header (mittente, destinatario, numero messaggio in relazione al mittente, comando, lunghezza eventuali dati), dati per un max di 24 byte e 2 caratteri di controllo,
Mi sembra un'ottima base di partenza.
Vorrei proporre un'altra modifica all'header, nell'ottica di gestire meglio messaggi a bassa priorita' con gran mole di dati.

Cosi' come avviene per esempio per il formato PDU per lo scambio sms sulla rete gsm, e dato che si hanno max 24 caratteri di data, proporrei di inserire la possibilita' di spezzare in piu' messaggi una risposta.

Dato che abbiamo gia' inserito il progressivo messaggio, direi di usare un altro byte per specificare in quanti parti e' spezzata la risposta fino ad un max di 16 parti:

1/4 , 2/4 ... 4/4

Usando i 4 bit meno significativi per descrivere il numero totali di parti e quelli piu' significativi il progressivo del messaggio corrente.
In questo modo portiamo a 384 i data bytes senza incidere sulle performances.

Ultima modifica di saveriop : 17-09-2006 alle ore 09.43.36
  #50  
Vecchio 17-09-2006, 23.11.42
nonno_62 nonno_62 non è collegato
Robottaro sostenitore
 
Data registrazione: 25-11-2005
Residenza: sardegna
Etŗ†: 68
Messaggi: 572
Potenza reputazione: 77
nonno_62 E' un faro della comunitŗ
Predefinito

Alla luce di quanto detto non credo che ci sar√* bisogno di realizzare messaggi cos√¨ lunghi. Ma visto che non sappiamo ancora dove stiamo andando, eche il supporto fisico consente di viaggiare a un megabps non dobbiamo lasciarci nulle di precluso. Possiamo fare cos√¨:

Prima fase del protocollo (master slave e comandi di un byte), lasciamo il messaggio come proposto.

Seconda fase del protocollo (multimaster e comandi mnemonici), come avevo gi√* proposto utilizzare il comando 0x00 per indicare che nel campo dati c'√® un comando mnemonico, che potra essere indicativo del numero paccheto trasmesso.

Nessun'altro ha nulla da dire? Abbiamo fatto una marea di post e poi mi lasciate solo?

Saluti Nonno

PS Una cosa di cui mi dimenticavo era di realizzare un protocollo a buccia di cipolla con un nucleo centrale e poi estensioni secondo le necessit√*, ma di facile realizzazione su di un pic
 


Utenti attualmente attivi che stanno leggendo questa discussione: 1 (0 utenti e 1 ospiti)
 
Strumenti discussione
Modalitŗ† visualizzazioe

Regole di scrittura
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code Ť Attivato
Le smilies sono Attivato
[IMG] Ť Attivato
Il codice HTML Ť Disattivato

Vai al forum

Discussioni simili
Discussione Autore discussione Forum Risposte Ultimo messaggio
Distanza con protocollo SPI. Ziko Comunicazione 3 27-08-2012 12.21.49
Tutorial Protocollo CAN Fu Mauro Comunicazione 22 05-10-2011 17.07.53
Piý strada cambiando protocollo. Ziko Comunicazione 8 28-01-2011 11.29.05
PIC in rete con rs232+protocollo UART calo Comunicazione 2 25-01-2008 21.07.16
Protocollo: Pratica nonno_62 Progetto robot MODDI (forum chiuso) 23 18-02-2007 21.02.06


Tutti gli orari sono GMT. Adesso sono le: 16.51.09.


Basato su: vBulletin Versione 3.8.8
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Realizzazione siti web Cobaltica Foligno
spacer.png, 0 kB