jueves, 19 de abril de 2012

Práctica 4 (Presentación)

En la práctica 4 de la asignatura de robotica replanteamos totalmente la manera de moverse de Emilio. Pasamos del clasico 4x4 con 4 ruedas a un estilo más bipedo muy parecido a Segway ("Aparato de dos ruedas controlado por el equilibrio del usuario"). Para ello utilizamos la teoria del equilibrio dinámico que nos introducen en el enunciado. A grandes rasgos es una teoria que indica que cuando el elemento (Emilio), tiende a caerse hacia un lado, desplazar el centro de gravedad para que se estabilice. En otras palabras, cuando tienda a caerse a un lado, inclinarlo hacia el otro.
Este es el modelo de robot bípedo que hemos utilizado:







Como podemos ver se sustenta en únicamente dos ruedas, ademas del sensor de luz que se encarga de determinar cuando Emilio se balancea hacia un lado o hacia otro.

Practica 4 (Equilibrio)

Ahora que ya os hemos presentado a Emilio el equilibrista, vamos a explicar el código. En primera instancia calibramos a Emilio (Ya que las condiciones no son las mismas en todos los sitios que probamos). A posteriori, jugamos con los valores que recibe el sensor de luz. El mecanismo es simple. Si se acerca demasiado al suelo, es que se está inclinando demasiado hacia delante, por lo que hay que mover el eje de gravedad hacia atrás. Lo mismo pasa si se inclina hacia atrás, que hay que mover el eje de gravedad hacia delante para que se mantenga lo más estatico posible (Cosa que absolutamente es imposible). Para la solventación de este error usamos las formulas que nos introducen en los apuntes de teoria y en la misma practica:

Para esto empleamos:

- Proporcional

Esta parte consiste en el producto entre la señal que da error y la constante proporcional que hemos establecido. En función de la magntiud del error lo reparará proporcionalmente.
La constante debe ser adecuada sino el sistema oscilará demasiado.

P_{\mathrm{sal}}=K_p\,{e(t)}


error = medida Actual - medida Deseada

* Integral

La componente integral va a ser sensible a la acumulación del error. La integral del error irá creciendo a medida que un error se mantenga en el tiempo.
Si estamos estables en un estado no deseado demasiado tiempo esta componente integral actuará.

La salida es proporcional a la integral de la entrada.

I_{\mathrm{sal}}=K_{i}\int_{0}^{t}{e(\tau)}\,{d\tau}



- Derivativo

Como los controladores P tienen tendencia a sobrecorregir el empleo de una componente derivativa tendremos una reacción diferente en caso de que el error esté disminuyendo aumentando. Con esto se intenta evitar las oscilaciones fuertes.

La salida es proporcional a la derivada de la entrada.

D_{\mathrm{sal}}=K_d\frac{de}{dt}



* La salida final será la suma de las tres componentes:

\mathrm{u(t)}=\mathrm{MV(t)}=K_p{e(t)} + K_{i}\int_{0}^{t}{e(\tau)}\,{d\tau} + K_{d}\frac{de}{dt}

Con esta formula conseguimos estabilizar a Emilio. La formula es fácil plantearla, lo dificil son los valores constantes que tenemos que emplear para que se mantenga firme. Ha sido bastante costoso en cuanto a pruebas hallar los valores que hemos utilizado. Además, no siempre el equilibrio es dependiente de la fórmula, también hay factores que creemos que son determinantes para el equilibrio, como son el peso (No todos los diseños son iguales), o incluso la bateria, que nos daba mas fallo cuando no estaba totalmente completa (Aunque realmente nunca llega a estarlo.)


Dejémonos de formulas, y veamos si Emilio aguanta:

martes, 20 de marzo de 2012

Practica 3 (Sensores)

Para esta práctica emplearemos comportamientos, una manera nueva de funcionar para Emilio, ya que dependiendo de la información que reciba a través de los sensores deberá de hacer una acción u otra, es decir, elegir que comportamiento usa.

Para utilizarlos usaremos la clase Behavior, que será un array en el que estarán los distintos comportamientos.
Los comportamientos funcionan con tres métodos:

  • boolean takeControl(); Devolverá True si cumple la condición para que el comportamiento tome el control del robot.
  • void action(); Es el código del comportamiento
  • void supress(); Es lo último que hará el comportamiento cuando tenga que dejar el control del robot a otro.


En el primer apartado Emilio debe de chocar contra un obstáculo  y posteriormente esquivarlo.

Para la realización de toda la práctica hemos utilizado distintos comportamientos:

  • Avanzar: Toma el control siempre que acaban los otros comportamientos y únicamente va hacia delante y cuando termina se para.
  • Esquivar: Tomará el control cuando el sensor de contacto se active por chocar contra un obstáculo, el cuál esquivará por un lado haciendo una curva.
  • Sensor: Toma el control cuando el sensor de ultrasonidos detecta un obstáculo a menos de 30 cm. El motor del sensor empieza a actuar y toma medidas para no chocar contra el obstáculo. Para ello calcula un vector que será su trayectoria.                                                                                     Para calcular el vector tomaremos medidas haciendo un barrido gracias al motor en el que está puesto el sensor, cogeremos la distancia menor  y el ángulo que forma con esta. Pasaremos estas medidas a cartesianas.            Calcularemos las coordenadas de donde tendrá que ir el robot, y posteriormente las pasaremos a polares, obteniendo de esta manera la distancia y el ángulo que debe recorrer el robot.
  • OrientarLuz: Toma el control del robot cuando algún sensor de luz detecta un valor mayor al del ambiente. Dependiendo del sensor que lo detecte girará hacia un lado u otro.

Para el primer apartado hemos utilizado los comportamientos de Avanzar y Esquivar, en este vídeo se muestra el resultado:







En el segundo apartado Emilio deberá de utilizar los comportamientos de Avanzar y Sensor, con lo que tendrá que esquivar un obstáculo cuando lo detecte y calcular su dirección, aquí el video:





Para el tercer apartado usaremos los sensores de luz que hemos puesto a ambos lados de Emilio. Se encargará de seguir la luz. Hacemos uso de la clase RCXLightSensor. Los comportamientos que utilizará serán el de Avanzar y OrientarLuz.



Por ultimo, combinamos todas las armas que montamos al principio para que Emilio siga la luz evitando obstaculos.
En la primera parte utilizaremos Avanzar, OrientarLuz y Esquivar, con lo que será una mezcla del apartado 1 y 3.


En la segunda parte utilizará Avanzar, OrientarLuz y Sensor, conjuntando el apartado 2 y 3, como se muestra en el video.





Lo más dificil de esta práctica ha sido el apartado 2, ya que en un principio, debido a nuestra carencia de física, no sabiamos muy bien como obtener todos los datos que necesitabamos

lunes, 19 de marzo de 2012

Practica 3 (Presentación)




Bueno, la espera ha sido larga pero Emilio ha vuelto con ganas de acción. En esta practica abarcaremos de manera mas compleja el comportamiento de Emilio cuando se enfrenta con determinados obstáculos. En este caso no bordea una pared ni nada parecido, va directo hacia el obstaculo, obteniendo información de los sensores para actuar en cada caso. Aqui teneis a Emilio "Armado hasta los dientes" para poder sobrevivir en la jungla de las prácticas de robótica.



Ibamos a montarlo por partes, pero creíamos que quedaría mas agresivo si lo armábamos todo de golpe. (En realidad no, pero es el único diseño que aguantaba los golpes). En cuanto al sensor de contacto, ya lo hemos usado en apartados anteriores como "Bump and go" y demás, solo que ahora el comportamiento es distinto, bordear obstáculos. El sensor de luz no tiene mucha explicación, lo usaremos para que persiga un determinado foco de luz que le aplicaremos.


El sensor de ultrasonidos es algo "nuevo" para nosotros. Sigue un mecanismo similar al comportamiento de un murciélago, lanzar ondas y dependiendo del rebote de las mismas se calcula su distancia al objeto. Como podeis ver, hemos añadido un motor personal a este sensor, para que cuando se choque, haga un determinado barrido para "atajar" el obstáculo de la manera mas correcta posible.


Os iremos informando de cada apartado en próximos fascículos, un saludo!

jueves, 8 de marzo de 2012

Práctica 2 (Calibración del sensor de ultrasonidos)

