Defensa de la práctica 1

¡¡¡Práctica 1 aprobada!!! Por fin tenemos la primera práctica oficialmente aprobada, lo cual no facilita la defensa de la segunda.

Durante la sesión de hoy estuvimos defendiendo la primera práctica y además se intentaron realizar una serie de mejoras de la práctica 2, pero éstas fallaron y debido a la falta de tiempo y la complejidad que supondría estar comprobando código y hacer que todo funcionara a la perfección desistimos, y hemos optado por dejar la práctica como estaba, con esperanzas reales de aprobar.

Mejoras en la práctica

Parece que hemos dado con el fallo que hacía que los robots no recorrieran bien el circuito. Lo probamos y ambos robots recogían sus objetos correspondientes de forma correcta, a pesar de ser un poco lentos a la hora de buscar el camino a seguir. En vista de que el algoritmo ha progresado y las unidades robóticas recorren el circuito, hemos decido realizar una de las mejoras de la práctica, que consiste en volver a colocar los objetos en el sitio en el que se encontraban. Lo hemos dejado pendiente para hacerlo por la tarde.

Algoritmo antichoques

Ahora toca hablar del algoritmo antichoques implementado.

Con el objetivo final de la implementación de un algoritmo capaz de evitar las colisiones entre los dos robots, se realizaron diversos ajustes en el código que lo permitieran. Entre ellos, destaca un uso mucho mayor del bluetooth, pues ahora no envía “novedades“, sino que envía información sobre cada punto por el que pasa, de manera que el otro robot tenga la información más actualizada posible sobre la posición de su compañero. Esto hizo que tuviéramos que hacer pruebas más intensivas de los algoritmos de comunicación y del protocolo utilizado, resultando efectivos en todos ellos.

Por ello, tras cada recepción de mensaje, se guarda en variables globales la posición del otro enemigo, y con ella es con la que se comenzó a trabajar en el algoritmo antichoques.

El algoritmo antichoques basa su funcionamiento en una función matemática que calcula las distancias entre el punto siguiente al que se va a mover el robot, y la posición del compañero. Si esta distancia es menor de dos puntos (queriendo esto decir que el robot está próximo a [1] o sobre el [0] robot), impedimos que pueda realizar ese movimiento y, por el contrario, tratará de alcanzar un punto distinto.

Este algoritmo, aunque comprobamos que es efectivo y funciona de manera satisfactoria, podría dar lugar a algunos problemas, como puede ser un mucho mayor tiempo de recorrido, pues hace necesario desviarse del camino deseado para poder esquivar al compañero. Sin embargo, tras debatir sobre los distintos algoritmos posibles, se llegó a la conclusión de que, probablemente, este fuera el más efectivo posible, teniendo en cuenta lo bien que podía ajustarse al código actual y su poca repercusión en él.

Se tuvieron en consideración otras ideas, como fue que el robot enviara la posición destino antes de moverse, y así el compañero poder predecir cuándo podrían chocarse. El problema de esta idea, es que se dependía en exceso de una más que cuestionable velocidad de transmisión del mensaje, de manera que pudiera darse que el mensaje llegara una vez hubiéramos empezado el movimiento. En el algoritmo implementado, en cambio, no dependes tanto del destino al que se mueve el otro robot sino de su posición actual, además de disponer siempre del colchón que supone hacer los cálculos sobre el punto siguiente al que te vas a mover, y no sobre tu posición actual.

8 Julio

Seguimos con el trabajo compartido, diviendo nuestro grupo para poder abarcar ambas prácticas poniendo nuestras esperanzas en obtener un buen resultado en la práctica 1 y demostrar el trabajo y el tiempo que hemos dedicado a la práctica final.

La práctica 1 avanza favorablemente. Nos ha sorprendido lo fácil que nos resulta ahora programar el NXT para obtener unos resultados favorables al bordear obstaculos, despues de habernos enfrentado al gran nivel de dificultad de la práctica 2. Hemos optado por modificar una de las políticas estudiadas durante la primera parte del curso y mejorarla. Esta política se basa en bordear el obstaculo comprobando en todo momento la distancia entre éste y el Robot, corrigiendo así el trayecto en caso de alejarnos o acercarnos demasiado, y sin realizar giros bruscos. Las primeras pruebas con ésta política parecen ser favorables, aunque aun debemos perfeccionar ciertos aspectos, como el rango de la distancia y las velocidades.

En cuanto a la práctica 2, los NXT siguen dándonos fallos, que a pesar de no ser realmente graves, impiden que se muevan correctamente por el circuito. Entre éstos errores se encuentran la incorrecta localización de los NXT dentro de la representación interna del mapa, así como algunos problemas a la hora de sortear ciertos obstaculos, teniendo problemas con la búsqueda de caminos alternativos.

