Difference between revisions of "Talk:RoboTower"
| Line 1: | Line 1: | ||
| + | All the code for the project is hosted on github. The repository can be browsed [https://github.com/pogliamarci/robotower here]. | ||
| + | |||
==TODO== | ==TODO== | ||
| Line 10: | Line 12: | ||
#Lanciapalle | #Lanciapalle | ||
#Warning librerie brian e fuzzy | #Warning librerie brian e fuzzy | ||
| − | |||
| − | |||
==IDEE== | ==IDEE== | ||
| Line 19: | Line 19: | ||
'''Idee''': | '''Idee''': | ||
| − | * '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://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. | * 'Scacchiera': riconosciuta molto male: findchessboard in opencv probabilmente non fa grande elaborazione dell'immagine. | ||
| − | * 'ARToolKitPlus': i frame vengono riconosciuti molto velocemente, anche in movimento, sembra per ora, la strada migliore. Problema: dipendenza estrema da condizioni di luce. | + | * [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=== | ===Lanciapalle=== | ||
| − | |||
Progetto: | Progetto: | ||
Due motori in continua che lavorino simmetricamente per prendere la pallina e lanciarla a una velocità media. | Due motori in continua che lavorino simmetricamente per prendere la pallina e lanciarla a una velocità media. | ||
| − | |||
===Ostacoli invisibili=== | ===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) | 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: | 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 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. | 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | si dovrebbe ottenere un comportamento decente. | + | |
===Vittoria=== | ===Vittoria=== | ||
| − | |||
| − | |||
''Quando il robot Vince?'' per ora è implementato una condizione di vittoria che prevede: | ''Quando il robot Vince?'' per ora è implementato una condizione di vittoria che prevede: | ||
| − | vedere la torre | + | # vedere la torre |
| − | avere un ostacolo vicino (che si suppone sia la torre) | + | # avere un ostacolo vicino (che si suppone sia la torre) |
| − | Tuttavia, | + | 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 forma blob. Problema: blob da vision pessimo | ||
* controllo con marker | * controllo con marker | ||
| Line 90: | Line 79: | ||
| − | Ora, il | + | 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: | 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) | + | -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. | + | 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. | 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. | + | 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: | 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); | + | 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 | 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; | + | return (const type) var; |
ma temo che, essendo passato per valore, sia completamente inutile. | ma temo che, essendo passato per valore, sia completamente inutile. | ||
| Line 112: | Line 101: | ||
---- | ---- | ||
| − | 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) | + | '''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 [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) [metto qui lo schema?] | ||
| + | * Integration of Mr. Brian into the project, and development of the first rules (Spykee robot searches the tower and goes toward it trying to avoid the obstacles, if any) | ||
Revision as of 22:18, 21 March 2012
All the code for the project is hosted on github. The repository can be browsed here.
Contents
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
IDEE
Marker
Idee:
- '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.
- '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 Triangle_ol (TOL) si dovrebbe ottenere un comportamento decente.
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 -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)
Project status
Implemented or partially implemented features
- 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) [metto qui lo schema?]
- Integration of Mr. Brian into the project, and development of the first rules (Spykee robot searches the tower and goes toward it trying to avoid the obstacles, if any)
