Práctica 1 y 3 01/02/2009
Posteado por Edorka en : Robótica , hay 5 comentariosEsta vez me ha tocado diseñar y programar un robot con la dificultad añadida de que debe superar los objetivos de la práctica 1 y la práctica 3, bastante diferentes entre ellas.
Me propuse hacerlo con la misma configuración física que aparece en las fotos y que ha resultado bastante desastrosa ya que pesaba demasiado para cumplir con los objetivos de la práctica 3 (mantener equilibrio dinámico).
Práctica 1: Esquiva obstáculos
Para este el robot tan solo tenía que utilizar el sensor de ultra sonidos y reaccionar ante objetos que estuvieran a menos de 30cms, girando a la derecha y volviendo a avanzar
. También tenia en carril de los sensores montado de tal manera que el sensor delantero se activara en caso de impacto frontal, ante esto el robot debía retroceder, girar y proseguir con la marcha.
Al tener el sensor de ultrasonidos inclinado hacia arriba lo activarán obstáculos grandes (paredes, puertas, etc) sin embargo queda un hueco importante para que el robot “tope” con un objeto.
El carril donde están montados los sensores ha sido diseñado para que el sensor de presión al que esta conectado pueda ser activado tanto por impactos frontales como inferiores.
Aquí esta el código. Copiadlo al directorio samples de lejos y ejecutad ant.
Práctica 2: Segway
Para esta práctica y empleando un único sensor de luz debemos programar y diseñar el robot para que se mantenga en equilibrio el mayor tiempo posible.
Algunas consideraciones sobre el diseño:
- El robot dispone de dos sensores de presión (uno delante y otro detrás) para detectar que ha caido y en consecuencia detener el movimiento y evitar daños.
- Estos sensores se utilizan activamente en la fase de calibrado para asegurarse de que el usuario lo esta realizando en el orden correcto (dejarlo caer hacia atras, luego hacia delante y activarlo en equilibrio)
Para controlar la fuerza de los motores se utiliza un controlador PID, en la pagina de la wikipedia se pueden encontrar mas detalles, aquí tan solo se comentará lo relativo a la implementación del Segway.
En cada ciclo de control el controlador obtiene una lectura del sensor de luz, esta lectura será 0 si el robot se haya en el punto de equilibrio, los valores positivos y negativos indicarán si el robot se esta inclinando hacia delante (si es positivo) o hacia atrás (si es negativo)
En consecuencia el robot debe responder para recuperar la posicion de equilibrio con una acción correctiva, en el caso del segway consistirá en desplazarse proporcionalmente hacia el punto que le permita recuperar el equilibrio.
Para calcular la velocidad con la que deben responder los motores y su direccion participan 3 constantes que suelen ser diferentes de un robot a otro ya que la inercia del robot y la potencia real de los motores interviene en la respuesta.
- KP es la respuesta proporcional, normalmente si es muy elevada puede hacer que el robot “sobre-actue” y se caiga al lado contrario, en las pruebas que he hecho sin embargo nunca ha llegado a conseguir neutralizar una inclinacion media.
- KI es la constante de integracion y multiplica las diferencias con el punto de equilibrio que se han ido sumando (hasta llegar a una constante máxima)
- KD, la constante de derivacion multiplica la diferencia de los dos ultimos errores obtenidos.
No todas las constantes tienen porque ser positivas, dependerá de que papel jueguen en el refuerzo o compensación de la respuesta para conseguir que el robot reaccione con la fuerza necesaria pero sin provocar que caiga en el sentido contrario.
El código está disponible aquí
Fallos y puntos a mejorar:
Quien mucho abarca poco aprieta, el motivo principal del fallo catastrofico del robot a la hora de mantener el equilibrio ha sido intentar construir una configuracion que resolviera simultaneamente las 2 prácticas pendientes para entregar el mismo día. El problema de esta configuración hibrida radicaba en el peso, que hacia imposible a los motores moverse con el suficiente impulso como para volver a ganar el centro de equilibrio.
por otra parte el entorno del laboratorio devolvía lecturas bastante cerradas con lo que el robot no aceptaba la lectura que le daba como punto medio (al no ser menor que la lectura máxima y mayor que la mínima)
Práctica 2: Conclusiones 17/12/2008
Posteado por Edorka en : Robótica , poner un comentarioTenacitas ya se ha enfrentado con un relativo éxito a su propósito en la vida.
He llegado a las siguientes conclusiones:
Las pinzas son un buen sistema para capturar objetos de ciertas formas, sin embargo con el diseño actual de las pinzas se daba la posibilidad de que objetos que tuvieran demasiado rozamiento no se “deslizaran” hasta tocar el sensor.- La mejor manera de detectar si las pinzas se han cerrado consiste en vigilar el angulo actual del motor que las mueve y así evitar que se siga moviendo cuando el mecanismo está bloqueado (esto es muy importante para evitar el deterioro de las piezas. Si a alguien le interesa como esta realizado el mecanismo de las pinzas dedicaré un post entero al tema. De momento dejo un vídeo mostrando el sistema de captura en acción.tenacitas-capturando
- Los sensores de lego suelen ser bastante poco precisos y susceptibles del ruido, esto es muy común y precisamente por ello debí pre-veer algún mecanismo para realizar filtros est
adísticos sobre los sensores de ultrasonidos y sobre todo del sensor de luz. - Aconteció un epic FAIL en un par de ocasiones cuando el robot alcanzaba la cinta aislante que marca el fin del mapa, en este caso el robot gira 100 grados a su izquierda y prosigue. Desgraciadamente esta política no es efectiva el 100% de las veces, ya que Tenacitas tiene el sensor de luz 6’5cms adelantado respecto del eje de movimiento, con lo que existe la posibilidad de que el sensor quede por delante del limite y que con ello el robot prosiga más allá de los límites del tablero. La solución a este problema consiste en retroceder unos centímetros antes de iniciar el giro.
- Debido a la persistente cojera de Tenacitas la odometría no era suficiente para establecer la posición del robot, este siempre se desplaza unos 5 grados a la derecha en cada desplazamiento, con lo que la incertidumbre crece tanto que se hace imposible hacer estimaciones sobre la posición del robot en el mapa, aunque sería interesante ver hasta que punto se pueden ir contabilizando estas taras permanentes y que el robot cuente con ellas para establecer su posición.
- Estoy especialmente satisfecho con el sistema para la localización de latas, este consiste en qu e el robot avanza 30cms (la distancia máxima en que el sensor de ultrasonidos es preciso) y rota 45grados a un lado, 90 al contrario y vuelve a mirar al rumbo original, interrumpiéndose el proceso si aparece un objeto susceptible de ser una lata. De este modo se maximiza el aprovechamiento del sensor y nos aseguraremos de que no sea necesario pasar dos veces por la misma zona.
- Si el sistema ha localizado una lata y esta desaparece del sensor, la buscara repitiendo un escaneo de 110grados (todas estas constantes son configurables), si al finalizarlo no ha conseguido encontrar la lata, la dará por perdida y proseguirá con la búsqueda de otra lata.
Práctica 2: Recoge latas 14/12/2008
Posteado por Edorka en : Robótica , poner un comentarioBuenas a todos,
Mis más cercanos habrán notado cierta obsesión estos últimos días con cierto artilugio que me ha sido encomendado para convertirlo en un estupendo caza latas.
Está pensado para moverse a través de un tablero que tiene una serie de limites marcados con cinta negra, detectar y capturar las latas para depositarlas en un recuadro de colores en el centro del tablero.
Lo mejor de todo, tiene que estar terminado y probado para el martes, ya contaré que tal.
