|
|
| (149 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.
| + | |
| − | *[http://opencv.itseez.com/modules/calib3d/doc/camera_calibration_and_3d_reconstruction.html?highlight=findchess '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)
| + | |
| − | 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.
| + | |
| − | | + | |
| − | 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:
| + | |
| − | | + | |
| − | const type var function(param);
| + | |
| − | | + | |
| − | 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
| + | |
| − | 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.
| + | |
| − | | + | |
| − | ----
| + | |
| − | | + | |
| − | '''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)
| + | |
| − | | + | |
| − | == Project status ==
| + | |
| − | === Implemented or partially implemented features ===
| + | |
| − | * Game design. A document with the game storyboard and rules is available here: [[File:RobotowerStoryboard.pdf]].
| + | |
| − | * 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 (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]]
| + | |
| − | * 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
| + | |
| − | | + | |
| − | == Progettazione gioco ==
| + | |
| − | | + | |
| − | ===Analisi degli articoli===
| + | |
| − | | + | |
| − | Abbiamo letto entrambi gli articoli ne abbiamo ricavato alcune linee guida generiche, che poi abbiamo messo insieme in un file di testo, in modo da tenere presente in ogni momento gli scopi e le linee guida del progetto.
| + | |
| − | ====Caratteristiche generali del progetto:====
| + | |
| − | | + | |
| − | #Deve consistere in almeno un robot e almeno un umano in grado di interagire tra di loro cooperativamente o competitivamente in un gioco.
| + | |
| − | #Basso costo e alta efficienza dell’uso dei componenti
| + | |
| − | #Sicuro da giocare
| + | |
| − | #Semplice (per chi ci gioca)
| + | |
| − | #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:====
| + | |
| − | | + | |
| − | #Obbiettivo, chiaro e semplice.
| + | |
| − | #Sotto-obbiettivi se l’obbiettivo principale è troppo lungo (punti)
| + | |
| − | #Difficoltà adatta/adattabile al giocatore corrente
| + | |
| − | #Regole facili da capire e imparare
| + | |
| − | #Controlli (o azioni) facili da compiere
| + | |
| − | #Il sistema “gioco” reagisce 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 pensato
| + | |
| − | #Funzionamento Real-Time
| + | |
| − | | + | |
| − | ====Obbiettivi 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.
| + | == Documentation == |
| − | #Introdurre nella vita quotidiana il robot come qualcosa di “familiare” e utile
| + | |
| − | #Diffondere l’interesse per la robotica ad un pubblico più ampio
| + | |
| | | | |
| − | ===Discussione generica===
| + | * [[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) |
| | | | |
| − | 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:
| + | == Stickers for RFID tags == |
| − |
| + | |
| − | *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 perchè ridicolo renderli con un numero limitato di robot
| + | |
| − | *Platform: esclusi perchè fisicamente spesso poco realizzabili da un robot attuale
| + | |
| − | *Sportivi
| + | |
| − |
| + | |
| − | Dopo aver escluso i principali generi, abbiamo considerato i due generi rimasti
| + | |
| − | Sportivi: hanno come limite la necessità di avere un robot abbastanza dinamico
| + | |
| − | Strategici: hanno come limite la scarsa dinamicità dell’azione
| + | |
| − |
| + | |
| − | Si è analizzato più approfonditamente la categoria sportivi:
| + | |
| − | in questa categoria mettiamo:
| + | |
| − |
| + | |
| − | *Giochi di corse automobilistiche: non adattissimi
| + | |
| − | *Sport individuali: non appropriati
| + | |
| − | *Sport di squadra: in genere necessitano troppi elementi giocanti
| + | |
| − | *Lotta: non appropriata
| + | |
| − | *Giochi competitivi (di coppia o a piccole squadre)
| + | |
| − | *Giochi dei bambini
| + | |
| | | | |
| − | Nelle categorie accettate abbiamo messo la distinzione tra giochi con e senza palla.
| + | * 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) |
| − | alcune idee per limitare la velocità della palla sono state:
| + | * 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 |
| − | *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.
| + | |
| − |
| + | |
| − | “esempi” di giochi con palla sono:
| + | |
| − |
| + | |
| − | *“torello”
| + | |
| − | *Pallamano
| + | |
| − | *Air hookey
| + | |
| − | *Polo
| + | |
| − | *Schiaccia 7
| + | |
| − | *A.S.I.N.O
| + | |
| − |
| + | |
| − | esempi di giochi senza palla possono essere:
| + | |
| − |
| + | |
| − | *Nascondino
| + | |
| − | *Ce l’hai
| + | |
| − | *Caccia al tesoro
| + | |
| − |
| + | |
| − |
| + | |
| − | 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.
| + | |
| − |
| + | |
| − | Dei giochi strategici abbiamo considerato 3 sotto categorie:
| + | |
| − |
| + | |
| − | *Derivati dai giochi da tavolo
| + | |
| − | *Tower Defense
| + | |
| − | *Da bambini/ di intelligenza (le due cose non sono affatto in contrasto)
| + | |
| − |
| + | |
| − | un esempio di gioco “da tavolo” potrebbe essere il labirinto magico (famoso gioco da tavolo in scatola), in cui magari il labirinto è fatto con segnali luminosi (se possibile) o in altro modo. Labirinto magico è un labirinto che può cambiare configurazione in cui bisogna trovare degli oggetti (oppure potrebbe essere l’uscita... oppure il robot.
| + | |
| − | Altri giochi del genere potrebbero essere quelli ispirati a giochi come “battaglia navale” o altri giochi di strategia pensati.
| + | |
| − |
| + | |
| − | Un esempio di Tower defense potrebbe essere un gioco ispirato a Rock Of Ages, tale gioco consiste nel difendere il proprio castello dall’assalto di una palla demolitrice e comandare la suddetta palla contro quello dell’avversario. In questo caso il robot potrebbe svolgere la funzione della “roccia”, evitando gli ostacoli insormontabili, e travolgendo/distruggendo quelli che invece potrebbero solo rallentarlo o che gli bloccano il passaggio (distruggendo: ovvero spostando... o passandoci sopra) fino a raggiungere l’obbiettivo. 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”
| + | |
| − |
| + | |
| − | giochi “infantili” possono essere trova & nascondi (simili alla caccia al desoro) distruggi & costruisci, oppure un gioco in cui l’obbiettivo 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.
| + | |
| | | | |
| − | ===Discussione sul tower defense=== | + | == Other stuff == |
| | | | |
| − | Si è discusso dunque di come implementare un gioco stile tower defense, con una base da aggredire e dei mezzi per ostacolare il robot.
| + | ===ROS=== |
| − | Purtroppo sono sorti dei problemi, in quanto la natura intrinseca del genere impone degli impedimenti di natura fisica al robot. Si è pensato quindi di nascondere la torre/base, idea non scartata del tutto, ma comunque messa in secondo piano.
| + | * 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 |
| − | Si è pensato allora ad ostacoli insormontabili di natura fisica, e a loro limitazioni di utilizzo per evitare che il giocatore crei una catena attorno alla base, rendendola irraggiungibile.
| + | * Also, in the AirWiki there is an handy [[ROS_HOWTO|ROS Howto]], that is useful too... |
| − | Si è pensato pure alla possibilità di variare gli ostacoli fisici, magari introducendo variabilità nel loro comportamento (temporizzati, distruttibili etc). Si è pensato inoltre di aggiungere trappole invisibili tramite un lettore di codici QR sotto al robot, o in modo analogo, in modo che il robot si accorga di essere su una trappola solo nel momento effettivo in cui ci si trovi sopra.
| + | |
| − | Tutte queste trappole possono essere piazzate dinamicamente dal giocatore durante la partita.
| + | |
| − | si è inine deciso di attendere indicazioni sulla bontà e attuabilità del gioco prima di proseguire e incominciare a sviluppare l’altro tipo di gioco, quello sportivo con palla, se eventualmente questo non andasse bene.
| + | |
| | | | |
| − | ===Gioco sportivo e gioco infantile=== | + | ===[[Spykee]]=== |
| − | Un punto in comune a queste due bozze è l’utilizzo della palla come strumento di gioco. Questo può provocare problemi legati alla velocità del robot e all’agilità o comunque alla differenza tra i tipi di movimento attuabili da un robot rispetto a un giocatore umano, anche se questo problema può essere ridotto dal fatto che il gioco è diviso in aree separate. Eventualmente è possibile che l’area del robot sia più piccola di quella del giocatore. Inoltre, nella bozza di gioco sportivo, la possibile traiettoria è limitata dalla regola che obbliga la palla a rimbalzare nell’area neutra.
| + | * 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) |
| − | Nel gioco infanitile, la limitata velocità di un palloncino in qualche modo riduce i problemi legati alla lentezza di movimento del robot.
| + | * 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!) |
| − | Un altro problema legato ai giochi con la palla è la necessità da parte del robot di effettuare movimenti complessi per prenderla da terra, colpirla (eventualmente al volo) e direzionarla, ...
| + | |
| | | | |
| − | In ogni caso, abbiamo convenuto che 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. | + | ===Hardware stuff=== |
| | + | * In [[media:Spykee-datasheet.zip|this file]] I collected some useful datasheet of part of the hardware employed in the project |
| | | | |
| − | ===Creazione Storyboard Per il Gioco Tower defense=== | + | ===Mr. Brian / Fuzzy controller=== |
| − | Dopo aver brevemente discusso con il Professor Bonarini via e-mail, si è deciso che il gioco più idoneo a essere implementato era la bozza Tower Defense. Abbiamo quindi scelto il nome per il gioco, provvisorio, di RoboTower.
| + | * 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) |
| − | Si è discusso degli elementi principali del gioco, tra cui le caratteristiche di essere un gioco a tempo (che può però variare a seconda dello svolgimento) e sono state introdotte le fabbriche che producono crediti, spendibili per acquistare nuove trappoloe, pagandole al pc. Si è pensato che molte regole sarebbero state impossibili da implementare nel software, e quindi il rispetto di tali regole, come quella di pagare le trappole, o quella di poterne posizionare una alla volta, o ancora, l’obbligo di mettere gli ostacoli fisici nel tempo settato tra l’avvio del gioco e la partenza del robot; per queste regole ci si affiderà, almeno nella prima versione, alla fiducia che il giocatore le rispetti per avere una esperienza di gioco gratificante. Sono state quindi scartate le idee che avrebbero in parte reso possibile il controllo sul comportamento del giocatore, quali il distributore di trappole. E’ stata invece accettata, almeno momentaneamente, l’idea del lancia-palle (o comunque lancia-frecce), 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.
| + | |
| − | E’ stata inoltre pensata la pensata la possibilità di usare delle vignette per descrivere il comportamento del gioco, utilizzabili soprattutto in un eventuale tutorial.
| + | |
| − | Si è discusso inoltre del primo progetto sull’interfaccia grafica del gioco, che dovrà comparire sullo schermo del pc.
| + | |
| − | Si è inoltre deciso di cominciare il progetto considerando solo un giocatore e un robot, riservandosi la possibilità di ampliarlo in futuro, introducendo elementi cooperativi/compeitivi tra più umani e più robot.
| + | |
| − | Si è infine discusso, durante la stesura definitiva del testo sul ruolo degli ostacoli, soprattutto quelli che accecano o che coprono la visuale al robot. Si è deciso ch3e sia l’accecamento momentaneo del robot, sia ostacoli fisici “visivi” siano utili alla fine del gioco:
| + | |
| − | Se il robot spegne la vista, potrebbe vagare per il campo di gioco e perdersi in trappole oppure perdere la concezione di dove si trovava rispetto alla torre (sempre che l'abbia vista).
| + | |
| − | se il robot invece vede un oggetto che nasconde qualcosa può ignorare quel qualcosa di nascosto oppure può concentrarsi sull’oggetto, dietro al quale potrebbe celarsi però una trappola, magari ad ampio raggio.
| + | |
| − | Ognuna di quieste possibilità apre diversi scenari tattici possibili sia da parte della trappola umana, sia da parte dell’intelligenza del robot.
| + | |
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)
