Difference between revisions of "Talk:RoboTower"

Revision as of 01:18, 5 April 2012

All the code for the project is hosted on github. The repository can be browsed here.

TODO

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

Project status

Implemented or partially implemented features

Game design. A document with the game storyboard and rules is available here.
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).

Architecture of the implemented system

Porting of Mr.Brian Tools in Ros Packages
- Rules Checker now works correctly.
- Gmbte porting complete.
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"

Soluzioni prese in considerazione:

Tag da riconoscere tramite visione

'DataMatrix': riconosciuti bene se fermi nell'immagine, ma troppo lentamente e non riconosciuti in movimento. Anche 3 secondi se non si impone un timeout. Abbiamo anche provato a sogliare l'immagine con imagemagick, su un frame che non riconosceva ma comunque abbastanza decente: nonostante la treshold provata a quasi ogni possibile livello tra 0 e 100% il risultato è pessimo, e l'immagine peggiora nettamente.
'Scacchiera (openCV cvFindChessboardCorners)': riconosciuta molto male: findchessboard in opencv probabilmente non fa grande elaborazione dell'immagine.
'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. L'unica possibilità è se si può migliorare il riconoscimento cambiando qualche parametro... ma la documentazione scarseggia...

Soluzioni alternative

'RFID': idea da prendere in considerazione, riportata anche qui
Radiosegnali: tecnologia in teoria conosciuta e facilmente riprodcibile (anche in laboratorio?) ma probabilmente non molto sfruttabile.
...

RFID

Dopo aver provato la scheda RFID per la prima volta, possiamo confermare dei risultati abbastanza buoni per la stessa.

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 (meglio se con antenna esterna sul 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.

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 Triangle_or (TOR) si dovrebbe ottenere un comportamento decente.

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:

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 vinto (il robot vince vedendo la torre, ad esempio, dietro un muro). errato!

Idee:

controllo forma blob. Problema: blob da vision pessimo
controllo con marker
controllo con RFID
controllo con interruttori a pressione

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?

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?

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 -Wextra, che provvede a passare il flag -Wignored-qualifiers. 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 "const" 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 "const" 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)

Passi avanti:

eliminati warnings cancellando semplicemente l'identificatore const ignorato. restano alcuni warnings dipendenti da flex/bison

Uso di MrBrian

I file

Cando.ini
want.txt
ctof.txt
PredicateActions.ini
Predicate.ini
s_ftoc.txt
shape_ctof.txt
s_shape.txt
behaviour.txt
file.rul

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.

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

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.

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_ftoc.txt

definisce quali sono i dati in uscita e che insieme di valori possono utilizzare

s_shape.txt

definisce gli insiemi di valori che possono usare i dati in uscita (solitamente singleton)

behaviour.txt

Lista dei possibili comportamenti e di dove trovarli nel filesystem

Regole (.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)

I livelli

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:

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

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

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.

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.

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.

Nello sviluppo dello 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.

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.

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.

@@ Line 228: / Line 228: @@
 =====Regole (.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)
 ====I livelli====