Nos queda una larga tarde por delante en la que esperamos avanzar en éstos problemas, y dar por finalizada la práctica 1.

Retoma de la primera práctica

Debido a los problemas surgidos con la práctica 2 y dado el correo que mandó el profesor de la asignatura, vimos que era necesario tener hecha la práctica 1 para que, en caso de que la defensa de la práctica 2 no sea efectiva, nuestro trabajo y todas las horas invertidas en ella no sean en vano y podamos entregarle una memoria explicando todo lo que hemos hecho, con pelos y señales.

De esta manera, en la sesión de hoy nos hemos dividos y unos integrantes de nuestro grupo han seguido con la práctica 2 y otros han retomado la práctica 1. Dado que nuestro algoritmo de seguir la línea negra de la práctica 1 estaba bien, hemos utilizado el mismo código, y hemos planteado una manera más eficiente y compacta de enfrentar la solución a la hora de bordear los obstáculos.

Hemos comenzado con el algoritmo y aún estamos en ello,  pero hemos sido previsores y teniendo en cuenta algunos de los problemas surgidos en la defensa, hemos optado por utilizar como obstáculos objetos que sean cilíndricos, tales como las papeleras existentes en el laboratorio, debido a que reduce bastante las posiblidades de que el robot no vea el obstáculo y por tanto,  realice un bordeado mejor.

2 Julio

Hoy hemos conseguido que cada robot por separado recorra el circuito de una manera correcta. Hecho esto, procedimos a poner los dos robots a la vez  en el mismo circuito. La información parece que se envía bien pero, cuando parecía que todo salía  a la perfección , el algoritmo comenzó a fallar, dando problemas a la hora de recorrer caminos que no son los adecuados.

Como llevamos muchas horas programando , hemos decidido arreglar este problema mañana, con el objetivo de terminar con esto lo antes posible para su futura defensa.

Problemas con el sensor de luz

Cuando parecía que el camino se nos iluminaba, comenzó a fallar el sensor de luz al captar el color blanco de las intersecciones. Tuvimos que cambiar muchas veces el rango del color blanco para que no diera problemas. Suponemos que es debido a que entra más luz en el laboratorio y el valor que recibe difiere de los obtenidos al comienzo de la práctica.

Asimismo, se intentó que el NXT recorriera el circuito y lo hace de manera que recorre ciertas partes del mismo de forma relativamente bien. Sin embargo, debido a los problemas surgidos con la detección del color blanco no realiza un recorrido perfecto, no detectando que las bases de ese color y por tanto, no enviando la información al otro NXT.

Mejoras

Con el objetivo de conectar los robots correctamente para que ambos fueran capaces de transmitirse mutuamente la información necesaria,  durante esta sesión se trabajó sobre la conexión bluetooh. Se producían una serie de fallos a la hora de enviar la información, pero conseguimos corregirlos. Aún así, se actualizaba la información recibida pero el algoritmo de búsquedad fallaba haciendo que el robot tomara como “libres” posiciones donde había un obstáculo visto por el otro robot.

Por otro lado, se trabajó en la mejora del algoritmo de búsqueda. Para ello, se hizo en C el algoritmo  A* debido a que es más eficiente que el algoritmo de búsqueda en profundidad. Una vez hecho en C , se intentó pasar a NXC perdiendo la batalla debido a la cantidad de problemas que surgían, como por ejemplo no dejar pasar “structs” por parámetros que dificultaban mucho la tarea. De esta manera y con el tiempo perdido, desisitimos y decidimos dejar las cosas como estaban. Y con ello, dimos por finalizada la sesión.

Seguimos con la práctica

Durante esta sesión, se mejoró la captura de los valores obtenidos por cada uno de los sensores, con el obtetivo de que fuera más preciso.  Para ello, se realizan una serie de medidas de cada uno de los valores y se calcula la media de los mismos, tomando como válido el resultado de dicha media. Con esta modificación, parece que la visualización de los obtáculos a mejorado.

Actualización del algoritmo de búsqueda

Tal y como se había comentado, nos surgieron una serie de problemas a la hora de recorrer el circuito debido a una mala implementación del algoritmo de búsqueda. Durante esta sesión en el laboratorio conseguimos corregir el fallo, que se producía auna mala condición a  la hora de evaluar el camino. De esta manera, el NXT era capaz de recorrer el circuito entero sin ningún obstáculo.

Asimismo, se programó el NXT para que permitiera introducirle manualmente la base desde donde empieza a recorrer el circuito. Con ello, se retomaron las pruebas para la evaluación de la nueva versión de la práctica, obteniendo mejores resultados que los anteriores y corrigiendo pequeños fallos que se producían.