Commit 2ba11684 authored by Federico Ciuffardi's avatar Federico Ciuffardi
Browse files

update readme

parent fc53114f
# Multi-robot exploration based on space segmentation
## Como usar
Correr `.test_once [map_name] [starting_robot_number]` donde:
Correr `./test_once.sh [map_name] [starting_robot_number]` donde:
* `map_name` puede ser `labyrinth` o `office`
* `starting_robot` es un numero entre 1 y 5
Esto correspnde a explorar el entorno `map_name` con`starting_robot` robots.
# Libreria GVD - Introduccion
Esta libreria puede ser compilada y ejecutada sin usar ROS.
# Libreria GVD - componentes
Para esto ejecutar en el directorio de la libreria `src/lib/GVD/`:
```
cmake .
make
```
Luego es posible correr las pruebas desarrolladas ejecutando:
```
./test i
```
Donde i es el numero de prueba a ejecutar.
# Libreria GVD - Componentes
Se encuentra en `src/lib/GVD/` a continuacion se describen sus componentes.
......@@ -48,9 +62,9 @@ La idea de esta estructura es facilitar el manejo de la representacion del mapa.
## 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.
Aunque en un principio la idea fue que este componente sea generico (sirva para cualquier grilla de distancias) dado los limites de tiempo este tiene codigo especifico para el caso de la grilla de distancia con los posibles puntos criticos como fuente. El codigo especifico es 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).
Estaria bueno que se lograra generalizar este componente para que sea usado tanto para la grilla de distancia con los posibles puntos criticos como fuente y con los obstaculos como fuente (evitando repetir codigo). Para lograr esto se puede utilizar algun mecanismo de hooks para permitir establecesr los comportamientos espesificos necesarios en cada 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`).
......@@ -67,51 +81,59 @@ GVD Constructor, version anterior que hace lo mismo que GVDIC pero de forma no i
# Libreria GVD - Flujo
El proposito de esta libreria es obtener cada cierto tiempo, de forma incremental, un GVD y los otros datos necesarios (contenidos en un valor de tipo `critical_info`) para realizar una subasta y que terminada esta los robots puedan navegar segun corresponda.
El proposito de esta libreria es obtener cada cierto tiempo, de forma incremental, un GVD y los otros datos necesarios (contenidos en un valor de tipo `critical_info`) para realizar una subasta y para que una vez terminada dicha subasta los robots puedan navegar segun lo determinado en dicha subasta.
A continuacion se mostrara el flujo para lograr lo antes mencionado en el contexto del trabajo desarrollado.
1. El modulo central crea una instancia de GVDIC.
1. El modulo central crea una instancia `gvdic` de `GVDIC` y el constructor de `GVDIC` hace lo siguiente:
1.1. Esto implica crear una instancia de `Map` la cual se usara para mantener el estado del entorno,
1.1. Crea una instancia `m` de `Map`.
1.2. 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.
1.2. Crea unas instancia `disMapIC` de `DisMapIC` para lo cual se le pasa la referencia al mapa `m`, los tipos de celda que se consideran ocupados y un conjunto en el cual se almacenaran fronteras libres.
2.2. se acutaliza el mapa
2. Desde el modulo central cuando se requiere hacer una nueva subasta se llama a la funcion `get_points_of_interest` `gvdic` con el `grid` que contiene la ultima informacion sobre el entorno como parametro, en la cual:
2.3. se obtienen los cambios
2.1. se limpian las estructuras que guardan los cambios de una iteracion.
2.4. se actualizan las fronteras
2.2. se actualiza el mapa `m` con la informacion contenida en el `grid`.
2.5. se actualiza el mapa de distancias a los obstaculos y el GVD
2.3. se clasifica a las celdas cuyo estado difiere con respecto al `grid` con el que se llamo `get_points_of_interest` la ultima vez. Las clasificaciones son conjuntos, por ejemplo, las celadas cuyo estado cambio de obstruido a libre llamado `obs_to_free`.
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.4. se actualizan las fronteras
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. se actualiza el mapa de distancias a los obstaculos. Para esto se usan ideas inspiradas en [1] utilizando multi-obstaculos en lugar de uno solo.
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.5.1 Al calcular el mapa de distancia a obstaculos se determina que celdas pueden pasar (`voro_to_true`) o dejar (`voro_to_false`) de formar parte del `GVD`
2.6. se actualiza el `GVD`.
2.6.1 A partir de los conjuntos `voro_to_true` y `voro_to_false` se dermina con algoritomo de erosion o "brush fire" [2] cuales celdas realmente pasan a ser o dejan de ser partes `GVD`. Una vez determinados esto, se insertan y remueven los nodos en el `GVD` (que es un `collapsedGraph`) segun corresponda.
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.6.2. Al final de la actualizacion del `GVD` se computan las celdas que pasan a ser (`possible_crit_to_true`) y las que dejan de ser (`possible_crit_to_false`) posibles criticos. Una celda es un posible critico si cuple todas las condiciones para ser criticos (explicadas en [3]) con excepcion de la cercania de estas celdas a lo desconocido, ya que para mantener la incrementalidad la cercania a lo desconocido sera calculada a partir de un mapa de distancias con los posibles criticos como fuentes.
2.7. se acutalizan los criticos
2.7. se actualiza el mapa de distancias a los posibles criticos (a traves de la instancia de `DisMapIC` creada en *1.2*)
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.
2.7.1 Como se menciono en la descripcion del componente `DisMapIC` intenta generalizar la construccion de mapas de distancia de forma incremental. Su codigo es similar al usado para la construccion del mapa de distacia y ademas contiene codigo especifico utilizado para determinar los puntos criticos.
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 )
# 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)
2.8. se acutalizan los criticos
TODO(explicar como se hace esto )
# TODO(Ver en el trello si se puede agregar algo)
2.9. 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.
# 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.
* Pareceria que hay criticos que quedan con fronteras asignadas que ya no son fornteras (causando falsos puntos criticos). **Posiblemente** se deba a como se manejan las asigaciones de fronteras a criticos (es decir no se remueven las fronteras de los criticos cuando estas dejan de ser fornteras). Ya sea en DisMapIC.cpp o cuando se generan las estructuras en GVDIC.cpp.
* En algunos casos 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. Esto no es estrictamente un bug, sino que una posible mejora.
# 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.
# Referencias
[1] Lau, B., Sprunk, C. and Burgard, W., 2013. Efficient grid-based spatial representations for robot navigation in dynamic environments. Robotics and Autonomous Systems, 61(10), pp.1116-1130.
[2] Zhang, T.Y. and Suen, C.Y., 1984. A fast parallel algorithm for thinning digital patterns. Communications of the ACM, 27(3), pp.236-239.
[3] Wurm, K.M., Stachniss, C. and Burgard, W., 2008, September. Coordinated multi-robot exploration using a segmentation of the environment. In 2008 IEEE/RSJ International Conference on Intelligent Robots and Systems (pp. 1160-1165). IEEE.
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