|
|
| (46 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| | + | == Source code == |
| | + | |
| | All the code for the project is hosted on github. The repository can be browsed [https://github.com/pogliamarci/robotower here]. | | All the code for the project is hosted on github. The repository can be browsed [https://github.com/pogliamarci/robotower here]. |
| | | | |
| − | ==TODO==
| + | Instructions for compilation and installation are provided in the documentation (appendix A). Notes regarding the firmware for the STM32F4 Discovery Board are in the appendix B of the documentation (source code is in the same github repository) |
| − | | + | |
| − | # Sistemare regole Mr. Brian (livelli + fabbriche)
| + | |
| − | # Marker RFID
| + | |
| − | # Vittoria (interruttore su torre che viene abbattuta)
| + | |
| − | # Abbattimento torre (stima distanza da torre da dimensione blob)
| + | |
| − | # Logica del gioco
| + | |
| − | # Evitare ostacoli "invisibili"
| + | |
| − | # Lanciapalle
| + | |
| − | | + | |
| − | == Project status ==
| + | |
| − | === Implemented or partially implemented features ===
| + | |
| − | * '''Game design'''. A document with the game storyboard and rules is available [[Media:RobotowerStoryboard.pdf|here]].
| + | |
| − | * '''Porting to ROS''' of the Robowii modules (previously based on DCDT) which control the robot and perform color blob detection
| + | |
| − | * Design of the '''overall architecture''' (ROS nodes and topics/services). The following figure represents the ROS nodes designed and/or implemented until now (boxes in bold), together with the messages that are exchanged (the names on the arrows) and the interfaces with external libraries and\or the hardware (boxes with dashed line).
| + | |
| − | [[File:RobotowerSchemaNodi.png|500px|center| thumb |Architecture of the implemented system]]
| + | |
| − | *Porting of Mr.Brian Tools (Checker and Gmbte) in Ros Packages
| + | |
| − | * Integration of '''Mr. Brian''' into the project, and development of the first rules (Spykee searches for the tower and goes towards it, trying to avoid the obstacles - if there are any)
| + | |
| − | ** Random search (to find the tower)
| + | |
| − | ** Avoiding obsacles: rules to move left or right if the sonar detects something in front of the robot, and to move backwards in case the obstacle is detected as very near
| + | |
| − | | + | |
| − | ==Ideas for the development==
| + | |
| − | | + | |
| − | ===Ostacoli "attivi"===
| + | |
| − | | + | |
| − | '''Tag da riconoscere tramite visione''' (tutte le soluzioni provate hanno dato scarsi risultati in termini di velocità e\o qualità del riconoscimento)
| + | |
| − | * [http://www.libdmtx.org/ 'DataMatrix']: riconosciuti bene se fermi nell'immagine, ma troppo lentamente e non riconosciuti in movimento. L'algoritmo è lento (anche 3 secondi se non si impone un timeout)
| + | |
| − | * [http://opencv.itseez.com/modules/calib3d/doc/camera_calibration_and_3d_reconstruction.html?highlight=findchess 'Scacchiera (openCV <tt>cvFindChessboardCorners</tt>)']: viene riconosciuta molto male
| + | |
| − | * [http://handheldar.icg.tugraz.at/artoolkitplus.php 'ARToolKitPlus']: i frame vengono riconosciuti molto velocemente. ''Problema'': l'algoritmo che utilizza dipende enormemente dalle condizioni di luce. In movimento i risultati sono deludenti, anche a velocità moderate. La documentazione è scarsa.
| + | |
| − | | + | |
| − | '''RFID''': [http://it.wikipedia.org/wiki/Radio_Frequency_IDentification 'Radio Frequency IDentification]
| + | |
| − | | + | |
| − | Abbiamo effettuato alcune prove con il lettore ID-12 della ID Innovations (tag a 125 KHz), e possiamo confermare dei risultati abbastanza buoni.
| + | |
| − | | + | |
| − | il riconoscimento avviene a una distanza apparentemente sufficiente (anche se di poco) agli scopi del gioco, e a una velocità abbastanza sostenuta da rendere l'esperienza sufficientemente dinamica.
| + | |
| − | | + | |
| − | * Da provare: funzionamento effettivo "On Board"
| + | |
| − | * Problematiche
| + | |
| − | ** Posizionamento del lettore. Il fatto che l'ID-12 sia dotato di antenna interna rende piuttosto difficoltoso il posizionamento verso il fondo del robot.
| + | |
| − | ** Gestione della comunicazione (più zigbee? O microcontrollore per multiplexare le seriali?)
| + | |
| − | | + | |
| − | ===Lanciapalle===
| + | |
| − | Progetto:
| + | |
| − | | + | |
| − | Due motori in continua che lavorino simmetricamente per prendere la pallina e lanciarla a una velocità media.
| + | |
| − | | + | |
| − | | + | |
| − | '''Domande''':
| + | |
| − | | + | |
| − | # Vale la pena di svilupparlo? cosa darebbe in più al gioco?
| + | |
| − | # C'è il tempo per svilupparlo?
| + | |
| − | # Ci sono le risorse economiche/infrastrutturali per controllarlo e realizzarlo?
| + | |
| − | # C'è la possibilità di rivelare il colpo a segno della pallina?
| + | |
| − | # E' necessario un microcontrollore?
| + | |
| − | | + | |
| − | ===Ostacoli invisibili===
| + | |
| − | gli ostacoli invisibili sono ostacoli che il sonar non riesce a rivelare perchè, ad esempio troppo bassi (gambe delle sedie) o troppo alti (caloriferi)
| + | |
| − | | + | |
| − | idee:
| + | |
| − | * Aumento hardware robot (più sonar)
| + | |
| − | * Logica
| + | |
| − | | + | |
| − | la prima opzione è abbastanza da scartare... complicata e probabili problemi di interferenza. inoltre il sonar sarebbe sottoutilizzato se piazzato per riconoscere ostacoli bassi, e inutile per quelli alti
| + | |
| − | | + | |
| − | La seconda opzione è passare al controllore fuzzy (brian) il tempo in cui l'ingresso del sonar non varia significativamente. questo significa che il robot, con buona probabilità, è bloccato.
| + | |
| − | Con un fuzzy set <tt>Triangle_or</tt> (<tt>TOR</tt>) si dovrebbe ottenere un comportamento decente.
| + | |
| − | [[File:Fuzzyset.jpg | center | 300px | thumb |TOR fuzzy set]]
| + | |
| − | | + | |
| − | | + | |
| − | idea su come gestire il "tempo di blocco"
| + | |
| − | # calcolo la deviazione standard degli ultimi 20 dati (ossia ultimo secondo circa, poichè il ciclo di controllo è a 20 Hz)
| + | |
| − | # impongo che la stddev sia minore dell'errore accettabile (scelto, ora, fisso)
| + | |
| − | # se l'errore è minore, allora aumenta il tempo di "blocco"
| + | |
| − | # se è invece maggiore, azzeralo.
| + | |
| − | # dai in pasto a brian il tempo, e fuzzyfica.
| + | |
| − | | + | |
| − | problemi:
| + | |
| − | | + | |
| − | * Falsi negativi
| + | |
| − | * Falsi positivi
| + | |
| − | * Comandi a volte troppo brevi
| + | |
| − | | + | |
| − | soluzioni:
| + | |
| − | | + | |
| − | * filtraggio passa-basso della varianza
| + | |
| − | * Aumento soglie tempo/varianza
| + | |
| − | | + | |
| − | '''Considerazioni'''
| + | |
| − | La maggior parte dei falsi positivi è dovuta al fatto che il sonar, oltre una certa distanza, tende a non rilevare con precisione le variazioni di distanza delle pareti e di altri ostacoli, senza contare la dispersione possibile del segnale sonoro.
| + | |
| − | si può evitare gran parte dei falsi positivi, introducendo un controllo sull'attuazione della regola, per distanze nel range di buona affidabilità del sonar (si può introdurre la possibilità di introdure l'affidabilità dell'imput??). Sicuramente così, si introducono potenziali falsi negativi, ma, poichè il controllo non può essere perfetto, si può considerare buona l'approssimazione.
| + | |
| − | | + | |
| − | '''Idea per migliorare ulteriormente''': considerare anche il sonar sud (e/o i sonar laterali)
| + | |
| − | | + | |
| − | ===Vittoria===
| + | |
| − | ''Quando il robot Vince?'' per ora è implementato una condizione di vittoria che prevede di vedere la torre e avere un ostacolo vicino.
| + | |
| − | | + | |
| − | Tuttavia, se il robot rileva un ostacolo vicino che '''non''' è la torre, e la torre è presente nel campo visivo, il robot crede di aver vinto (il robot vince vedendo la torre, ad esempio, dietro un muro).
| + | |
| − | | + | |
| − | '''Idee:''': controllo con interruttori a pressione che scattano quando la torre cade, e trasmettono via radio il segnale di "torre abbattuta" al computer. Per la trasmissione del segnale: telecomandi e ricevitore Aurel RX-4MHCS ([http://www.soselectronic.hu/a_info/resource/c/AUREL/RX4MHCS-F.pdf datasheet])
| + | |
| − | | + | |
| − | ===Riconoscere la distanza da un oggetto "visto"===
| + | |
| − | | + | |
| − | '''Come capire se l'oggetto che sto vedendo si trova davantti a me e non dietro a qualche ostacolo?'''
| + | |
| − | | + | |
| − | *Correlando ciò che '''Vedo''' a ciò che '''Sento'''
| + | |
| − | | + | |
| − | ossia correlando una distanza data dalla visione a una distanza data dal sonar.
| + | |
| − | | + | |
| − | '''Problema:''' ciò che vedo è un segnale rumoroso, la larghezza del segnale non è affidabile, e la telecamera scatta.
| + | |
| − | | + | |
| − | | + | |
| − | ====Soluzione: Filtro di Kalman====
| + | |
| − | | + | |
| − | Il filtro di kallman studia come stimare corettamente una grandezza da un sistema sottoposto ad errore del tipo:
| + | |
| − | [[File:KalmanSistem.png | none | sistema da considerare]]
| + | |
| − | Queste equazioni a tempo continuo rappresentano un sistema a tempo discreto in cui:
| + | |
| − |
| + | |
| − | * la prima equazione è il processo da osservare, in questo caso indica come varia realmente la dimensione del blob visto dalla camera. ossia è quello che vedremmo noi (umani) nel frame.
| + | |
| − | * la seconda è il valore misurato del processo, in questo caso è la misura ricavata dall'algoritmo di visione, del blob. Ossia, z è la misura del blob vista dal robot.
| + | |
| − | | + | |
| − | wi è il rumore del processo, vi è il rumore di osservazione
| + | |
| − | | + | |
| − | ui è la forzante del sistema, ossia ciò che provoca la variazione della dimensione del blob, in questo caso dipende dalla posizione e dalla velocità del robot mentre inquadra un bersaglio.
| + | |
| − | | + | |
| − | Il filtro di Kalman si può spezzare in tre fasi iterative: la fase di predizione, il calcolo del guadagno di kalman e la fase di osservazione/correzione
| + | |
| − | | + | |
| − | 1) predizione
| + | |
| − | [[File:KalmanPred.png | none | ciclo di predizione]]
| + | |
| − | 2) guadagno
| + | |
| − | [[File:KalmanGain.png | none | guadagno]]
| + | |
| − | 3) osservazione
| + | |
| − | [[File:KalmanOss.png | none | guadagno]]
| + | |
| − | | + | |
| − | | + | |
| − | '''Problemi:'''
| + | |
| − | * che valori devono assumere ri e qi? devono essere costanti o variare nel tempo?
| + | |
| − | * come inizializzare p0?
| + | |
| − | * Come ricavare il valore della forzante ui all'istante i?
| + | |
| − | | + | |
| − | idee:
| + | |
| − | * Poichè pi rappresenta la varianza dell'errore, allora si può supporre che p0 sia nula, poichè si suppone che l'errore sia costantemente nullo (ossia si suppone che la visione sia perfetta). Il filtro si occuperà poi di portare, a regime, p al valore reale della varianza dell'errore della stima di x.
| + | |
| − | | + | |
| − | * come calcolare ui?
| + | |
| − | | + | |
| − | Ui è la forzante del sistema, e corrisponde a quanto il blob reale varierà la sua dimensione nell'istante di tempo i. Poichè non conosciamo alcun dato sulla velocità del robot, e quindi non possiamo utilizzare un modello teorico dell'evoluzione della dimensione del blob, allora possiamo fare una piccola approssimazione:
| + | |
| − | | + | |
| − | consideriamo l'istante di tempo in cui viene calcolata ui infinitesimo, la velocità di variazione della dimensione del blob sarà allora costante. Allora si potrà utilizzare la derivata della dimensione stimata del blob all'iterazione precedente, come stima della velocità della variazione del blob (reale). Dunque:
| + | |
| − | | + | |
| − | ui=(x(i-1)-x(i-2))/Ts*Ts
| + | |
| − | | + | |
| − | ossia:
| + | |
| − | | + | |
| − | ui=x(i-1)-x(i-2)
| + | |
| − | | + | |
| − | con:
| + | |
| − | | + | |
| − | * Ts tempo di campionamento (1/20 s nel nostro caso)
| + | |
| − | * x(i) è il valore della dimensione del blob (supposta dal filtro all'istante i)
| + | |
| − | | + | |
| − | ===Ostacoli laterali===
| + | |
| − | | + | |
| − | Un problema della logica e dell'infrastruttura del robot, sono gli "ostacoli laterali"
| + | |
| − | Sebbene dotato di sonar a est e ovest, per ora non sono "molto" utilizzati dalla logica attuale del gioco, in quanto vengono utilizzati solamente per indurre comportamenti intelligenti di uscita dalle situazioni di blocco frontale (ad esempio a causa di un ostacolo), a supporto della scelta casuale, che è necessaria quando non si hanno altre indicazioni.
| + | |
| − | | + | |
| − | Un'idea per sfruttare più pienamente le potenzialità del sonar, e indurre un comportamento più "conscio" del campo di gioco da parte del robot, è quello di cercare di mantenere una distanza di sicurezza da ostacoli laterali, se possibile.
| + | |
| − | | + | |
| − | '''problema possibile''': il robot potrebbe non essere in grado di attraversare strettoie
| + | |
| − | | + | |
| − | '''Considerazioni''':
| + | |
| − | * Il robot è già in grado di attraversare strettoie? se si, si può evitare il problema? bastano i due predicati contrapposti?
| + | |
| − | * Queste regole sono utili davvero? o possono influire sul normale comportamento del robot negativamente?
| + | |
| − | * Se il robot non fosse in grado d afttraversare strettoie, è possibile indurlo a farlo?
| + | |
| − | * Si riesce a supplire la mancanza di una ulteriore coppia di sonar obliqui? il cono d'ombra attuale del robot è accettabile?
| + | |
| − | | + | |
| − | ==Uso di MrBrian==
| + | |
| − | | + | |
| − | ===I file===
| + | |
| − | * '''behaviour.txt''': lista dei possibili comportamenti, dei loro livelli di priorità, e di dove trovarli nel filesystem.
| + | |
| − | * '''file .rul''': definiscono i comportamenti possibili del robot, mettendo in relazione a una condizione logica espressa coi predicati fuzzy in ingresso, i predicati fuzzy in uscita che verranno poi defuzzyficati secondo il loro peso (cando, want e antecedente)
| + | |
| − | * '''ctof.txt''': Associa al dato crisp in ingresso una "forma", ossia un'insieme di funzioni e etichette per trasformare il dato crisp in dato fuzzy.
| + | |
| − | * '''s_ftoc.txt''': definisce quali sono i dati in uscita e che insieme di valori possono utilizzare
| + | |
| − | * '''shape_ctof.txt''': definisce le possibii "forme" che possono essere utilizzate per fuzzyficare un determinato dato in ingresso, ossia un insieme di funzioni e relative etichette in modo da poter associare un valore di "verità" fuzzy l dato in ingresso.
| + | |
| − | * '''s_shape.txt''': definisce gli insiemi di valori che possono usare i dati in uscita (solitamente singleton)
| + | |
| − | * '''Predicate.ini''': Definisce i predicati Fuzzy semplici, a partire dai dati in ingressso, processati dal fuzzyficatore, oppure i predicati complessi a partire da altri predicati e dati fuzzyficati
| + | |
| − | * '''PredicateActions.ini''': che è? bella domanda! attendiamo risposte esaustive, più di quelle lette in articoli/guide sull'effettivo utilizzo del file
| + | |
| − | * '''Cando.ini''': Questo file definisce quando un determinato comportamento può essere eseguito, ossia rappresenta le condizioni necessarie per cui uncomportamento sia "sensato" da eseguire
| + | |
| − | * '''want.txt''': Questo file definisce quando è oppurtuno attivare un determinato comportamento, ossia rappresenta la parte "propositiva" e "strategica" del controllore fuzzy. L'obbiettivo del want è pesare quale delle scelte possibili è la migliore scelta effettuabile, nel determinato caso.
| + | |
| − | | + | |
| − | ===I livelli===
| + | |
| − | | + | |
| − | Lo scopo della gestione a livelli è rendere indipendente la condizione di attivazione delle regole da possibili condizioni negative che invece ne evitino l'attivazione, rendendo di fatto indipendente la regola da condizioni che esulano il suo contesto. se non ci fossero i livelli, ogni regola dovrebbe considerare dunque le condzioni per cui la sua attivazione potrebbe causare conflitti con comportamenti più critici.
| + | |
| − | | + | |
| − | Ad esempio una regola che impone di avanzare al robot è sicuramente meno critica di una regola che gli impone di evitare un ostacolo, e senza i livelli l'avanzata sarebbe condizionata sempre al controllo di eventuali ostacoli di fronte a se.
| + | |
| − | | + | |
| − | == Progettazione del gioco ==
| + | |
| − | | + | |
| − | ===Linee guida===
| + | |
| − | | + | |
| − | Le seguenti linee guida per lo sviluppo di un Robogame competitivo "di successo" sono state ricavate a partire da alcuni articoli sul progetto di Hi-CoRG.
| + | |
| − | | + | |
| − | ====Caratteristiche generali ====
| + | |
| − | | + | |
| − | # Deve consistere in almeno un robot e almeno un giocatore umano in grado di interagire tra di loro cooperativamente o competitivamente
| + | |
| − | # Basso costo e alta efficienza dell’uso dei componenti
| + | |
| − | # Sicuro da giocare
| + | |
| − | # Semplice & divertente (per chi ci gioca)
| + | |
| − | # Il robot deve essere visto dal giocatore come un agente razionale
| + | |
| − | # Il gioco deve essere provato sul campo
| + | |
| − | # il gioco deve coinvolgere più sensi (del giocatore... e del robot) : vista, udito, tatto (ossia colori, suoni e forme)
| + | |
| − | | + | |
| − | ====Caratteristiche del gioco====
| + | |
| − | | + | |
| − | # Obiettivo: deve essere chiaro e semplice, e deve essere suddiviso in sotto-obiettivi (punti) se è troppo lungo
| + | |
| − | # Difficoltà adatta/adattabile al giocatore
| + | |
| − | # Regole facili da capire e imparare
| + | |
| − | # Azioni facili da compiere
| + | |
| − | # Il sistema “gioco” reagisce prontamente alle azioni del giocatore
| + | |
| − | | + | |
| − | ====Caratteristiche del robot====
| + | |
| − | | + | |
| − | # Reagisce al comportamento umano bene (a meno di semplificazioni)
| + | |
| − | # Riceve input nella maniera più affidabile e credibile possibile (anche a costo di semplificazioni)
| + | |
| − | # Aspetto adatto al gioco
| + | |
| − | # Comportamento che non appare casuale, ma razionale e pensato
| + | |
| − | # Funzionamento in tempo reale
| + | |
| − | | + | |
| − | ====Obiettivi di Robogame====
| + | |
| − | | + | |
| − | # portare il gaming verso la sua naturale evoluzione verso la “fisicità”, strada cominciata da Nintendo con il wii, e ormai accettata dalle maggiori case di videogiochi.
| + | |
| − | # Introdurre nella vita quotidiana il robot come qualcosa di “familiare” e utile
| + | |
| − | # Diffondere l’interesse per la robotica ad un pubblico più ampio
| + | |
| − | | + | |
| − | ===Progetto del gioco===
| + | |
| − | | + | |
| − | ==== Scelta del genere ====
| + | |
| − | Per avere un’idea del gioco, si è partito dal presupposto che Robogame sia l’evoluzione del gaming tradizionale, si è partiti quindi dal considerare i generi più usati nei videogiochi attuali:
| + | |
| − |
| + | |
| − | * Strategici
| + | |
| − | * Gestionali (esclusi in ottica robogame in quanto non adatti)
| + | |
| − | * Sparatutto (esclusi in quanto fin troppo sfruttati, sia dai robot che dai videogiochi)
| + | |
| − | * Giochi di ruolo (esclusi a causa del numero limitato di robot in gioco)
| + | |
| − | * Platform (esclusi perchè fisicamente poco realizzabili da un robot attuale)
| + | |
| − | * Sportivi
| + | |
| − |
| + | |
| − | Dopo aver escluso i generi non adatti, abbiamo considerato approfonditamente i due generi rimasti, e i loro limiti. Nel caso dei giochi '''sportivi''', il limite è dato dalla necessità di avere un robot abbastanza dinamico, mentre i giochi '''strategici''' sono limitati dalla scarsa dinamicità di azione.
| + | |
| − | | + | |
| − | ==== Uso della palla ====
| + | |
| − | | + | |
| − | Una prima distinzione all'interno dei giochi delle categorie considerate riguarda l'uso della palla.
| + | |
| − | | + | |
| − | * I giochi con palla rendono il robot più complesso, ma sono immediati e coinvolgenti, e non pongono gravi problemi come la definizione di nascondiglio. Sono certamente semplici, intuitivi e dinamici. permettono di variare strategia, soprattutto se il gioco avviene con più agenti intelligenti in campo.
| + | |
| − | | + | |
| − | * I giochi senza palla necessitano di robot in generale semplici, che richiedano al più velocità discrete. Sono meno coinvolgenti (anche se dipende dai gusti) e meno dinamici, o comunque se sono dinamici danno meno spazio a strategie pensate come “razionali” (se devo scappare da qualcuno... scappo) oppure paradossalmente prevedono l’introduzione di idee complesse, come quella di nascondiglio.
| + | |
| | | | |
| − | Un grosso problema legato all'uso della palla riguarda la velocità. Alcune idee per limitare la velocità della palla sono:
| + | == Documentation == |
| − | * Uso dei palloncini
| + | |
| − | * Uso di palline da tennis sgonfie, con l’obbligo di rimbalzo (urto anelastico che “assorbe” energia cinetica)
| + | |
| − | * Uso di zone determinate per il gioco e porte.
| + | |
| | | | |
| − | ==== Giochi strategici ====
| + | * [[media:RoboTower.pdf|Documentation]] (in italian) [last update: 1 April 2013] |
| − |
| + | * The [[media:RTSheet.pdf|posters]] used to explain the game at MeetMeTonight 2012 (in italian) |
| − | Dei giochi strategici abbiamo considerato 3 sotto categorie:
| + | |
| − |
| + | |
| − | * '''Derivati dai giochi da tavolo'''. Esempio: labirinto magico (famoso gioco da tavolo in scatola), in cui magari il labirinto è fatto con segnali luminosi (se possibile) o in altro modo. Il labirinto magico è un labirinto che può cambiare configurazione in cui bisogna trovare degli oggetti (oppure potrebbe essere l’uscita... oppure il robot. Altri esempi: giochi come “battaglia navale” o altri giochi di strategia pensati.
| + | |
| − | * '''Tower Defense'''. Un esempio di Tower defense potrebbe essere un gioco ispirato a Rock Of Ages, che consiste nel difendere il proprio castello dall’assalto di una palla demolitrice e comandare la palla contro quello dell’avversario. In questo caso il robot potrebbe svolgere la funzione della “roccia”, evitando gli ostacoli insormontabili, e travolgendo/distruggendo (ovvero spostando... o passandoci sopra) quelli che invece potrebbero solo rallentarlo, o che gli bloccano il passaggio fino a raggiungere l’obiettivo. Più robot possono cooperare contro più umani per l’assalto al “castello”, oppure si possono fare due o più squadre robot/umano e simulare una battaglia alla “Rock Of Ages” | + | |
| − | * '''Da bambini e/o di intelligenza''': giochi “infantili” possono essere trova & nascondi (simili alla caccia al tesoro) distruggi & costruisci, oppure un gioco in cui l’obiettivo del robot siano alcuni oggetti, però il robot non deve farsi individuare dal giocatore che ha gli oggetti... e il giocatore deve portare i robot a tradirsi attraverso questi oggetti, posizionandoli adeguatamente nell’area di gioco, sfruttando fondamentalmente lo stesso concetto della pesca.
| + | |
| | | | |
| − | ====Design del gioco==== | + | == Stickers for RFID tags == |
| | | | |
| − | In particolare sono state stese tre bozze di gioco, una (RoboTower) basata sull'idea di Tower Defense, che è poi stata effettivamente implementata, e due bozze, entrambe focalizzate sull'uso della palla. Delle bozze scartate, la prima consiste in un gioco sportivo simile al tennis, in cui il robot deve svolgere azioni limitate rispetto all'umano, la seconda consiste in un gioco ispirato ai giochi infantili e basato su un palloncino.
| + | * PDFs of the stickers that have been applied on the RFID tags: [[media:RFIDStickers-1.pdf|sheet 1]] and [[media:RFIDStickers-2.pdf|sheet 2]] (print them on polyester adhesives) |
| | + | * Adobe Illustrator [[media:RFIDStickers-Sources.zip|sources]] of the stickers and the [[media:RTCards-Sources.zip|images]] of RFID stickers used to represent them in the GUI |
| | | | |
| − | In generale, è preferibile pensare a giochi in cui i ruoli di giocatore e robot siano diversi (come nella bozza Tower Defense), il che permette di aggirare eventuali limitazioni del robot, se non sfruttarle a vantaggio dell’esperienza di gioco.
| + | == Other stuff == |
| | | | |
| − | Un altro problema, oltre a quello già citato della velocità, legato ai giochi che utilizzano la palla, è la necessità da parte del robot di effettuare movimenti complessi: la palla deve infatti essere sollevata da terra, colpita (eventualmente al volo) e direzionata, causando problemi nell'implementazione con una precisione accettabile su un robot di tali comportamenti. Per tale motivo, le bozze impieganti la palla sono state scartate.
| + | ===ROS=== |
| | + | * Qui c'è una nostra piccola [[media:miniguidaROS.pdf|guida]] con i comandi principali e il codice di nodi di esempio (presi dai tutorial), sia per C++ che per Python |
| | + | * Also, in the AirWiki there is an handy [[ROS_HOWTO|ROS Howto]], that is useful too... |
| | | | |
| − | Nello sviluppo dello [[Media:RobotowerStoryboard.pdf|storyboard]] di '''RoboTower''', è stata prestata particolare attenzione a quali aspetti del gioco siano completamente controllabili dalla logica di gioco e quali invece non sono controllabili in maniera efficiente e\o sufficientemente precisa, lasciando il compito di rispettare queste ultime regole alla "buona fede" del giocatore.
| + | ===[[Spykee]]=== |
| | + | * Qui c'è una spiegazione parziale e incompleta del [[media:spykeerev.pdf|protocollo]] di comunicazione tra SpyKee e il computer (non tutti i pacchetti sono stati testati, ma solo poco più di quelli che ci interessavano) |
| | + | * It's not so useful, but as the Spykee firmware is open source, you can take a look [http://www.spykeeworld.com/spykee/US/freeSoftware.html here] if you want to find out how the other packets work (beware: the download is huge!) |
| | | | |
| − | * E’ stata accettata, almeno momentaneamente, l’idea del lancia-palle, usabile per abbattere sia la torre che le fabbriche. Il modo effettivo con cui queste strutture possono essere distrutte è ancora da discutere, e dipenderà dalle caratteristiche dello spara-palle. | + | ===Hardware stuff=== |
| | + | * In [[media:Spykee-datasheet.zip|this file]] I collected some useful datasheet of part of the hardware employed in the project |
| | | | |
| − | * Il gioco è stato progettato per essere sia facilmente espandibile, aumentando ad esempio il numero di robot o di torri da utilizzare, di conseguenza è possibile implementare versioni del gioco con più giocatori umani che collaborino con o contro più robot. | + | ===Mr. Brian / Fuzzy controller=== |
| | + | * If you need to put your hand into the rules of the fuzzy controller, on the AirWiki there is a complete guide to Mr. Brian in the [[MRT]] page ([[media:MRTmanual.pdf|direct link]])! (read only the chapter about Mr. Brian, the other stuff wasn't used in RoboTower) |
Instructions for compilation and installation are provided in the documentation (appendix A). Notes regarding the firmware for the STM32F4 Discovery Board are in the appendix B of the documentation (source code is in the same github repository)