En esta última parte de la práctica, la más pesada, tendremos que tomar medidas del sensor de ultrasonidos para ver su efectividad a la hora de ofrecernos los datos.
Para ello tendremos que ir moviendo el robot de alante para atrás respecto a una pared e ir anotando los datos que sean mostrados por la pantalla.

1.- ¿Cuál es la distancia real máxima y mínima que puede medir el sensor?

Distancia mínima: 5 cm
Distancia máxima: 254 cm

Seguramente pueda medir también hasta 255, pero como ahí esta el máximo del sensor no lo hemos puesto.

2.- ¿Cuál es el máximo ángulo con respecto a la pared para los que los valores son válidos?

A partir del angulo 50 y -50 empezó a darnos valores erróneos, con lo cual entre los valores [-50,50] los valores si que son buenos, salvo algunos cm de diferencia ya que no está en perpendicular, pero al llegar a 60 y -60 las distancias ya se salían de rango. Así que lo máximo estará entre los valores [-60,-50]-[50,60]

3.- ¿Tiene el sensor un error sistemático, es decir, la media de su error no es cero?


Distancia real Distancia medida Diferencia
20 21 1
30 31 1
40 42 2
50 50 0
60 61 1
70 72 2
80 81 1
90 91 1
100 101 1


Observamos las médidas obtenidas, se ve que el error es mínimo y también puede ser a una mala colocación nuestra del robot respecto a la distancia, con lo que podemos concluir que la eficacion del sensor es bastante buena.
Para hallar el error sistemático habría que sumar todas las diferencias y dividirlas entre el número de mediciones;  10/9 = 1'111 cm

4.- Cacula la incertidumbre del valor del sensor

Eje X:


Distancia real Distancia medida Media Error
40 40 40 39 40 40 39'8 0'2
40 39 40 40 40
50 50 50 50 49 50 49'8 0'2
49 50 50 50 50
60 59 60 60 60 60 59'8 0'2
60 60 59 60 60
70 70 70 70 70 70 69'9 0'1
70 69 70 70 70
80 80 80 80 79 80 79'9 0'1
80 80 80 80 80
90 90 90 90 90 90 90 0
90 90 90 90 90
100 100 100 100 100 100 100 0
100 100 100 100 100
110 110 110 110 110 110 110 0
110 110 110 110 110
120 120 120 120 120 120 120 0
120 120 120 120 120

Mirando la tabla se ve que en el eje x el error es practicamente inapreciable y que va desapareciendo respecto más se va alejando, con lo cuál el error depende de la distancia.






Eje Y:


Distancia real Distancia detección Media
40 8 8 9 9 10 9
9 9 9 10 9
50 10 10 9 11 11 11'7
11 13 10 11 11
60 12 12 13 14 14 12'8
12 13 13 13 12
70 13 13 14 14 14 14'3
15 15 16 14 15
80 15 15 15 14 16 14'8
14 14 15 15 15
90 14 14 15 15 14 14'4
14 15 15 14 14
100 14 14 13 13 14 13'6
14 14 13 14 13
110 14 13 14 14 13 13'4
13 14 13 13 13
120 14 13 12 13 13 12'7
12 13 12 12 13


Se puede apreciar, que como apunta la práctica, si que se forma un cono de apertura


Haya la matriz de covarianza del error P que representa la incertidumbre del sensor:

 | 0'071     1'037 |
 | 1'037     0'065 |

Práctica 2 (Sigue Pared)

En este apartado, como su propio nombre indica, Emilio tendrá que avanzar a la vez que sigue una pared, esquivando todo tipo de obstáculos, ya sean esquinas, papeleras, etc.



Esta parte ha sido la más trágica, ya que aquí fue donde el anterior Emilio se rompió y tuvimos que volver a montarlo un par de veces hasta que decidimos cambiarlo.
Tuvimos algún problema con el código pero por el mismo motivo que en las prácticas del Bump&Go, el robot no andaba recto, con lo cual intentamos cambiar muchas cosas para que nose alejase demasiado.

Aun así hemos tenido problemas con las medidas ya que las esquinas que le sigue una pared cercana no las hace del todo bien

miércoles, 7 de marzo de 2012

Práctica 2 (Bump & Go con sensor de ultrasonidos)

