4copter: IMU de 10dof - Presentacion

Introducción:

Los sistemas autónomos últimamente están teniendo una gran acogida, debido, en parte, al abaratamiento de los materiales y a la evolución de la tecnología que permite realizar sistemas cada vez más pequeños.

Vehículos aéreos, terrestres, acuáticos, submarinos e incluso espaciales se están utilizando cada vez más en multitud de campos, desde operaciones militares y de rescate a investigaciones científicas, desde tareas de inspección y mantenimiento a espectáculos o actividades de recreo.

Un sistema automático de control de dispositivos robóticos autónomos (drones) se pueden dividir en varios componentes (vinculados generalmente a una tripulación típica):

• Piloto: Este componente se encarga de controlar la posición y orientación del drone y realizar los ajustes pertinentes en los actuadores (generalmente motores o servos), para corregir el rumbo, la posición y/o la orientación.
• Navegante: Este componente se encarga de dictaminar y decidir el rumbo a seguir, a partir de los datos recogidos por el sistema
• Maquinista: Este componente se encarga de hacer funcionar los actuadores (en un sistema robótico este cometido está realizado por los controladores de los motores).
• Tele-operador: Este componente se encarga de recibir las ordenes enviadas desde tierra y transmitir la posición y rumbo.

Aunque parecen sistemas muy complejos y especializados, todos estos vehículos tienen muchos elementos en común: un sistema de posicionamiento y navegación, un sistema sensorial y varios actuadores (generalmente motores o servos).

Objetivos:

La finalidad del proyecto 4copter es realizar un piloto para sistema automático de control de dispositivos robóticos autónomos, que se encargará de estabilizar el sistema. Los objetivos específicos del proyecto serán lo siguientes:

• Arquitectura y protocolo de telemetría. Se creará un protocolo de comunicaciones independiente de la capa física y el modelo de plataforma utilizado. Por otro lado también se implementará un sistema de radio para la comunicación entre el equipo y la estación base.
• Unidad inercial (IMU) de 10 ejes: Se implementará una unidad inercial de 10 ejes (acelerómetro, giroscopio, magnetómetro y barómetro-altímetro), de esta forma se podrán realizar algoritmos de fusión de sensores que aumenten la fiabilidad del sistema.
• Hardware Abierto (Open Hardware): Diseñar una plataforma de hardware abierto para que la comunidad científica pueda utilizarla como base de sus proyectos.
• Hardware reutilizable e independiente de la plataforma: Aunque se ha elegido un cuadróptero como plataforma, se diseñará un hardware independiente de la plataforma, de tal manera que pueda ser reutilizable para cualquier tipo de modelo, sea este aéreo, terrestre, acuático, submarino o espacial.

Aplicaciones:

Las aplicaciones de este tipo de equipos son prácticamente son infinitas. Actualmente se utilizan equipos tele-controlados para inspección de tuberías y alcantarillado, limpieza de conductos, inspección de cascos de barcos, etc. Todos estas tareas son mayormente repetitivas y pueden ser automatizadas mediante un sistema que marque los puntos de interés.

Por otro lado los sistemas automáticos pueden utilizarse para realizar medidas de datos climáticos, de contaminación, de localización (para sistemas de información geográfica), fotografías geoposicionadas, estudios agro-forestales, de fondo marino, estudios de sedimentación en embalses, búsqueda y rescate de personas durante catástrofes, reconocimientos en lugares peligrosos para el ser humano, y otra multitud de aplicaciones que únicamente dependen de la imaginación.

CAMPIC (I): Control de una cámara desde un micro

La visión artificial es un reto que la robótica tiene desde hace mucho tiempo. Por ahora se necesitan equipos especializados o PCs para procesar las imágenes que se reciben de las cámaras.

Para micros con pocas prestaciones es un campo difícil, sin embargo no imposible.

Unos compañeros estamos utilizado una cámara con salida serie-TTL (3V3) para recibir imágenes y esta es la primera prueba que hemos sacado (por ahora en PC).

La imagen es pequeña y de poca resolución pero se ven perfectamente a los dos que estábamos saludando a la cámara, e incluso se aprecia el logo de CC en mi camiseta.

A partir de ahora toca el procesado.

S2

Ranganok Schahzaman

3m/s (IV): Resolución en el eje Y

Retorno con el velocista después de mucho tiempo...

Como vimos en la primera entrada de la serie el tiempo que tarda en tomar (y procesar) dos medidas de los sensores es muy importante, ya que determinará la resolución máxima que podemos tener a una velocidad determinada. Existe un límite que nos pone una cota máxima al tiempo que podemos tardar entre dos medidas: el teorema de Nyquist (en la wikipedia inglesa está algo más explicado), resumiéndolo un poco nos dice que para poder reconstruir el camino sin errores debemos tomar los datos a una velocidad mayor que el doble de la velocidad a la que cambia la curva.

Vamos a intentar explicar esto (teorema de Nyquist aplicado a un velocista):

Supongamos que no somos un observador externo sino que vamos montados en el propio velocista mirando al suelo. Sin ninguna referencia más podríamos pensar que estamos quietos y lo que se desplaza es el suelo, esto es, una línea negra en un fondo blanco; imaginemos, además, que sólo vemos esa línea a través de una redija muy pequeña sin que podamos ver más allá para prevenir una curva, esto es nuestra señal de entrada.

Si tuvieramos eso sería un sistema analógico normal y corriente; pero nuestro sistema (al ser microprocesado y no construido con filtros analógicos) tiene una particularidad: es discreto en el tiempo, es decir, no estamos viendo la línea continuamente sino que sólo podemos tomar fotografías en instantes concretos de tiempo, o lo que es lo mismo, es como si estuvieramos viendo la línea únicamente iluminada a través de una luz estroboscópica (flashes que saltan cada cierto tiempo).

Si el tiempo entre fotografías (o flashes) es demasiado alto seguramente no podríamos seguir la línea, no podríamos corregir la dirección y acabaríamos estrellando el velocista.

Es difícil determinar el tiempo mínimo que cumple el teorema, sin embargo, es más visual ver la resolución en metros (centímetros o milímetros), es decir la distancia que recorrerá el robot entre dos medidas a la velocidad a la que vayamos. Para tener una referencia contaremos que el eje de giro será t=0, lo que recorra el robot será el eje positivo y lo que ya halla recorrido el eje negativo.

Evidentemente si bajamos la velocidad del velocista la distancia que recorremos entre flashes será menor y si la subimos mayor. Si optimizamos el tiempo de proceso o cogemos un micro más rápido (los flases más seguidos) la distancia recorrida disminuirá y si escogemos un micro más lento la distancia augmentará.

Sin embargo, lo bueno de todo es que, siempre que cumplamos el tiempo mínimo que dice el teorema, dará igual a qué velocidad vayamos que siempre podremos procesar correctamente la señal.


S2

Ranganok Schahzaman

Near Space Development Probe

O NSd es el nombre del proyecto en el que estoy trabajando desde hace un tiempo y que posiblemente sirva de base para mi proyecto de final de carrera.

Podéis colaborar con él (proyecto de hardware y software libre) en su propio blog: http://blogs.webdearde.com/nsdprobe/

S2

Ranganok Schahzaman

HexaBot

El HexaBot es el proyecto de un compañero de trabajo en el que he ido ayudando (principalmente aportando ideas y solucionando dudas), falta bastante por hacer (le faltan los motores y ruedas que le hagan desplazarse, pero vale la pena hecharle un vistazo:



S2

Ranganok Schahzaman

III Jornadas Robóticas de ARDE

Desde la Asociación de Robótica y Domótica de España (A.R.D.E.) estamos organizando las "III Jornadas Robóticas", los días 21 y 22 de Marzo en el Centro asociado de la UNED en Las Rozas, MAdrid.

Estas jornadas pretenden ser un acercamiento de la robótica y la domótica a todo el mundo por lo que esperamos la asistencia de todos vosotros.

Toda la información la podéis ver en: http://www.webdearde.com/asambleas

¡Os esperamos!

Asociación de Robótica y Domótica de España (A.R.D.E.)

III Concurso Universitario de Software Libre

Ya ha empezado el Concurso Universitario de Software Libre que este año celebra su tercera edición, además viene cargado con un montón de proyectos para electrónica, domótica y robótica. Los proyectos que más me han llamado la atención son:

• A.R.A.D. (Articulacion Robotica Para Aplicaciones diversas): Implementación del diseño, control y cinemática de un manipulador con 5 grados de libertad


• ArCan: Crear una interfaz para Arduino que le permita comunicarse mediante CanBus.


• Biblioteca de conexión de Arduinos con el protocolo X10: Se desarrollará una biblioteca para Arduinos capaz de comunicarse con un ordenador, vía protocolo de comunicaciones X10, y tanto enviar como recibir información en dicho protocolo.La bibllioteca se integrará en el paquete de control domótico MisterHouse.


• dotRobot: Implementación .net microframework bajo gpl v3 reutilizando dotgnu


• DVS Car: Sistema de seguridad para vehículos mediante sensores, que se comunican con nuestro servidor proporcionando a nuestro cliente servicios como estado de su vehículo, localización del mismo, aviso a la policía y aviso por a través de mensajería instantánea.


• Endouélico: Proyecto de visión artificial para reconocimiento de objetos.


• GesControl Security: GesControl Security es un sistema destinado al control reomoto y vigilancia de áreas geográficas limitadas como oficinas, comercios, garajes, casas, etc..., las cuales están provistas de dispositivos que informan del estado de dicha área.


• habla conmigo: Aplicación que interpreta el lenguaje castellano ( escrito o hablado) y lo traduce al lenguaje de signos mediante un muñeco animado.


• IdeLdeS (Interprete de Lengua de Signos): El programa consistirá en un interprete de lengua de signos capturando las imágenes con una cámara web.


• LabGNU: Alternativa libre a LabView. Para el que no conozca LabView, se trata de un software de instrumentación virtual, con el que poder crear instrumentos de medida para la aplicación exacta que necesitemos.


• Libgann: Biblioteca de Redes Neuronales Artificiales en C++.


• Locator: Localizador GPS basado en hardware & software libre que utiliza un servidor remoto para calcular rutas de proximidad y localización.


• Micro-Comet: Estudio, diseño y construcción de una videoconsola basada en microcontroladores e implementación de juegos para esta plataforma.


• mMHS: PERSONAL HEALTHCARE UMPC TECHNOLOGY AND SERVICES FOR ELDERLY: El proyecto consiste en un sistema de monitorización de telemedicina. Esta compuesto por un dispositivo móvil (UMPC con Maemo) el cual se conecta a una serie de sensores médicos no-invasivos a través de Bluetooth (BAN).


• RoViM (Robotics Virtual Machine): Prototipo de máquina virtual genérica y extensible para robots móviles.: Máquina virtual que permite ejecutar software portable para robots móviles de tal modo que no sea necesario reescribir el código de un programa cuando haya que ejecutarlo en una plataforma robótica distinta.


• Thoromotica: La fusión la robótica, con el proyecto ThoRo mas la domótica, nos amplia los horizontes en la fusión del mundo real con la tecnología modular e inalámbrica más avanzada.

Como he dicho este año hay una gran cantidad de proyectos interesantes, espero que todos lleguen a buen puerto.

S2

Ranganok Schahzaman

Actualización 11/12/2008: he añadido un par de links y el Planet del concurso

La sonda Phoenix (II)

Volvemos con la segunda parte de la disección de la sonda Phoenix realizada por el blog El Tamiz. Aquí se nos muestra todos los aparatos científicos que lleva la nave a bordo.

Con respecto a esto últimamente hemos visto noticias en la blogosfera sobre problemas en uno de ellos, el TEGA (Thermal and Evolved-Gas Analyzer) que se encarga de calentar material y analizar la composición de los gases que se desprenden, debido a que la tierra estaba demasiado compacta para poder pasar por la malla que cubre la entrada. La solución propuesta por la NASA ha sido la de tamizar la tierra y, como eso no bastaba, tirar la tierra desde lo alto para que al caer se esparza.

Al final parece ser que un movimiento del suelo (a parte de todo lo demás) ha desecho los grumos y se ha llenado uno de los hornos.

S2

Ranganok Schahzaman

Usando la electricidad estática

Generalmente la electricidad estática es un coñazo: quema circuitos integrados, hace que no podamos despegarnos de un plástico, y hace que nos rampemos cuando tocamos otra gente, sin embargo leo vía Gizmodo que han creado un robot capaz de usar la electricidad estática que genera en su beneficio, en concreto es capaz de subir por las paredes.

El robot en cuestión ha sido diseñado por SRI en cuya página dan una explicación algo más detallada.

S2

Ranganok Schahzaman

La sonda Phoenix

El Tamiz ha publicado una disección, como siempre impresionante, sobre la sonda Phoenix que está dividida en dos partes. La primera parte ya esta disponible y es muy recomendable leerla para saber cómo ha sido posible que llegue ese laboratorio a Marte (impresionante el vídeo del final). En la segunda parte se hablará del laboratorio en sí mismo.

S2

Ranganok Schahzaman

3m/s (III): Configuraciones mecánicas

De las muchas formas de moverse que tiene un robot, ¿cuál es la mejor para un velocista? Yo me quedo con tres configuraciones (todas con ruedas), que intentaremos analizar: diferencial, triciclo ("sniffer") y Ackerman (tipo coche).

Diferencial

Consta de dos ruedas paralelas entre sí con tracción independiente. En teoría esta es la mecánica
más fácil de construir, únicamente se necesitan ruedas de tracción, ya que la direccionalidad se consigue con la diferencia de velocidades (y sentidos) de estas ruedas. Para darle estabilidad al conjunto se suelen usar una o varias ruedas locas que aguantarán el peso del robot impidiendo que este se incline, sin embargo esto puede dar problemas de pérdida de tracción de las ruedas en pistas irregulares.


Pulsa en las imágenes para verlas más grandes

Ventajas:

• El robot puede girar sobre su propio eje (el punto medio entre las ruedas de tracción) lo que le da una mejor respuesta ante curvas cerradas.

Inconvenientes:

• Las ruedas de tracción no pueden ir a máxima velocidad siempre, en las curvas una de ellas (la interior a la curva) deberá frenar o incluso invertir su sentido para poder girar el robot.


• Para asegurarse el movimiento rectilíneo debemos comprobar que las dos ruedas vallan siempre a la misma velocidad.


• Existen problemas de estabilidad lo que dará pie a poner una tercera rueda (loca), sin embargo esto puede seguir dando problemas (depende de la posición del centro de gravedad). Si se pone una cuarta rueda (loca) ganará estabilidad pero pueden perder contacto la ruedas de tracción (dependiendo de las irregularidades de la pista).

Triciclo

En este caso tenemos 3 ruedas formando un triángulo, una de dirección delantera y dos traseras paralelas entre ellas. Generalmente las ruedas traseras se utilizan como tracción pero la rueda de dirección puede servir también.

El principal problema del triciclo son los giros que depende de la distancia entre las ruedas traseras y la delantera (que marca la dirección del giro). Además se debe tener en cuenta que en un giro las ruedas traseras deberán ir a distinta velocidad para compensar el trayecto a recorrer por cada una de ellas.


Pulsa en las imágenes para verlas más grandes

Ventajas:

• Las ruedas de tracción pueden ir a máxima velocidad, siempre que el radio de giro de la pista sea lo suficientemente grande.


• Tiene facilidad para ir recto.

Inconvenientes:

• El radio de giro del robot no es muy grande, por lo que se ha de reducir la velocidad antes de entrar en una curva.

Configuración Ackerman

Todos hemos visto alguna vez un coche, así que no tiene mucha explicación de la forma: cuatro ruedas, dos de ellas de dirección... Lo que sí podemos haces es diferenciar dónde ponemos la ruedas de dirección y dónde las de tracción.

En un coche la ruedas de dirección generalmente son las delanteras (aunque existen algunos modelos con ruedas ser traseras) esto se hace así porque son las ruedas que están más cerca del conductor. Sin embargo en un velocista no tiene porqué ser así.

Las ruedas de tracción también suelen ser las delanteras, sin embargo en los modelos de RC las ruedas de tracción son distintas a las de dirección, entre otras cosas, para simplificar el diseño.

La ventaja de la tracción delantera (hacer coincidir la tracción con la dirección) es que se aprovecha mucho mejor la energía en curva porque la fuerza se transmite en la dirección de ésta por lo que serán más fáciles de controlar. Sin embargo los automóviles de alto rendimiento son más difíciles de manejar y tienden al subviraje si son de tracción delantera.


Pulsa en las imágenes para verlas más grandes

Ventajas:

• Las ruedas de tracción pueden ir a máxima velocidad, siempre que el radio de giro de la pista sea lo suficientemente grande.


• Buena estabilidad.


• Facilidad en las rectas.

Inconvenientes:

• El radio de giro del coche no es muy pequeño, por lo que se ha de reducir la velocidad antes de entrar en una curva.

Eje de gravedad

Algo muy importante a tener en cuenta es que deberemos repartir el peso de tal forma el centro de masas del robot quede lo más cercano al suelo (lo cual le dará mayor estabilidad) y que el eje de gravedad coincida con el eje de giro (lo cual facilitará que el giro del robot se haga de forma correcta y sin desviaciones), a parte de esto deberemos pensar en el momento de inercia de giro del robot que nos interesa que sea el mínimo posible (para poder corregir rápidamente la trayectoria).

Teniendo en cuenta esto diseñaremos el velocista de tal forma que las baterías y los motores, que son los elementos que más pesan, queden:

1. Lo más cerca del suelo posible


2. Simétricos respecto al eje de giro


3. Lo más cerca del eje de giro posible

Como hemos ido viendo en los dibujos el eje de giro depende de muchos factores. Los más importantes son: la configuración mecánica (diferencial, triciclo, Ackerman, ...), el radio de giro, y la distancia entre ruedas.

Dado que la posición de eje de giro es variable en la mayoría de los casos, tendremos que utilizar otros factores para posicionar el centro de gravedad:

• Siempre deberemos distribuir el peso de tal forma que el eje de gravedad caiga dentro del polígono que se forme al unir los puntos de apoyo de las ruedas, en otro caso volcaremos el robot.


• Si sabemos que el giro siempre va a ser hacia el mismo lado (y sabemos ese lado) podemos acumular la mayor parte del peso en la parte interior del giro para ayudar a girar al robot (mínima distancia con el eje de giro), es decir, si debe girar siempre a la derecha poner la mayor parte del peso en el lado derecho, de esta forma estaremos "ayudando" a realizar el giro.


• Si no sabemos cómo va a ser el giro, o este no va a ser siempre hacia el mismo lado (lo más normal), tendremos que mirar la configuración para decidir como repartir el peso:
  
  • En una configuración de triciclo situaremos el peso alrededor del eje entre la rueda de dirección y el punto medio entre las ruedas de tracción.
  
  
  • En una configuración diferencial el punto medio entre las dos ruedas coincidirá con el eje de giro cuando las ruedas giren a la misma velocidad en sentidos opuestos, por lo que repartiremos el peso en función de este punto.
  
  
  • En una configuración Ackermanlo mejor es repartir simétricamente el peso respecto a las ruedas de dirección y tracción.

S2

Ranganok Schahzaman

PD: Algunos links que pueden ser de utilidad

• http://ccc.inaoep.mx/~esucar/Clases-irob/ir2-locomocion.pdf


• http://turan.uc3m.es/uc3m/dpto/IN/dpin11/PRACTSM1Y2.pdf


• http://www.muchotrasto.com/TiposDePlataformas.php


• http://www.clubse.com.ar/news/news11/notas/nota10.htm

Busco colaboradores

Este post lo puse hace unos días en la web de ARDE

Hola,

Llevo tiempo dándole vueltas a un par de proyectos, pero por falta de tiempo no los termino de arrancar, así que me he decidido a poner este anuncio...

Busco:
- persona que le guste el diseño electrónico,
- que sepa o le interese aprender KiCAD,
- preferiblemente que sepa de mecánica,
- preferiblemente estudiante (por aquello que utilice lo que hace para presentar algún trabajo o PFC).

Funciones:
- Diseño de planos esquemáticos y PCB.
- Todos los planos y PCB se liberarán bajo la licencia CC-by-sa. Lo cual da publicidad a los que lo hacen.

Proyecto:
Creación de un taller/laboratorio para robotica y domotica.
- Entrenador modular
- Punta lógica
- Multímetro: Voltímetro, Amperímetro, Ohmmetro, Capacímetro...
- Osciloscopio.
- Generador de Funciones.
- Frecuencímetro.
- Fuente de alimentación.
- Medidor de protocolos.

Ofrezco:
- Compartir conocimientos.
- Tutorizarla en los trabajos que tenga que realizar (por eso lo de ser estudiante).

Se que no ofrezco mucho, pero es que no puedo ofrecer más...

Aclaro que no es una oferta de trabajo, simplemente se trata de sacar adelante los proyectos que tengo parados por falta de tiempo (luego serán publicados con licencia CC, así que yo tampoco gano nada). Si hay algún interesado...

S2

Ranganok Schahzaman.

3m/s (II): Analógico vs Digital

En un velocista hay que seguir un camino marcado entre dos líneas negras "pintadas" sobre un fondo blanco... Muchas veces para ahorrar tiempo y proceso lo que se hace es coger una de las dos líneas (generalmente la interior) y seguirla. Para hacernos una idea:



La forma de "ver" esa línea es casi siempre igual sensores de infrarrojos que distinguen entre el fondo blanco y la línea negra: los omnipresentes CNY70 (aunque se pueden usar otros).

La mayoría de los sensores de infrarrojos que nos encontremos para este menester dan una salida analógica en función de la cantidad de luz que reciben, ahora bien, cómo debemos procesar esta información.

• Por un lado tenemos la opción digital, es decir se escoge un umbral y todo lo que sobrepase de ese umbral es un '1' y lo que no un '0' (en realidad se escogen dos umbrales y se realiza un trigger Schmitt)


• Por otro lado la opción totalmente analógica en la que no usamos micro y las decisiones que afectan al movimiento se realizan por añadir y substraer señales unas de otras. Dado la complicación que esto supondría (sobretodo a la hora de cambiar "el programa") esta opción queda totalmente descartada.


• Algo más intermedio sería utilizar un conversor analógico-digital para tener las señales digitales pero no como 1s y 0s sino como bytes.

Las ventajas e inconvenientes son claros, la "digitalización" de las señales aumenta la velocidad de proceso a costa de perder información de la señal... así que la pregunta es: ¿cuánta información necesitamos? o mejor dicho ¿de cuánta información podemos prescindir?

S2

Ranganok Schahzaman

Controlando el caos II

Al fin compré un cepillo con las cedras inclinadas, y he empezado a realizar algunas pruebas.
El montaje es simple (ya lo vimos en la primera parte). Necesitaremos: un cepillo de dientes con cedras inclinadas, un motor de vibrador de móvil, una pila de botón y un poco de plastilina o BlueTak (ni idea de como se escribe, es esa pasta parecida a la plastilina, que sirve para pegar pósters, fotos, etc. en la pared).



Algunas cosas que me he encontrado:

• Utilizad un cepillo de cedras duras y gruesas. Los cepillos de dientes tienen diferentes grosores de cedras y distintas durezas, si escogéis el de cedras duras y gruesas soportará mejor el peso.


• El sentido de giro del motor influye en el sentido de giro del conjunto. Dado que la idea es poner dos motores vibradores pues nos puede venir bien esta premisa para realizar giros.


• El sistema tiene equilibrio inestable. Es decir hace falta tener muy en cuenta la repartición del peso (si tu cepillo cae siempre hacia un mismo lado necesitarás un contrapeso en el lado contrario), unos topes para que no caiga también vienen bien. Sería bueno bajar el centro de gravedad del conjunto (ya veremos cómo).
  


• Funciona con un cepillo de cedras rectas (la primera prueba la hice con un disipador de calor), pero las cedras inclinadas dirigen el movimiento en la dirección de las mismas.

Otro vídeo del VibroBot esta vez sin el mango del cepillo de dientes:


S2

Ranganok Schahzaman

3m/s

Los velocistas son la categoría de los concursos de robótica que menos me atrae, no es que le tenga especial manía, sin embargo pienso que hay categorías más interesantes...

Sin embargo en la Agrupación de Barcelona, se ha votado que haremos un concurso interno de velocistas, así que hay que ponerse las pilas:

Objetivo... ¡llegar a los 3m/s!

¿Por qué 3m/s? Pues fácil, en la última competición que he visto de velocistas se alcanzaron velocidades de más de 2m/s, así que si quiero ganar necesitaré mejorar bastante esa marca (si puedo superarla mejor que mejor).

Para empezar unos pocos cálculos:

• 3m/s son 10.8 km/h


• Una persona "normal" andando hace una media de entre 5 y 6 km/h


• Para tener una decisión por cm necesitaremos realizar 300 decisiones cada segundo lo cual para un procesador de 10MIPS (un PIC18) sólo nos deja ejecutar 33333 instrucciones por decisión, evidentemente podemos usar un procesador más pontente o realizar decisiones más espaciadas, pero es una buena aproximación


• Con ruedas de diámetro 7.6cm necesitaremos que esta gire a aproximadamente 754 rpm, y el motor tenga la suficiente fuerza para llevar a todo el equipo (motores, sensores, ruedas, baterías y control)

Como podéis ver no es trivial conseguirlo.

S2

Ranganok Schahzaman

Edito: corregido el error en el número de instrucciones por decisión (ver comentarios)

Controlando el caos

Me encantan los BristleBot: son pequeños, manejables y si los dejas un rato te limpian la mesa...

Una explicación de como construirlos:



Y mi resultado (grabado con la cámara del móvil):



Como vemos tienen un pequeño problemilla: el movimiento es bastante caótico. En el primer vídeo el movimiento se dirige por la propia mecánica del robot: los pelos del cepillo al estar inclinados dirigen el robot hacia una dirección y sentido. En mi caso, el movimiento caótico está dado (creo) porque el motor estaba a un lado de la estructura y desequilibraba el peso.

La idea es montarlo todo en un cepillo y añadir otro motor para controlar el movimiento caótico mediante un acelerómetro u otro dispositivo que pueda medir giros... ¿Fácil no? (ironía).

Antes de nada algo de teoría:

Un giro siempre implica una fuerza que hace cambiar la dirección de la velocidad tangencial. A esta fuerza se le llama Fuerza Cetrípeta (Cp), si no existiese esta fuerza el giro no se produciría. No confundir con la Fuerza Centrífuga que es una fuerza imaginaria que se usa para explicar los fenómenos de inercia en un giro.



Por la Segunda Ley de Newton sabemos que una fuerza implica una aceleración en la misma dirección y sentido que se produce esa fuerza, y eso es lo que queremos medir con el acelerómetro.

Con unos pequeños cálculos vamos a ver la precisión necesaria para medir estos giros. Si contamos en el ejemplo de mi VibraBot vemos que el radio de giro es un par de centímetros la masa es 10g




Para la velocidad angular de giro podríamos decir que es una vuelta cada segundo (simplificando), por lo que la aceleración medida será:

a = 2·Pi·0.02 = 0.13 m/s² = 0.013G

Es decir si escogemos un acelerómetro de gran sensibilidad (1200mV/G) tendremos unos 15mV de resolución en el giro. Con un ADC de 10bits tenemos una resolución aproximada de 5mV con lo cual se nos queda un poco justo pero es posible. Además siempre le podemos poner un amplificador de señal.

Bueno, ya hemos visto que es viable, ahora sólo hace falta comprar el material y montarlo...

S2

Ranganok Schahzaman

II Jornadas Robóticas de A.R.D.E. (II)

El pasado fin de semana fueron las II Jornadas Robóticas de A.R.D.E.. Los que halláis organizado algún tipo de evento ya sabéis lo que supone esto: nervios, carreras, estar disponible para todo el mundo, miradas asesinas cuando alguien saca un soldador en una sala de conferencias (*), etc.

En un par de días pasaré la grabación de las conferencias en vídeo y las subiremos a Internet (pido un poco de paciencia en este sentido). Las fotos ya mismo se colgarán y las transparencias en cuanto las tengamos también.

Saludos

Ranganok Schahzaman

(*) Hay que decir en favor de la persona que sacó el soldador que solo lo hizo para buscar otra cosa en la mochila.

II Jornadas Robóticas de ARDE

Desde la Asociación de Robótica y Domótica de España (A.R.D.E.) estamos organizando las "II Jornadas Robóticas", los días 8 y 9 de Marzo en el Campus Nord de Barcelona.

Estas jornadas pretenden ser un acercamiento de la robótica y la domótica a todo el mundo por lo que esperamos la asistencia de todos vosotros.

Toda la información la podéis ver en: http://www.webdearde.com/asambleas.

¡Os esperamos!

Asociación de Robótica y Domótica de España (A.R.D.E.)

Concurso Nacional de Robots AESSbot 2008

Copio directamente el mail que me enviaron desde AESS Estudiantes:

El Concurso Nacional de Robótica 2008 (AESSBot '08) ya está aquí, el evento ser realizará en el ya conocido Campus Nord de la UPC de Barcelona los días 7 y 8 de Marzo de 2008. Este año se realizará el concurso con 3 categorías (Sumo, MiniSumo y Rastreadores) y con dos premios especiales aparte. Podréis encontrar más información, las bases del concurso y las normativas vigentes en: http://aess.upc.es. Esperamos vuestra participación y recordad, las plazas son limitadas

Pues ya lo sabéis, uno de los concursos más antiguos de España vuelve a celebrarse... ¿Quién participa?

S2

Ranganok Schahzaman

El mando universal

Esta claro que la Wii de Nintendo ha supuesto una revolución en la forma de entender los juegos de consola y no porque halla reinventado la rueda. Los juegos en los que tenías que jugar de forma distinta al teclear botónes en un mando ya existían con la PlayStation2: sólo hay que ver los juegos de la Eye Toy o el Dance Revolutions. Sin embargo todo esto son accesorios a la consola, con la Wii el accesorio es el mando "clasico". Tanta ha sido la popularidad del mando (Wiimote) que Sony les ha copiado parcialmente la idea para su PlayStation 3.

Sin embargo, este no es un blog dedicado a consolas o videojuegos, sino a la electrónica y la robótica... Así que pasemos a la acción:

El Wiimote, tiene un sensor de aceleración (acelerómetro) con el que se puede indicar los movimientos del mando, es wireless (sin cables) comunicado mediante bluetooth con la consola, además con la barra de leds (que se pone encima de la pantalla) tienes una referencia espacial lo cual te da la posición del mando en todo momento (siempre que esta apuntando a la pantalla).

Como véis las posibilidades son inmensas, y pueden ser ampliadas mediante un puerto para los periféricos (por ahora sólo el nunchuk que añade un control analógico, otro acelerómetro y varios botones más).

Ahora unos vídeos que demuestran las posibilidades del mando:

• Control de un brazo robótico.
• Control de un robot
• Esta vez con el mando inhalámbrico de la PS3
• Control domótico de una casa.
• ...
  

Da para mucho juego, pero antes una advertencia: hagas lo que hagas agarra con fuerza el mando.

S2

Ranganok Schahzaman