Vamos a especificar algunos detalles técnicos de la práctica final, y de la parte de navegación que hemos hecho estos días.
Para mover el sensor de ultrasonidos, estamos utilizando el método rotateTo en lugar de rotate.
En principio los dos métodos son iguales, pero eso sólo ocurriría en un motor ideal. Sin embargo, se pueden producir pequeños errores en el movimiento. Si le decimos que rote 20º, puede girar entre 18º-22º (por poner un ejemplo).
En principio esto nos daría igual, pero lo malo es que estos errores son acumulativos. Hicimos una prueba, y con rotate, si girábamos 180º en tomas de 1º, acababa girando unos 230º, mucho error.
Sin embargo con rotateTo esto no ocurre porque, a pesar de tener el mismo margen de error, este no es acumulativo. Si giramos a la posición 5º, y luego queremos girar a la posición 10º, da igual si al principio se quedó en 3º, en 5º, en 6º, o en 20º. Irá a la posición 10º, con las mismas posibilidades de error, pero no acumuladas.
Para la impresión por pantalla utilizamos trigonometría básica, teníamos la hipotenusa, teníamos el ángulo, hallar los dos catetos estaba tirado.
La escala la hicimos utilizando las constantes de LCD.SCREEN_WIDTH/2 y LCD.SCREEN_HEIGHT.
El ancho lo dividimos entre dos porque hemos colocado el robot en medio, y la medida más larga será la mitad. En este caso además, debíamos sumarle LCD.SCREEN_WIDTH, para que los negativos pasaran a ser la parte izquierda y los positivos la parte derecha de la pantalla.
El único problema que tuvimos aquí fue acordarnos de los radianes, hasta que nos dimos cuenta, las medidas se iban dando vueltas por la pantalla.
El tema de la navegación ya es algo más complicado.
Al principio nos definimos varias constantes, entre ellas la resolución a utilizar, la distancia mínima, y el ángulo base.
La distancia mínima es una distancia de seguridad, que nos permite un cierto recorrido sin chocar.
El ángulo base, es un ángulo que definimos para dividir el espacio. Estos se solapan, es decir, con una resolución de 5º, y un ángulo base de 20º, el primero va de 0 a 20, el segundo de 5 a 25, etc.
Después de tomar las medidas, aplicamos un filtro, para eliminar ciertas medidas "extrañas", típicamente una muy alta (en torno a los 255, que también puede indicar un error) entre dos más discretas.
Seguidamente asignamos una nota a estos espacios en función de si cumplen la distancia mínima y de cuanto puede recorrer el robot. Actualmente utilizamos la media para asignar las notas, funciona bien, aunque nos estamos planteando utilizar el mínimo.
A partir de ahora trabajamos con estas notas. Detectamos cual es la mejor y buscamos los grupos seguidos más grandes. Esto es, si la nota máxima es de 45, buscamos el conjunto seguido de notas máximas. En este caso, para admitir pequeñas variaciones, aceptamos en el grupo notas un 10% más bajas que la máxima, en este caso, más de 41. Podríamos bajar un poco más, aunque de momento funciona bien, las pruebas dirán. Pero sí es importante para medidas altas, normalmente 255, para admitir desde 220.
Hay que tener en cuenta que hablamos de notas máximas, no de medidas máximas. ¡Siempre notas! De no ser así tendríamos problemas con picos en las medidas.
Una vez tenemos el inicio del mayor grupo y su tamaño, escogemos como mejor dirección la que esté en medio.
Para saber cuanto podemos andar buscamos la medida mínima en un rango de la mitad del ángulo base a cada lado (con un ángulo de 20º, 10º a cada lado). Estamos pensando en ampliar este márgen para que detecte bien las cosas, pero tendríamos que tener en cuenta que podemos salirnos del rango de medidas que tenemos. Sin embargo estamos esperando a ver los resultados de otra función que tenemos pensada para ver si aplicamos esta subida o no.
La función tratará de evitar que choquemos si, por ejemplo, cerca de una "puerta" en la que tenemos un espacio de 20º o más en el que no detectamos nada, pero en el hueco no entramos.
¡Iremos dando más detalles!
También hemos implementado una conexión USB para pasar todos los datos al ordenador. Nos dió problemas en los ordenadores de la universidad y acabamos intentandolo en casa.
También hubo muchos problemas porque no encotraba los drivers, hasta que después de googlear muchísimo y mirar las implementaciones de las comunicaciones, encontramos una entrada en el foro de Introducción a la Robótica de Carlos Agüero en el que explicaba que debíamos copiar el archivo libjlibnxt.so en /usr/lib. En lugar de copiar hicimos un enlace simbólico, y funcionó sin tocar nada más.
Sin embargo para hacer lo mismo con bluetooth no hemos sido capaces. Hemos mirado muchísima documentación, hemos probado muchas cosas, como hacer lo mismo con libjbluez.so, con los archivos de $NXT_HOME/3rdparty/lib (libbluecove.so y demás, extraidos de bluecove-gpl.jar) utilizar el fichero de configuración para cambiar a bluez, para cambiar a bluecove... nada ha dado resultado (a pesar de que nxjupload y nxjbrowse funciona por bluetooth).
Si no fuera por esto, lo tendríamos funcionando, y además seleccionando la conexión (USB o bluetooth).
miércoles, 22 de abril de 2009
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario