Commit 58a36591 authored by Federico Ciuffardi's avatar Federico Ciuffardi
Browse files

readme

parent b8ed8ad2
# Godot Touch Input Manager
# Multi-robot exploration based on space segmentation
## Como usar
Correr `.test_once [map_name] [starting_robot_number]` donde:
......@@ -6,3 +6,105 @@ Correr `.test_once [map_name] [starting_robot_number]` donde:
* `starting_robot` es un numero entre 1 y 5
Esto correspnde a explorar el entorno `map_name` con`starting_robot` robots.
# Libreria GVD - componentes
Se encuentra en `src/lib/GVD/` a continuacion se describen sus componentes.
## pos.h y pos.cpp
Contiene la definicion del tipo de dato `pos` que es una tupla de enteros (ints) que se utiliza a lo largo de la implentacion para modelar una posicion en la grilla de ocupacion.
Este tipo de datos define varias operaciones que se basan en interpretar `pos` como vectores.
## utils.h
Contiene funciones genericas, especificamente implementa el operador (<<) para poder visualizar las collecciones que usamos usualmente y tambien define la funcion `is_elem` que dado un dato y una colleccion devuelve `true` si y solo si ese dato es un elemento de la collecion.
## grid.h
Define grid que es una grilla (matriz) que que indica el estado de cada posicion (Ocupado,desconocido,etc). Y tambien algunas funciones utilies para el manejo de la grilla usando el tipo `pos` (por ejemplo la funcion `adj` que permite obtener los adyacentes validos o la funcion `cell` que permite obtener el contenido de una celda dado una pocicion).
## GVD.h y GVD.cpp
Define los grafos que representan a los GVD (usando la libreria de grafos de boost).
### genericGraph
Grafo generico cuyos nodos son identificados por posiciones (del tipo `pos`), sus operaciones son mas que nada wrapers de las funciones de boost, que buscan facilitar la manipulacion del grafo de boost, no agregan funcionalidad.
### uncolapsedGraph
Este grafo se basa en GenericGraph pero agrega una funcion que permite agregar un conjunto de posiciones al grafo de forma de que si dos posiciones son adyacentes en la grilla de ocupacion existira un enlace entre estas. (este no se utiliza en la implementaion incremental)
### collapsedGraph
Este grafo se basa en GenericGraph pero busca modelar un grafo donde si existen dos vertices adyacentes segun la grilla de ocupacion estos estaran conectados por un enlace. A su vez colapsando todos los nodos que cumplan las condiciones de colapsamiento, estas son que sean de grado 2 y sus enlaces tengan la misma direccion (tambien deben ser minimos locales en el mapa de distancia, se explicara despues).
Especificamente este grafo contiene dos representaciones:
* El grafo de boost: es la representacion colapsada del grafo, o sea que un nodo pertenece al grafo de boost si este no cumple con las condiciones de colapsamiento descriptas anteriormente. Y existe un enlace entre dos nodos de esta representacion si estos son vecinos entre si o si existe un conjunto de nodos collapsados que estan estan entre ellos.
* El grafo complento (`full_graph`): Es la representacion descolapsada (completa) del grafo. Esta se modela como un conjunto de posiciones donde una posicion esta en el conjunto si su nodo pertenece al grafo descolapsado. Las aristas se encuentran implicitas (si son adyacentes entonces estan conectados).
### nota
Las operaciones de agregado y remocion de vertices del grafo colapsado y descolapsado estan implementadas de forma que se cumpla lo descripto anterirmente.
## Map.h Map.cpp
La idea de esta estructura es facilitar el manejo de la representacion del mapa. Especificamente esta estructura "wrapea" una grilla de tipo `grid` y provee una funcion `update` que permite actualizar dicha grilla, y a su vez asegura que las acutalizaciones queden disponibles en su atributo `changes`.
## DisMapIC.cpp DisMapIC.h
El proposito de este es construir de forma incremental una grilla de distancia.
Aunque en un principio la idea fue que este componente sea generico (sirva para cualquier grilla de distancias) dado los limites de tiempo termino con codigo especifico para el caso de la grilla de distancia con los posibles puntos criticos como fuente. Esto es que tiene en cuenta cuales de las celdas son fronteras y mantiene un registro de que fronteras tienen asignados a que punto critico.
Estaria bueno que se lograra generalizar este componente para que sea usando tanto para la grilla de distancia con los posibles puntos criticos como fuente y con los obstaculos como fuente. (se requeriria algun mecanismo de hooks para permitir los comportamientos espesificos necesarios en cadas caso).
## critical\_info.h
Contiene el tipo de datos utilizado para representar la informacion de cuales son los puntos criticos, que fornteras tienen asignados y cual de estas es la mas cercana (y su distancia a esta `mind_f`).
Hay 2 `critical_info`:
* `critical_info`: es el que se uso en la implementacion no incremental. Guarda las fronteras asignadas en un vector donde el primer elemento (de indice 0) es la frontera mas cercana. `mind\_f` es solamente la distancia desde dicha frontera mas cercana al punto critico.
* `critical_info2`: es el usado en la implementacion incremental. Guarda las frotneras asignadas en un set. `mind_f` es un par (frontera mas cercana, distancia a la forntera mas cercana).
## GVDIC.h GVDIC.cpp
GVD Incremental Constructor, su tarea es contruir el gvd y ademas segmentar el espacio de forma incremental. Cada vez que se requiera un GVD y su segmentacion se debe llamar a la funcion `get_points_of_interest` con la ultima version de la grilla de ocupacion y esta devolvera, GVD y la segmentacion asociada (`critcals_info`).
## GVDC.h GVDC.cpp
GVD Constructor, version anterior que hace lo mismo que GVDIC pero de forma no incremental.
# Libreria GVD - Flujo
1. El modulo central crea una instancia de GVDIC.
1.1. Al crearse dicha instancia esta crea un Map y una instancia de DisMapIC a la cual le pasa la referencia al mapa y a un conjunto en el cual se almacenaran las fronteras libres.
2. Desde el modulo central cuando se requiere hacer una nueva subasta se llama a la funcion `get_points_of_interest` de la instancia de GVDIC
2.1. se limpian las estructuras que guardan los cambios de una iteracion.
2.2. se acutaliza el mapa
2.3. se obtienen los cambios
2.4. se actualizan las fronteras
2.5. se actualiza el mapa de distancias a los obstaculos y el GVD
2.5.1. Para calcular el mapa de distancia y los posibles puntos del GVD se usan las ideas inspiradas en el paper (poner link) utilizando multi-obstaculos en lugar de uno solo.
2.5.2 Al calcular el mapa de distancia a obstaculos se determina que celdas pueden pasar o dejar de formar parte del GVD y estas se erosionan para determinar cuales son realmente los nodos del GVD. Una vez determinados esto, se insertan y remueven los nodos en el GVD (que es un collapsedGraph) segun corresponda.
2.5.3. TODO(explicar lo de los posibles criticos, las condiciones y explicando tambien lo del minimo local y de porque no se pueden colapsar estos)
2.6. se actualiza el mapa de distancias a los posibles criticos (a traves de la instancia de DisMapIC) TODO(explicar como y que es bien lo que se hace aca con las fornteras y los datos que se van a necesitar para deteminar bien los criticos )
2.7. se acutalizan los criticos
2.8. se adapta la salida para devolver las estructuras que espera la central. Esto porque la central espera lo que devolvia GVDC (implentacion anterior) y para evitar problemas y probar rapidamente lo implementado hicimos una funcion (`generate output`) que tranforma lo generado por GVDIC y lo devuelve en el formato de lo generado por GVDC, que es lo que espera la centra. Esto deberia modificarse de forma que la central manipule directamente lo generado por GVDIC. Las problematicas de esto es que al utilizarse el grafo colapsado no se puede guardar la informacion solo en los nodods del grafo de boost (lo que se hacia antes) si no que habria que guardarlo en otra estructura mas relacionado con el `full_graph`. Tambien habria que ver como asignar los segmentos al grafo de forma incremental (detectar cuando un nodo cambia de segmento cuando se hace el mapa de distancia a los posibles criticos.
# TODO(Estaria bueno ahora seguir explicando mas a detalle algunos pasos, tambien se podria repensar la seccion anterior a ver si se puede organizar distinto)
# TODO(Ver en el trello si se puede agregar algo)
# Bugs experimentados
* Hay casos en los cuales el GVD queda disconexo. Deberia ser siempre conexo.
* Pareceria que hay criticos que quedan con fronteras asignadas que ya no son fornteras, posiblemente se deba a como se manejan las asigaciones de fronteras a criticos. Ya sea en DisMapIC.cpp o cuando se generan las estructuras en GVDIC.cpp,
* Esto no es estrictamente un bug. En algunos caso se puede ver que el GVD generado es incecesariamente complejo, se podria implemtar algun tipo de cleanup mas complejo que solamente la erosion para evitar esto.
# Notas
Tenemos una convencion para algunas colecciones que es nombralas como `priopiedad_to_true` y `propiedad_to_false` un punto pertenece a alguna de estas colleciones si para el incremento la propiedad paso a ser true o false para ese punto.
# Glosario
fronteras libres: fronteras que a su ves no se encuentran obstaculizadas, son los posibles objetivos de exploracion.
#include <iostream>
#include "GVDIC.h"
using namespace std;
int main(int argc, char** argv) {
return 0;
}
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment