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)