Este apartado es igual que el anterior, unicamente que está vez no se chocará, sino que cuando llegue a una distancia de 25 cm, hemos aumentado esta distancia por las medidas del robot, retrocederá y girará un número de grados aleatorio.



En esta parte tuvimos los problemas que en la anterior, ya que la haciamos igual unicamente que cambiando la parte del código que implicaba cada sensor.

Práctica 2 (Bump & Go sensores de contacto)

En esta parte de la práctica, cada vez que el robot choque contra un obstáculo deberá retroceder y girar un número aleatorio de grados.

Aquí el vídeo:




En esta parte hemos tenido un par de problemas:
El primero es que al usar la clase Math.Random no incluiamos la biblioteca de java en la que estaba, con lo cual los giros eran siempre los mismos.
El segundo fue que al utilizar la clse TachoPilot para que se moviese utilizabamos la clase entera para que se moviese, es decir, robot.forward(), y al ir hacia delante siempre se giraba. Lo solucionamos poniendo que cada motor avanzase por si mismo.

Cambio de imagen

Lamentandolo mucho...Emilio tendrá que cambiar su aspecto, ya que al probar las prácticas no era del todo estable, y habia veces que se desmontaba al chocar.

Ahora tiene una imagen mucho más normal para los de su especie, ya que hemos seguido el montaje que indica LEGO, este es su nuevo aspecto.




viernes, 2 de marzo de 2012

Práctica2 (Control del robot por sonido)

En este segundo apartado queremos que Emilio avance o se pare cada vez que escuche un sonido más alto de lo normal. Para eso hemos conectado el sensor de sonido.

Aquí el vídeo en el que obedece perfectamente.



Tuvimos algún problema al principio, ya que no calibrabamos el sonido con las ruedas, y una vez se ponia en marcha al dar otra palmada hacia amagos de parar y volver a andar, creemos que era porqué el sonido de las ruedas le hacia como estar en un búcle infinito de andar pararse

jueves, 1 de marzo de 2012

Practica 2 (Obteniendo Información)

Hola otra vez después de una semana que hemos intentando "desmalcriar" un poco a Emilio tras estar un par de días nada más que pendientes de él.

En está segunda práctica nos familiarizaremos con los sensores que podemos poner a Emilio para que sea un poco más eficiente.

Después de un día intenso de montaje y desmontaje, decidimos que la planta que tenia anteriormente Emilio no era suficiente para un robot de su importancia, asi que hemos intentado que ahora sea mucho más imponente.

Este es su nuevo estado:






















Le hemos incorporado el sensor de sonido, de luz, de contacto y de ultrasonidos.

Para este primer apartado solo conectaremos el de luz y el de ultrasonido.
Se trata de sacar por el ladrillo los siguientes datos de Emilio:
  • Nombre
  • Valor del sensor de ultrasonidos en mm
  • Valor del sensor de luz
  • La potencia de la bateria
  • La cantidad de memoria libre

Aquí una foto de los resultados:

jueves, 23 de febrero de 2012

Practica 1 (Mostrar trayectoria)



Bueno allá vamos con la ultima parte de la practica 1, la correspondiente a mostrar por el LCD de Emilio la trayectoria que sigue al hacer un cuadrado, siguiendo la formula que os muestro a continuacion:





En este caso la esquemática del programa es la siguiente, dos bucles while anidados. Un bucle while trata el movimiento del robot cuando se mueve hasta llegar a los 40 cms. Una vez llegados a los 40 cms, gira y entra en el otro bucle while, anotando también los grados que gira. Primero os mostraré la foto de lo que se ve en la pantalla) (Porque en el video no se distingue del todo bien):


Y el vídeo:



Hemos tenido dos problemas con esta práctica: El primero es que el robot (No sé porqué), cuenta hasta 80 en la recta del lado del robot, digo no se porqué porque en el código del programa hemos estipulado claramente que llegue solo hasta 40 cms. Y el segundo es que la primera sesión de pruebas el robot no paraba de andar y de andar...(Quería escapar). Se nos olvidó incrementar la "i" en el bucle..

Y hasta aquí la practica 1...La semana que viene empezaremos con la práctica 2, saludos.


miércoles, 22 de febrero de 2012

Practica 1 (Realización del cuadrado)




Después de un poco de descanso de tanto "Emilio", nos hemos vuelto a poner a la carga, esta vez con la parte de la realización del cuadrado. Para ello, en el código, hemos definido un bucle While (De 0 a 9) que se encargue de realizar las 10 representaciones de un cuadrado de 40 cm. de lado. Cada vez que realiza un cuadrado, tenemos un lapso de tiempo para recolocarlo en el punto 0,0, pero gracias a nuestras "manos de cirujano", la posición no siempre es exacta, por lo que varía unos milímetros y ese error lo arrastra todo el cuadrado. Aqui os muestro una foto del montaje del boligrafo (Posteriormente lo tuvimos que cambiar a lapiz porque Emilio no se lleva del todo bien con los Pilot).




Para la posterior realización de la covarianza, hemos realizado el cuadrado sobre un
eje de abscisas, para luego señalar donde se queda al terminar el cuadrado. Seguiría un esquema así:




El cuadrado rojo es la trayectoria ideal del cuadrado de 40 cms. Los puntos dispersos son donde termina Emilio la ejecución del cuadrado (Es orientativo). Vemos que no es exacto porque hay muchas condiciones que no se barajan en el código (Rozamiento, nuestras manos..), bueno aquí os dejo con el vídeo de un cuadrado (Vuelvo a sentirlo por la calidad)



Dos posdatas: La primera es que el vídeo es de las primeras veces que probamos el robot haciendo cuadrados, y como se puede ver, se tuerce demasiado al hacer el segundo lado. Es culpa de los folios y de su unión, ya que no me di cuenta y los superpuse mal. Y la otra es que no he conseguido voltear el vídeo (Por el momento).
Teniendo los datos de las finalizaciones de los cuadrados (Donde termina Emilio los cuadrados), sacamos las coordenadas de los mismos:



Y posteriormente, por medio de un programa para calcular la matriz de la covarianza, sacamos por pantalla la misma.


| -0.05 ,-0.35 |

| -0.35, 0.6 |

martes, 21 de febrero de 2012

Practica 1 (Odometria)

Después de una tarde un tanto tensa (Nuestro Emilio murió, y al mas puro estilo Frankestein y a nuestras manos, revivió. Bueno, el tiempo apremia y estamos avanzando tanto bien como rápido (Pienso yo...). Aquí os traigo la parte de la odometría del motor, donde por medio de la instrucción drawstring, imprimimos cuando se pasa de 360º, y cuando lo hace le restamos esos 360º para que sea real la medición. Lo mismo hacemos cuando es menos de 360º. Y por medio de la expresión "DrawInt" imprimimos por pantalla lo que queremos, en la posición que queremos, en este caso, los grados. Por ultimo usamos clear para limpiar la pantalla cada vez que movemos la pala, para que no quede "basura" en la pantalla. Esta es una foto del montaje:


Y aquí, un vídeo del movimiento de las palas:


PD: Hemos tenido dos problemas. El primero es que no nos imprime cuando se pasa de 360º o de 0º (No sabemos porque). El otro es que no hemos conseguido centrar del todo la impresión del numero (Demasiado centrado sale para los que hemos probado...jaja).

Práctica 1 (Motores)

Bueno ya que estamos "On fire" con Emilio, nos hemos dispuesto a darle caña y hemos conseguido hacer los 3 programas básicos para el movimiento del robot. En primera instancia hemos hecho BasicMotor1, en el cual cada vez que apretamos el botón, el motor mueve las palas (Sin limite). Hemos usado las instrucciones Button.waitforpress (Para hacer que se mueva al tocar el botón) y movimiento.forward (Para que se mueva(movimiento es la variable)).



Para la segunda parte del movimiento básico de motores, había que partir del código anterior pero moviendo las palas únicamente 45º, hemos empleado la instrucción "Rotate" para mover las palas, y le hemos indicado los 45 grados.


Y en ultima instancia, la evolución del código anterior, BasicMotor3, en el cual usamos "RotateTo", que explicado en "cristiano", seria como decirle al motor a que grados le queremos mandar.



PD: Veáse que en la pantalla intentamos escribir algo, pero al quedarsenos corta, se nos quedan a medias las frases (Intentaremos modificarlo en próximas prácticas).