Hola de nuevo,
la última práctica que nos han puesto consiste en implementar un algoritmo que nos permita autolocalizarnos en un mapa dado.
Para ello hemos implementado varias clases.
Clase Radar: Implementa un radar parametrizable, es decir, se puede configurar a medida en cuanto a velocidad, resolución y amplitud de la medición.
Clase Localización: Esta clase carga y nos muestra el mapa con las partículas por el LCD del robot.
Clase Reconocimiento:Se compone de dos etapas independientes.
La primera etapa consiste en ir situando al robot en varios puntos entonces, mediante nuestro radar, el robot realiza mediciones, las cuales son guardadas en un histograma para poder reconocer el punto posteriormente.
La segunda etapa del reconocimiento reza por localizar el robot en el mapa, se realizan mediciones y se va comparando el histograma obtenido con las muestras representivas de cada punto.
La semana que viene combinaremos toda la potencia de las clases implementadas para conseguir autolocalizarnos en un mapa y poder seguir una ruta predispuesta.
martes, 13 de abril de 2010
jueves, 25 de marzo de 2010
Filtros de partículas
Aquí venimos una vez más con prácticas de nuestro robot.
En esta ocasión hemos tratado de implementar un filtro de partículas en nuestro robot para poder llegar a auto-localizarnos en un mapa según nuestra posición.
Lamentablemente no hemos conseguido llegar a dar solución al problema.
El otro apartado de la práctica era relativamente más fácil ya que consistía en manejar el robot mediante una secuencia de coordenadas(x,y) y orientación.
Introducimos el punto final mediante incrementos a través de los botones LEFT/RIGHT del robot presionando ENTER para escribir el punto.
Igualmente introducimos la orientación final a través de los botones de nuestro robot.
Una vez introducidos el punto y la orientación el robot navega al lugar indicado.
La gracia de todo esto consiste en que si nuestro robot parte de un punto(0,0) el solo sabrá ir a cualquier punto del mapa volviendo al origen si se le indica.
Como se puede apreciar en el primer video indicamos a nuestro robot que se desplace a el punto (20,20) y finalice con la orientación inicial(0).
En el segundo video se indica al robot que se desplace al punto(0,0) partiendo del punto del video anterior, al final debe acabar con una orientación de -90 grados desde la posición inicial original, es decir desde la posición inicial del primer video.
Un saludo.
En esta ocasión hemos tratado de implementar un filtro de partículas en nuestro robot para poder llegar a auto-localizarnos en un mapa según nuestra posición.
Lamentablemente no hemos conseguido llegar a dar solución al problema.
El otro apartado de la práctica era relativamente más fácil ya que consistía en manejar el robot mediante una secuencia de coordenadas(x,y) y orientación.
Introducimos el punto final mediante incrementos a través de los botones LEFT/RIGHT del robot presionando ENTER para escribir el punto.
Igualmente introducimos la orientación final a través de los botones de nuestro robot.
Una vez introducidos el punto y la orientación el robot navega al lugar indicado.
La gracia de todo esto consiste en que si nuestro robot parte de un punto(0,0) el solo sabrá ir a cualquier punto del mapa volviendo al origen si se le indica.
Como se puede apreciar en el primer video indicamos a nuestro robot que se desplace a el punto (20,20) y finalice con la orientación inicial(0).
En el segundo video se indica al robot que se desplace al punto(0,0) partiendo del punto del video anterior, al final debe acabar con una orientación de -90 grados desde la posición inicial original, es decir desde la posición inicial del primer video.
Un saludo.
jueves, 11 de marzo de 2010
Navegación local evitando obstáculos
Hasta ahora el comportamiento de nuestro robot ha sido completamente iterativo y lineal. En esta última práctica hemos aprendido a programar el robot con varios comportamientos que compiten por controlarlo heredando de la clase Behavior.
Evitación de obstáculos usando sensores de contacto
El robot cuando choca con un objeto, retrocede, describe un arco a la derecha de él y vuelve a quedarse en el mismo ángulo de orientación. Con el "control" que poseemos ya sobre la clase TachoPilot no nos ha dado ningún quebradero de cabeza.
Evitación de obstáculos usando el sensor de ultrasonidos
En este apartado se suponía que el robot debía de evitar un obstáculo usando el algoritmo de VFF's, pero lo máximo que hemos llegado a conseguir es realizar un radar que escanea entre , y quedarnos con mal sabor de boca, al saber que estábamos muy cerca de que funcionase.
Comportamiento de ir hacia la luz
Gracias a este comportamiento, y a los dos sensores de luz de su primo el NCX el robot se orienta hacia la luz. No avanza ya que tenemos otro comportamiento básico "avanzar" que se encarga de ello. La función básica es eso, girar hasta encararse a la luz más fuerte.
Comportamiento de ir hacia la luz evitando obstáculos
Aquí nuestro pequeño artefacto ya tiene varios comportamientos compitiendo: el de avanzar, orientarse hacia la luz, y evitar un obstáculo. Para evitarlo hemos usado el comportamiento que se vale de los sensores de contacto, ya que el de UltraSonidos mediante VFF's no fuimos capaces.
Evitación de obstáculos usando sensores de contacto
El robot cuando choca con un objeto, retrocede, describe un arco a la derecha de él y vuelve a quedarse en el mismo ángulo de orientación. Con el "control" que poseemos ya sobre la clase TachoPilot no nos ha dado ningún quebradero de cabeza.
Evitación de obstáculos usando el sensor de ultrasonidos
En este apartado se suponía que el robot debía de evitar un obstáculo usando el algoritmo de VFF's, pero lo máximo que hemos llegado a conseguir es realizar un radar que escanea entre , y quedarnos con mal sabor de boca, al saber que estábamos muy cerca de que funcionase.
Comportamiento de ir hacia la luz
Gracias a este comportamiento, y a los dos sensores de luz de su primo el NCX el robot se orienta hacia la luz. No avanza ya que tenemos otro comportamiento básico "avanzar" que se encarga de ello. La función básica es eso, girar hasta encararse a la luz más fuerte.
Comportamiento de ir hacia la luz evitando obstáculos
Aquí nuestro pequeño artefacto ya tiene varios comportamientos compitiendo: el de avanzar, orientarse hacia la luz, y evitar un obstáculo. Para evitarlo hemos usado el comportamiento que se vale de los sensores de contacto, ya que el de UltraSonidos mediante VFF's no fuimos capaces.
miércoles, 3 de marzo de 2010
Navegando
Estamos implementando a base de comportamientos un programa para conseguir que el robot evite obstáculos pero yendo hacia la luz.
Como realizar tal hazaña?Con vectores de fuerzas.
Hay dos vectores:
Vector repulsión: Nos indica hacia donde alejarnos del objeto.
Vector atracción: Nos indica hacia donde ir.
Estos vectores se recalculan a tiempo real.
Luego mediante coordenadas polares podemos hallar nuestra (x,y):
x = ro · cos(teta)
y = ro · sen(teta)
Hasta aquí fácil,el problema esta en calcular ese ángulo y esa distancia.
Para el objeto es relativamente fácil,nosotros siempre partimos del (x=0,y=0), avanzamos y al chocar calculamos los vectores.La distancia al objeto nos la dará el sensor de ultrasonidos o el de contacto y el ángulo nos sera dado por la odometría de nuestros motores de empuje, la cual será reseteada para conseguir evitar los errores lo máximo posible.
Para la luz hay mas pegas.Necesitamos también el vector de atracción.
¿Cómo detectar la distancia a la que esta la luz?¿Como saber a que ángulo esta la luz?
De momento tenemos pensadas varias estrategias:
Para averiguar el ángulo de la luz podemos utilizar una estimación de los sensores de luz los cuales están en el frente del robot orientados con un ángulo de 45º a cada lado.El problema nos surge si cambiamos la intensidad de la luz ya que rompería muestras medidas previas.
El otro punto clave es la distancia a la luz para poder calcular el vector atractivo.
En un primer momento intentamos calcular la distancia con los sensores de luz pero había tan poca separación que la luz recibida a 60cm, 100cm, 200cm era prácticamente la misma y por si fuera poco cambiaría con el tipo de luz.Nos daba miedo fiarnos de una medida tan poco precisa.
Posteriormente nos dimos cuenta de que la luz solamente nos marca la dirección a seguir.Nos da igual la distancia a la que esté, entonces, ¿porque no fijar esta distancia a un valor constante?
Al fijar la distancia a la luz es posible obtener vectores resultantes que nos hicieran movernos hacia atrás y eso es de cobardes.
Pero podemos implementar que en el vector resultante de movimiento la componente y sea siempre positiva y así nunca llegar a retroceder.
Aún esta en pruebas,iremos informando.
Como realizar tal hazaña?Con vectores de fuerzas.
Hay dos vectores:
Vector repulsión: Nos indica hacia donde alejarnos del objeto.
Vector atracción: Nos indica hacia donde ir.
Estos vectores se recalculan a tiempo real.
- Calcular vector de atracción.
- Calcular vector de repulsión.
- Calcular vector resultante.
- Traducir el vector resultante al movimiento del robot.
Luego mediante coordenadas polares podemos hallar nuestra (x,y):
x = ro · cos(teta)
y = ro · sen(teta)
Hasta aquí fácil,el problema esta en calcular ese ángulo y esa distancia.
Para el objeto es relativamente fácil,nosotros siempre partimos del (x=0,y=0), avanzamos y al chocar calculamos los vectores.La distancia al objeto nos la dará el sensor de ultrasonidos o el de contacto y el ángulo nos sera dado por la odometría de nuestros motores de empuje, la cual será reseteada para conseguir evitar los errores lo máximo posible.
Para la luz hay mas pegas.Necesitamos también el vector de atracción.
¿Cómo detectar la distancia a la que esta la luz?¿Como saber a que ángulo esta la luz?
De momento tenemos pensadas varias estrategias:
Para averiguar el ángulo de la luz podemos utilizar una estimación de los sensores de luz los cuales están en el frente del robot orientados con un ángulo de 45º a cada lado.El problema nos surge si cambiamos la intensidad de la luz ya que rompería muestras medidas previas.
El otro punto clave es la distancia a la luz para poder calcular el vector atractivo.
En un primer momento intentamos calcular la distancia con los sensores de luz pero había tan poca separación que la luz recibida a 60cm, 100cm, 200cm era prácticamente la misma y por si fuera poco cambiaría con el tipo de luz.Nos daba miedo fiarnos de una medida tan poco precisa.
Posteriormente nos dimos cuenta de que la luz solamente nos marca la dirección a seguir.Nos da igual la distancia a la que esté, entonces, ¿porque no fijar esta distancia a un valor constante?
Al fijar la distancia a la luz es posible obtener vectores resultantes que nos hicieran movernos hacia atrás y eso es de cobardes.
Pero podemos implementar que en el vector resultante de movimiento la componente y sea siempre positiva y así nunca llegar a retroceder.
Aún esta en pruebas,iremos informando.
One up!!
Hemos pensado algunas mejoras, ya que una vez todo implementado y probado salía a la fuerza una versión 2.0
En el Bump&Go nos dimos cuenta de que si por casualidad, y digo casualidad porque giraba aleatoriamente, el robot diera con un callejón se quedaría bloqueado.
Me explico; el "rastrillo" que accionaba el sensor al chocar era demasiado estrecho y si conseguía pasar el rastrillo no paraba a nuestro robot el cual se atascaba.Por ello dotamos a nuestro "esclavo" con un rastrillo más ancho de modo que cubriera con creces la longitud del eje de las ruedas.
Por otra parte en el Bum&Go de Ultrasonidos, nos dimos cuenta de que sobraban cosas.
A la hora de "chocar" con algo, el robot, reculaba para poder realizar el giro y no entorpecerse con el obstáculo.
Y ahora?No, al cambiar el tipo de sensor, también cambia el algoritmo.Ya no necesitamos andar hacia atrás.Ahora solo hay que preocuparse de "chocar" con el obstáculo a una distancia suficiente para no entorpecer el giro.
Ahora choca sin tocar,simplemente.
Midiendo tu marchita y al tran-tran,
Buscando la salida,porque si hay una salida por aquí tiene que estar.
En el Bump&Go nos dimos cuenta de que si por casualidad, y digo casualidad porque giraba aleatoriamente, el robot diera con un callejón se quedaría bloqueado.
Me explico; el "rastrillo" que accionaba el sensor al chocar era demasiado estrecho y si conseguía pasar el rastrillo no paraba a nuestro robot el cual se atascaba.Por ello dotamos a nuestro "esclavo" con un rastrillo más ancho de modo que cubriera con creces la longitud del eje de las ruedas.
Por otra parte en el Bum&Go de Ultrasonidos, nos dimos cuenta de que sobraban cosas.
A la hora de "chocar" con algo, el robot, reculaba para poder realizar el giro y no entorpecerse con el obstáculo.
Y ahora?No, al cambiar el tipo de sensor, también cambia el algoritmo.Ya no necesitamos andar hacia atrás.Ahora solo hay que preocuparse de "chocar" con el obstáculo a una distancia suficiente para no entorpecer el giro.
Ahora choca sin tocar,simplemente.
Midiendo tu marchita y al tran-tran,
Buscando la salida,porque si hay una salida por aquí tiene que estar.
lunes, 22 de febrero de 2010
Calibracion del Sensor de Ultrasonidos
Una vez obtenidos los datos calculamos la matriz de covarianza con excel y cuatro sencillas formulas.
0.46 0.21645039
0.21645039 2.18
Práctica 2
Hola a todos, hoy por fin hemos conseguido dejar practicamente terminada la práctica 2, en la que se nos pedía las siguientes cosas:
Mostrar información por el LCD
En este apartado no hemos tenido ninguna dificultad, ya que simplemente ha sido invocar a los métodos correspondientes para leer de los sensores.
Clap Control
A pesar de que el algoritmo para conseguir controlar la marcha o parada del robot mediante sonido es muy fácil, cometimos el error de realizar la lectura en dB en lugar de en dBA, por lo que el comportamiento del robot era bastante errático.
Bump & GO
Se puede observar la descripción en la entrada anterior ;)
Simple Avoid Objects
El objetivo es programar al robot para que se comporte como en el Bump & Go, así que empleamos el mismo algoritmo, solo que en lugar de reaccionar cuando se pulsa el sensor de contacto, se detiene cuando detecta un objeto cerca de el.
Sigue Pared
En este apartado se nos pide dotar al robot de la "inteligencia" necesaria para que al colocarlo cerca de una pared, éste la siga a unos 20 cm de distancia, sin importar los rincones o esquinas con los que se encuentre.
A pesar de que el algoritmo lo teniamos claro, tuvimos que valernos del antiguo de método de "ensayo y error" para ajustar los valores de giro, velocidad, distancias limite y los Thread.sleep().
No obstante estamos bastante satisfechos con el resultado obtenido, aquí teneis la prueba:
Mostrar información por el LCD
En este apartado no hemos tenido ninguna dificultad, ya que simplemente ha sido invocar a los métodos correspondientes para leer de los sensores.
Clap Control
A pesar de que el algoritmo para conseguir controlar la marcha o parada del robot mediante sonido es muy fácil, cometimos el error de realizar la lectura en dB en lugar de en dBA, por lo que el comportamiento del robot era bastante errático.
Bump & GO
Se puede observar la descripción en la entrada anterior ;)
Simple Avoid Objects
El objetivo es programar al robot para que se comporte como en el Bump & Go, así que empleamos el mismo algoritmo, solo que en lugar de reaccionar cuando se pulsa el sensor de contacto, se detiene cuando detecta un objeto cerca de el.
Sigue Pared
En este apartado se nos pide dotar al robot de la "inteligencia" necesaria para que al colocarlo cerca de una pared, éste la siga a unos 20 cm de distancia, sin importar los rincones o esquinas con los que se encuentre.
A pesar de que el algoritmo lo teniamos claro, tuvimos que valernos del antiguo de método de "ensayo y error" para ajustar los valores de giro, velocidad, distancias limite y los Thread.sleep().
No obstante estamos bastante satisfechos con el resultado obtenido, aquí teneis la prueba:
sábado, 20 de febrero de 2010
Bump & Go!
Como dijimos en la entrada anterior, nos ha costado dios y ayuda poder tener a punto el entorno en nuestros ordenadores y centramos toda nuestra atención en ello a lo largo de la última semana. En consecuencia no hemos llegado a la entrega de la practica 1.
No obstante, hemos trasteado con todo lo relativo al control de los motores, los métodos forward(), backward(), rotate(), rotateTo(), etc. Y ya estamos manos a la obra con los apartados de la práctica 2.
Como aperitivo del trabajo que estamos realizando aquí os dejamos una muestra de lo que hemos hecho hasta ahora:
No obstante, hemos trasteado con todo lo relativo al control de los motores, los métodos forward(), backward(), rotate(), rotateTo(), etc. Y ya estamos manos a la obra con los apartados de la práctica 2.
Como aperitivo del trabajo que estamos realizando aquí os dejamos una muestra de lo que hemos hecho hasta ahora:
Hemos conseguido nuestro primer objetivo con relativa facilidad. El pseudocódigo del comportamiento de nuestro robot es el siguiente:
loop {
avanzar();
if (sensorActivado) ->
parar;
retroceder();
girar();
end if;
end loop;
El robot como se observa en el video, a parte de un numero de grados de giro aleatorio, tambien tiene de forma aleatoria la dirección del giro. Con esto logramos que el robot no se quede bloqueado indefinidamente en escenarios como dar en una esquina (0:14 - 0:24 del video).
El siguiente paso en el desarrollo de esta práctica es realizar las mediciones correspondientes del sensor de ultrasonidos, para hacer un "Bump" & Go usando este sensor, así como el resto de apartados.
Os iremos informando en próximas actualizaciones! ;) Saludos
El siguiente paso en el desarrollo de esta práctica es realizar las mediciones correspondientes del sensor de ultrasonidos, para hacer un "Bump" & Go usando este sensor, así como el resto de apartados.
Os iremos informando en próximas actualizaciones! ;) Saludos
jueves, 18 de febrero de 2010
Compilar,enlazar,cargar
Hoy hemos conseguido tras 2 horas de practicas compilar enlazar y posteriormente meter el programa en el lego.
Hemos tenido bastantes problemas a la hora de configurar Eclipse ya que de vez en cuando daba errores al ejecutar tanto el compilador como el enlazador como el cargador.
Finalmente hemos introducido el HelloWorld y hemos comprobado que funcionaba.
Tambien nos ha costado entender como funcionan las variables y metodos.
¿Porque no empezaran en primero con Java?
Peleando con molinos.
Hemos tenido bastantes problemas a la hora de configurar Eclipse ya que de vez en cuando daba errores al ejecutar tanto el compilador como el enlazador como el cargador.
Finalmente hemos introducido el HelloWorld y hemos comprobado que funcionaba.
Tambien nos ha costado entender como funcionan las variables y metodos.
¿Porque no empezaran en primero con Java?
Peleando con molinos.
martes, 16 de febrero de 2010
Build Failed
Hemos tenido problemas al instalar el entorno,
primero debemos asegurarnos que tenemos el paquete java en el ordenador ya que sino no tenemos nada que hacer.
Luego al compilar la version de Lejos obteniamos el siguiente error:
Una vez solucionado informaremos a traves del blog
primero debemos asegurarnos que tenemos el paquete java en el ordenador ya que sino no tenemos nada que hacer.
Luego al compilar la version de Lejos obteniamos el siguiente error:
Una vez solucionado informaremos a traves del blog
Bienvenidos
Hola,Este es el blog de la asignatura de robotica.
En él iremos poniendo los problemas, mejoras, penas y alegrias de la asignatura.
En él iremos poniendo los problemas, mejoras, penas y alegrias de la asignatura.
Suscribirse a:
Entradas (Atom)
