|
|
| (22 intermediate revisions by the same user not shown) |
| Line 3: |
Line 3: |
| | 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]. |
| | | | |
| − | * PDFs of the stickers that have been applied on the RFID tags [[File:RFIDStickers-1.pdf]] [[File:RFIDStickers-2.pdf]] (print them on adhesive PVC)
| + | 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) |
| − | * Adobe Illustrator source of the stickers [[File:RFIDStickers-Sources.zip]] and the images of RFID stickers used in the GUI to show the RFID tags [[File:RTCards-Sources.zip]]
| + | |
| | | | |
| − | == Progettazione del gioco == | + | == Documentation == |
| | | | |
| − | * Come abbiamo progettato il gioco (linee guida, idee scartate/preliminari, etc) [https://docs.google.com/document/d/1uODOTOVbayhVzQwIU1lLKIQu3Wq_uJgjkT_por5xa_o/edit link al documento] | + | * [[media:RoboTower.pdf|Documentation]] (in italian) [last update: 1 April 2013] |
| − | * Una prima bozza dello storyboard: [[media:RobotowerStoryboard.pdf]] | + | * The [[media:RTSheet.pdf|posters]] used to explain the game at MeetMeTonight 2012 (in italian) |
| | | | |
| − | ==Working notes about some of the used tools== | + | == Stickers for RFID tags == |
| | | | |
| − | ===ROS===
| + | * 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) |
| − | * Qui c'è una nostra [https://docs.google.com/document/d/1-vX2MsA0aMlLT_pS4nJxnZG4ha5F8EjwOOmLAR0iTq8/edit mini-guida\cheatsheet] con i comandi principali e il codice di nodi di esempio (presi dai tutorial), sia per C++ che per Python | + | * 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 |
| | | | |
| | + | == Other stuff == |
| | | | |
| − | ===Uso di MrBrian=== | + | ===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 |
| − | ====File di configurazione====
| + | * Also, in the AirWiki there is an handy [[ROS_HOWTO|ROS Howto]], that is useful too... |
| − | * '''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 (oppure in uscita da un livello di MrBrian) 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''': Contiene i predicati che sono definiti dai dati fuzzy presi in uscita da ogni livello.
| + | |
| − | * '''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.
| + | |
| − | | + | |
| − | I livelli funzionano nel seguente modo:
| + | |
| − | | + | |
| − | 1) Mr Brian comincerà a calcolare i predicati fuzzy a partire dai dati "crisp" in ingresso, ossia applica una "forma" ai dati ricevuti dall'applicazione, che possono essere dati dei sensori, oppure dati elaborati dal programma.
| + | |
| − | | + | |
| − | 2) Mr Brian calcola il Cando di ogni regola, se è sotto una determinata soglia, la regola non viene attivata.
| + | |
| − | | + | |
| − | 4) Mr Brian calcola il peso da dare a ciascuna regola con il want
| + | |
| − | | + | |
| − | '''A questo punto entrano in gioco i livelli'''
| + | |
| − | | + | |
| − | 5) Mr Brian inizia a calcolare le uscite imposte dalle regole di livelli 1, pesandole con il Cando e il Want (probabile che scelga il minimo dei due come peso)
| + | |
| − | | + | |
| − | 6) Se si definisce una shape per il dato Fuzzy con etichetta Proposed<nome dato fuzzy in uscita> questo potrà essere utilizzato per definire predicati in predicateActions, in modo da condizionare il comportamento dei livelli superiori, in parte a quello dei livelli inferiori, ove necessario. Ad esempio se a livello 1 abbiamo TanSpeed = 40, avremo a disposizione un dato crisp ProposedTanSpeed, che potremo, se necessario, rifuzzyficare e usare come pre condizione dei livelli successsivi. Non è necessario che TanSpeed e ProposedtanSpeed abbiano la stessa shape: concettualmente sono una uscita il primo (e quindi conviene utilizzare una shape puntuale) e un ingresso il secondo (e quindi teoricamente conviene utilizzare una shape a aree trapezioidali/triangolari).
| + | |
| − | | + | |
| − | 7) Se presenti regole a livello n+1 attive, esse possono:
| + | |
| − | * Leggere i dati fuzzy definiti in predicate.ini, che avranno il medesimo valore rispetto ai dati fuzzy letti dalle regole di livello n
| + | |
| − | * Leggere i dati fuzzy in uscita ai livelli precedenti definiti in PredicateActions.ini . Il valore di questi predicati dipende dall'ultimo livello attivo che gli setta e eventualmente da quelli precedenti se il dato non fosse stato cancellato.
| + | |
| − | * Cancellare le uscite impostate precedentemente con (&DEL.<nome predicato in uscita> ANY)
| + | |
| − | * Imporre nuove uscite al predicato (che i precedenti siano stati cancellati dunque fa sì che la regola sia l'unica a essere applicata)
| + | |
| − | | + | |
| − | 8) i Dati vengono dunque presi, defuzzyficati e passati al livello successivo, finchè non si raggiungono le regole attive di livello massimo.
| + | |
| − | | + | |
| − | 9) Il dato fuzzy così prodotto viene mandato in uscita da brian.
| + | |
| | | | |
| − | == STM32F4 Discovery: notes == | + | ===[[Spykee]]=== |
| − | To manage the devices added to the robot, we used a STM32F4 Discovery Board. We built the firmware with the chibiOS/RT Operating System.
| + | * 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!) |
| | | | |
| − | The board is equipped with an ST-Link v2 programmer, that seems to be officially supported on Windows only. It works on Linux with two methods: using the stlink utility (https://github.com/texane/stlink) or using OpenOCD (you need to build it from git, as stlink support is experimental).
| + | ===Hardware stuff=== |
| − | === OpenOCD configuration === | + | * In [[media:Spykee-datasheet.zip|this file]] I collected some useful datasheet of part of the hardware employed in the project |
| − | As stlink support provided by openOCD is still experimental, it has to be explicitly enabled while compiling the sources. After downloading the latest sources from the git repository (the URL should be http://sourceforge.net/scm/?type=git&group_id=274635), compile and install issuing:
| + | |
| − | $ ./configure --enable-maintainer-mode --enable-stlink
| + | |
| − | $ make
| + | |
| − | # make install (this is needed only to install the binaries system-wide, and must be performed by root)
| + | |
| − | === Starting OpenOCD ===
| + | |
| − | When openOCD is correctly configure, it can be started with the command
| + | |
| − | $ openocd -f board/stm32f4discovery.cfg
| + | |
| − | (assuming that the board is connected to the computer).
| + | |
| | | | |
| − | '''NB''': sometimes the board is not recognized (it happens to me frequently when chibiOS is flashed on the board), and neither openocd nor texane's stlink can connect to the board. In this case, keeping the "reset" button on the board pressed while launching openocd should solve this issue. If this doesn't solve, use the ST Visual Programmer utility (windows only, sorry) to erase the FLASH memory.
| + | ===Mr. Brian / Fuzzy controller=== |
| − | === Connecting to the board === | + | * 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) |
| − | You now can flash the firmware, run and debug the code from within gdb (an arm version of gdb!). To connect to the openocd gdb server (assuming that firmware.elf is the binary file to be flashed and\or debugged):
| + | |
| − | $ arm-none-eabi-gdb filename.elf
| + | |
| − | (gdb) target extended-remote localhost:3333
| + | |
| − | Now that gdb is connected, typing the following commands will erase the FLASH memory, load the new firmware, and - finally - run the firmware!
| + | |
| − | (gdb) monitor reset halt
| + | |
| − | (gdb) monitor flash probe 0
| + | |
| − | (gdb) monitor stm32f2x mass_erase 0
| + | |
| − | (gdb) load
| + | |
| − | (gdb) monitor reset halt
| + | |
| − | (gdb) continue
| + | |
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)
