|
|
| (166 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) |
| − | | + | |
| − | in ordine di priorità: | + | |
| − | | + | |
| − | #Marker
| + | |
| − | #Evitare ostacoli "invisibili"
| + | |
| − | # Vittoria
| + | |
| − | #Come vedere Torri e Fabbriche
| + | |
| − | # Scelta colore fabbriche e torre
| + | |
| − | #Lanciapalle
| + | |
| − | #Warning librerie brian e fuzzy
| + | |
| − | | + | |
| − | ==IDEE==
| + | |
| − | | + | |
| − | ===Marker===
| + | |
| − | | + | |
| − | '''Idee''':
| + | |
| − | | + | |
| − | * [http://www.libdmtx.org/ 'DataMatrix']: riconosciuti bene se fermi nell'immagine, ma troppo lentamente e non riconosciuti in movimento. Anche 3 secondi se non si impone un timeout.
| + | |
| − | * 'Scacchiera': riconosciuta molto male: findchessboard in opencv probabilmente non fa grande elaborazione dell'immagine.
| + | |
| − | * [http://handheldar.icg.tugraz.at/artoolkitplus.php 'ARToolKitPlus']: i frame vengono riconosciuti molto velocemente, anche in movimento, sembra per ora, la strada migliore. Problema: dipendenza estrema da condizioni di luce.
| + | |
| − | | + | |
| − | ===Lanciapalle===
| + | |
| − | Progetto:
| + | |
| − | | + | |
| − | Due motori in continua che lavorino simmetricamente per prendere la pallina e lanciarla a una velocità media.
| + | |
| − | | + | |
| − | ===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_ol</tt> (<tt>TOL</tt>) si dovrebbe ottenere un comportamento decente.
| + | |
| − | [[File:Fuzzyset.jpg | center | 300px | thumb |TOL fuzzy set]]
| + | |
| − | | + | |
| − | ===Vittoria===
| + | |
| − | ''Quando il robot Vince?'' per ora è implementato una condizione di vittoria che prevede:
| + | |
| − | # vedere la torre
| + | |
| − | # avere un ostacolo vicino (che si suppone sia la torre)
| + | |
| − | Tuttavia, se il robot rileva un ostacolo vicino che '''non''' è la torre, e la torre è presente nel campo visivo, il robot crede di aver vieno (il robot vince vedendo la torre, ad esempio, dietro un muro). errato!
| + | |
| − | | + | |
| − | '''Idee:'''
| + | |
| − | * controllo forma blob. Problema: blob da vision pessimo
| + | |
| − | * controllo con marker
| + | |
| − | | + | |
| − | ===Scelta Colore===
| + | |
| − | | + | |
| − | * che colore scegliere per la torre?
| + | |
| − | | + | |
| − | Il rosso è facilmente riconoscibile. il blu si confonde col pavimento.
| + | |
| − | Grossi problemi a causa della sensibilità alle condizioni di luce. Soluzione: algoritmo di visione in HSV?
| + | |
| − | | + | |
| − | ===Altro===
| + | |
| − | | + | |
| − | niente da segnalare per ora!
| + | |
| − | | + | |
| − | ===Warning di brian===
| + | |
| − | | + | |
| − | | + | |
| − | Mail a Restelli:
| + | |
| − | | + | |
| − | ----
| + | |
| − | Ok, forse qua c'è bisogno di qualche informazione in più da darle per chiarire meglio il problema (non poi tanto grave) e trovare soluzioni adeguate:
| + | |
| − | | + | |
| − | ecco un esempio di warning, non aggiungo tutti i warning perchè sono davvero centinaia, non è possibile nemmeno vederli su terminale, dato il loro numero elevatissimo, se serve posso fare un log, ma non credo sia utile, dato che sono quasi tutti uguali. comunque ecco qui:
| + | |
| − | | + | |
| − | In file included from /home/dave/RoboTower/Brian/brian/include/rules_behav.h:20:0,
| + | |
| − | from prs/rulesflex.l:3:
| + | |
| − | /home/dave/RoboTower/Brian/brian/include/behavior_eng.h:462:53: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
| + | |
| − | /home/dave/RoboTower/Brian/brian/include/behavior_eng.h:475:55: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
| + | |
| − | /home/dave/RoboTower/Brian/brian/include/behavior_eng.h:486:52: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
| + | |
| − | /home/dave/RoboTower/Brian/brian/include/behavior_eng.h:491:53: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
| + | |
| − | | + | |
| − | | + | |
| − | Ora, il warning salta fuori perché cmake da a g++ il flag <tt>-Wextra</tt>, che provvede a passare il flag <tt>-Wignored-qualifiers</tt>. Ovviamente passargli il flag mostrato, non serve a nulla, in questo caso, perché è un flag per mostrare i Warnings. Si potrebbe anche togliere, ma non credo sia il caso, anche percè il problema è un'altro: ossia che il compilatore sta ignorando "<tt>const</tt>" sul ritorno della funzione.
| + | |
| − | | + | |
| − | Per poter essere più chiaro nell'esposizione del problema, sono andato a vedere che significava di preciso quel flag sulla documentazione di gcc:
| + | |
| | | | |
| − | -Wignored-qualifiers (C and C++ only)
| + | == Documentation == |
| − | Warn if the return type of a function has a type qualifier such as const. For ISO C such a type qualifier has no effect, since the value returned by a function is not an lvalue. For C++, the warning is only emitted for scalar types or void. ISO C prohibits qualified void return types on function definitions, so such return types always receive a warning even without this option.
| + | |
| − | This warning is also enabled by -Wextra.
| + | |
| | | | |
| − | Questa spiegazione mi pare abbastanza illuminante. Da quello che ho capito io (che però ho a che fare col c++ da solo pochi mesi, e quindi non sono espertissimo) il problema è che un ritorno "<tt>const</tt>" ha senso solo per tipi non scalari, perché i tipi scalari son passati per valore, e quindi non ha alcun senso dichiarare un valore come costante, semmai una variabile. Per i tipi non scalari, siccome sono tipi passati per riferimento, può aver senso dire che il puntatore è riferito a una zona di memoria costante, similmente a come vengono trattate le string di java o i tipi riferimento dei tipi primitivi. Comunque ripeto che è quello che immagino, e non sono sicuro, di quanto suppongo.
| + | * [[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) |
| | | | |
| − | Se così fosse, l'unico modo che mi viene in mente per rendere "costante" veramente il valore restituito da una funzione, nel caso di scalari (int, float etc...) è quello di scrivere:
| + | == Stickers for RFID tags == |
| | | | |
| − | const type var function(param);
| + | * 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 |
| | | | |
| − | temo che tuttavia non sia possibile "sempre". Il problema è che attualmente il compilatore "ignora" il const di ritorno. posso provare a castare ciò che ritorna la funzione con
| + | == Other stuff == |
| − | return (const type) var;
| + | |
| − | ma temo che, essendo passato per valore, sia completamente inutile.
| + | |
| | | | |
| − | Ci dica cosa ne pensa e cosa suggerisce per risolvere il warning, che comunque, non sono mai "belli" da tenere.
| + | ===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... |
| | | | |
| − | ----
| + | ===[[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!) |
| | | | |
| − | '''In sintesi''': Togliamo const dai return di tipo primitivo. Se Restelli è d'accordo (ma non vedo perchè non dovrebbe, dato che non hanno alcun effetto, se non una possibile non compilazione in futuro)
| + | ===Hardware stuff=== |
| | + | * In [[media:Spykee-datasheet.zip|this file]] I collected some useful datasheet of part of the hardware employed in the project |
| | | | |
| − | == Project status == | + | ===Mr. Brian / Fuzzy controller=== |
| − | === Implemented or partially implemented features ===
| + | * 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) |
| − | * Game design [metto qui la documentazione/storyboard?!?] | + | |
| − | * Porting to ROS of the Robowii modules (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, together with the messages that are exchanged and the interfaces with external libraries and\or the hardware.
| + | |
| − | [[File:RobotowerSchemaNodi.png|500px|center|Architecture of the implemented system]] | + | |
| − | * Integration of Mr. Brian into the project, and development of the first rules (Spykee searches the tower and goes toward it trying to avoid the obstacles, if any)
| + | |
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)
