Plataforma Móvil de Inspección Robotizada PMIR

Proyecto Integrador
SECyT-CNEA-DOE

 

 

Implementación Mecánica:
Ing. Ernesto Davico

 

Control Distribuido:
Mariano Suarez

 

Navegación y Planeamiento de trayectorias:
Fernando Pereiro

 

Control de dirección por lógica difusa:
Ing. Leonardo Davico e Ing. Javier Roitman

 

Control Adaptivo de motores:
Ing. Sergio Alberino e Ing. Pablo Folino

 

Torre de intrumentos:
Sergio Berti

 

Sonar:
detección de obstáculos por ultrasonido

Versión inicial: Ing. Leonardo Davico
Versión avanzada: Javier Nersesián, Melisa Villafañe, Augusto Carimatto y Juan Manuel Perdomo

 

Módulo conversor de protocolo RS232 – RS485:
Ing. Javier Roitman

 

Radio modem:
Ing. Rodrigo Alcoberro

 

Plataforma PMIR 2007 (PDF)

 

 

 

 

 

 

 

Resumen

 

Se trata del diseño y construcción de un carro de transporte de instrumental, autónomo cuya finalidad es la inspección de distintos entornos. El mismo se enfoca principalmente a recolección de datos en ambientes fabriles ó de producción y/o donde sea riesgosa la acción humana, extrayendo información de distinto tipo, mediante sensores adecuados (cámaras de vídeo, sensores ultrasónico, y otros a elección). Cuenta también con facilidades de comunicación inalámbrica con PC mediante radio módem y reconocimiento de imágenes y de voz.

El proyecto está soportado por distintos grupos dedicados a tareas específicas:

 

• Control de servomotores de bajo nivel (Sist. de control – fuzzy control).
• Sistemas de planeamiento de trayectorias
• Sistema operativo de tiempo real
• Red interna de datos control distribuido.
• Detección y procesamiento de imágenes.
• Reconocimiento de voz.
• Ultrasonido.
• Redes neuronales.

 

 

Introducción

 

 

Descripción de las posibles aplicaciones, capacidades, y consideraciones generales.

Se propone el diseño y construcción de una Plataforma Móvil para inspección de instalaciones industriales y manipulación de pequeñas piezas.
La plataforma tendrá tres modos de navegación, uno teledirigido, por medio de un enlace serie cableado/inalámbrico, otro autónomo empleando un plano de la planta donde debe operar, con capacidad para sortear obstáculos no previstos y finalmente un tercer modo de exploración con capacidad de generar el plano de la planta explorada.

 

El brazo manipulador de tres grados de libertad operará mediante un algoritmo adaptivo en base a redes neuronales
A nivel nacional, el desarrollo de plataformas móviles autónomas es prácticamente nulo, si se han desarrollados carros filo guiados a nivel de prototipo o como herramientas ad-hoc para tareas específicas, por ejemplo dentro de centrales nucleares. A nivel internacional, existe una basta experiencia y actualmente el desarrollo está orientado a vehículos autónomos para la exploración interplanetaria y de zonas inhóspitas como la Antártida o los lechos marinos.

 

Esta plataforma estaría destinada a sustituir costosas importaciones, para su aplicación en la industria nuclear, para inspección de recintos con altos niveles de radiación, en la industria petrolera y servicios públicos para inspección de tuberías de gran diámetro y en las fuerzas de seguridad para la manipulación y observación de objetos peligrosos.

 

Las entidades que adquieren esta clase de dispositivos lo hacen como costos extraordinarios frente a una emergencia, y no como una inversión programada para reducir riesgos.

 

Construcción de un prototipo industrial de plataforma móvil de observación y manipulación, con documentación completa para su reproducción a escala industrial, de bajo costo (<$10.000), con capacidad de operación manual/remota/ autónoma con comportamiento programable.

 

 

Especificaciones:

 

 

• Carro: 30cmx40cmx30cm, veloc max:1m/s, radio de giro: 50cm,
• autonomía: >1hs, Precisión del sonar: <5cm, mapa max: 100mx100m,
• radio modem:>100mts@9600baudios,
• Cámara: B/N 200x200px 5c/s.- Grados de libertad: 3 – Alcance en centímetros: 50cm
• Peso a levantar: 500 gramos.
• Precisión y repetibilidad del posicionamiento:5 décimas de milímetro.
• Velocidad vectorial mínima del movimiento del TCP ( Tool Center Point): xx mm./seg.
• Movimiento coordinado de los ejes: El alcance máximo es el que oficia de maestro?
• Máximo peso total: 5000 gramos.
• Servomotores de C:C:
• Control de los motores abordo con microcontroladores dedicados

 

El proyecto se basa en un esquema de control distribuido, conectado por un bus serie RS485, con protocolo tipo Mod Bus. Este bus está controlado por un Master o procesador central donde residirán los algoritmos de control del bus y de navegación. Además sobre este bus operarán las unidades de control de tracción, control de dirección, control del brazo, radio modem, sonar, control de cámara, alimentación etc.

 

Esta arquitectura posibilita un desarrollo incremental, partiendo de tres módulos básicos: Procesador central, control de ruedas y de dirección y alimentación. Cada uno de los módulos tiene su propia especificación en cuanto a información de entrada, de salida y formato de los comandos. La responsabilidad de su ejecución esta a cargo de distintas comisiones de no menos de dos personas cada una.

 

Se dispondrá de una plataforma para la evaluación de algoritmos de Inteligencia Artificial y Robótica para aplicaciones en la industria local.
C on especial énfasis en las disciplinas asociadas como, Planeamiento y evasión de obstáculos, Control Robusto, Neuro Control, Control Difuso, Reconocimiento del habla, Procesamiento de imágenes, Reconocimiento de patrones.

 

 

Plataforma Móvil de Inspección: Ventajas del proyecto

 

Posibilidad fusionar todas las disciplinas de IA un único proyecto

Modelo incremental, acumulativo

Integración de Soft y Hardware

Posibilidad de aplicaciones prácticas

Prototipo económicamente viable

 

 

Plataforma Movil de inspección: Esquema

 

        

 

Plataforma Movil de Inspección: Fotos

 

 

 

 

Control Distribuido

 

Esquema General de Hardware

 

 

 

Administrador de tareas

 

En una arquitectura de robot como la que nosotros proponemos, móvil y autónomo, el administrador de tareas o sistema operativo toma una importancia fundamental, ya que de él depende el correcto funcionamiento de todos los módulos de software y hardware. El Sistema Operativo (S.O.) es el encargado de administrar los recursos de procesamiento y de memoria para que cada tarea sea efectuada en tiempo y no retrase a una tarea posterior. Para ello la tarea a ser ejecutada debe tener los datos y los recursos para procesar esos datos. Muy probablemente dichos datos sean provenientes de una tarea efectuada con anterioridad por lo que se ve claramente que el trabajo del S.O no es menor. Para resumir podemos encuadrar la tarea del S.O. en los siguientes puntos:

 

• Administrar los recursos de procesamiento, memoria, bus.
• Auditar el funcionamiento de cada tarea y desactivar la que no responda.
• Proporcionar un set de funciones utilitarias para que las tareas accedan al hardware a través de ellas.

 

En la arquitectura de control distribuido propuesta no existe una única placa con inteligencia para procesar, sino que la inteligencia está distribuida. Esto hace que el S.O deba administrar una red interna. Además gracias a la flexibilidad de la arquitectura, la PC de control y telemetría se puede tratar tanto como un ente externo o como una extensión del bus interno del robot hacia el exterior.

 

Un sistema operativo de estas características debe ser extremadamente robusto, es decir altamente estable e inmune al mal funcionamiento de una tarea que se esté ejecutando. Es decir que si por algun motivo una tarea dejara de funcionar correctamente el S.O. no se debe bloquear y por ende bloquear el funcionamiento del robot, sino que debe ejecutar una estrategia de recuperación (como una aplicación).

 

De todo esto se desprende que el S.O. debe ser multitarea y debe asignar slots de tiempo a cada una de las tareas y debido a que se debe realizar la administración de los dispositivos (o las tareas) en el momento que ellos lo necesitan, tambien debe ser “de tiempo real”. Es decir que existe un intervalo de tiempo máximo acotado (y lo mas pequeño posible) en el que el S.O. atenderá una tarea que lo requiera. Además este tiempo no debe variar en forma significativa con la cantidad carga computacional que se esté manejando en el momento.

 

Además el S.O. debe tener un conjunto de funciones que faciliten la utilización de los recursos. Este paquete de funciones de bajo nivel permiten por ejemplo:

 

• Leer y escribir bloques de memoria.
• Transmitir y recibir en el bus interno.
• El manejo de tipos de datos.
• La implementación de funciones matemáticas.
• La transmisión de mensajes entre tareas.

 

Yendo a la arquitectura del S.O propiamente dicho, existen fundamentalmente dos enfoques. Los sistemas operativos del tipo monolíticos y los S.O. del tipo microkernel. Los primeros tienen la ventaja de que al implementar en el kernel la mayoría de las funcionalidades del sistema operativo, disminuye la transmisión de mensajes entre tareas y el cambio de contexto, por lo que tienen una mejor performance relativa. En cambio los S.O del tipo microkernel…

 

 

Navegación y Planeamiento de trayectorias

 

 

Navegador

 

El sistema “Navegador” este formado por dos programas: “Yo” y “SuperYo”. Estos dos programas corren independientemente uno del otro, “Yo” corre a bordo del robot mientras que “SuperYo” corre en la PC que lo comanda.

Si bien las funciones de ambos son las mismas estos se reparten las tareas de manera en que “SuperYo” comanda a “Yo” mientras este es quien realmente maneja al móvil.

 

Usuario >> SuperYo >> Radio Modem >> Yo >> Red Interna >> Móvil

A su vez la arquitectura interna del sistema esta organizada en tres niveles:
el inferior son las funciones de interfaz con los diferentes dispositivos (ruedas, radar, brújula, etc.), por encima de este las funciones de manejo y lógica (trazado de recorridos, posición, mapas, etc.) y en el nivel superior esta el interprete de comandos en el cual el usuario puede ir escribiéndole comandos los cuales este ira interpretando y ejecutando.

 

Un esquema de este modelo seria el siguiente:

 

Interprete de comandos >> Lógica >> Interfaz con dispositivos

 

 

Interprete de Comandos:

 

Este interprete posee una reducida cantidad de comandos con una infinita cantidad de sinónimos de estos comandos. Suena complicado pero es bastante sencillo, por ejemplo existe el comando “#IF” el cual sirve de condicional al cual el usuario le puede asignar el sinónimo “si” para utilizarlo mas fácilmente.

 

Además se pueden asignar sinónimos cuyas definiciones no sean un comando sino una serie de comandos o inclusive una serie de comandos y /o sinónimos los cuales apunten a su vez a otros comandos, estos sinónimos pueden ser del largo que el usuario desee de tal forma que podría escribir toda una rutina la cual se llame con solo una palabra.
La asignación de sinónimos es realizada automáticamente por el Interprete de la siguiente forma:

 

El usuario escribe un comando, cuando el interprete encuentra una palabra desconocida le pregunta al usuario su significado y de ser respondido queda asignado el sinónimo. De haber encontrado una serie de palabras sin significado, el interprete va preguntando por el significado de cada una de las posibles oraciones, de esta manera podemos encontrar sinónimos de longitudes mayores a una palabra. Cabe también destacar que para un mismo comando pueden existir varios sinónimos que lo representen, como también pueden existir sinónimos de expresiones numéricas.

 

Además de los comandos y sinónimos podemos definir Sustantivos los cuales pueden adoptar valores numéricos o de palabras, estos le pueden servir al usuario para representar variables dentro de alguna rutina. Estos Sustantivos se escriben con la sintaxis “##palabra” donde palabra podrá ser cualquier sucesión de letras y números sin espacios intermedios, la generación de los mismos es automática desde el momento en que se los invoca y adoptando el valor que se les pase, de no pasársele ningún valor adoptaran el valor cero.

 

Lista de comandos del Interprete

 

Comando Tipo Descripción”#TIME” Dato In Fecha Hora
“#IDBARRAS” Dato In Evento que ocurre al leer un código de barras
“#BRUJULA” Dato In Numero que representa el valor devuelto por la brújula
“#SONAR” Dato In Distancia devuelta por el sonar
“#GRADOS” Dato bidireccional Posición del timón
“#DISTANCIA” Dato bidireccional Distancia que se esta recorriendo o que se desea recorra
“#VELOCIDAD” Dato bidireccional Velocidad de las ruedas
“#X” Dato bidireccional Coordenada X en el mapa
“#Y” Dato bidireccional Coordenada Y en el mapa
“#RESPONDE” Directiva Devuelve el resultado de la expresión lógica que le siga
“#RESETS” Directiva Borra todos los Sustantivos
“#CUANDO” Directiva Funciona como un condicional que de no ser true guarda la expresión
en una base datos y la ejecuta cuando pase a ser true
“#IF” Evaluación Condicional
“#ELSE” Evaluación Opcional del “#IF”
“#=” Operador Asigna o evalúa valor según corresponda
“#<>” Operador Evalúa valor de distinto que
“#>” Operador Evalúa valor mayor que
“#<” Operador Evalúa valor menor que
“#*” Operador Operador aritmético de multiplicación
“#/” Operador Operador aritmético de división
“#+” Operador Operador aritmético de suma
“#-” Operador Operador aritmético de resta
“#AND” Operador AND opcional del “#IF”
“#OR” Operador OR opcional del “#IF”
“#XOR” Operador XOR opcional del “#IF”
“#NOT” Operador Negación opcional del “#IF”
“.” Fin Comando Se utiliza seguido de “enter” para que se procese un comando

La interfaz del interprete radica en el “SuperYo” pero su motor (Sinónimos, Sustantivos, interprete) esta en el “Yo”, esto debe ser así ya que de haber un comando “#CUANDO” el cual contenga sinónimos estos deben estar disponibles al momento de ejecutarse, cosa que no ocurriría de cortarse la comunicación con el “SuperYo”.

 

Planificación en entorno de mapa conocido

 

Especificaciones del mapa de entorno:

· El mapa será ingresado como un bitmap que indique celdas libres y ocupadas.

· Cada celda medirá 15×15 cms. (1/4 del diámetro previsto para el vehículo)
obteniendo así una definición del entorno más que aceptable para la planificación previa a la navegación.

Error del mapa: + – 15 cms.

Error máximo de planificación del espacio libre de obstáculos: 30cms.

Al considerar que el diámetro medio del robot es de 60 cms. todo error cometido es despreciable para la planificación.

· Espacio de almacenamiento del mapa:

aprox. 7 x 7 bits por mtro.cuadrado

 

Método de Planificación

 

1. Obtengo el versor director de la recta que une el punto de inicio con la meta. Lo denomino dirx , diry (respectivamente).

2. Luego debo planificar el vector RUTA que contendrá a todas las celdas del camino a seguir.

3. Para cada PASO de RUTA debo:

· Sumar el versor director a la posición actual y aproximar el resultado al entero más próximo. De este modo obtengo proxcelda.

· Si proxcelda se encuentra libre entonces AGREGOUNPASO:

· Agrego proxcelda al vector RUTA.
· Actualizo mi posición actual.
· Planifico el próximo PASO.

· De otro modo debo planificar la evasión del obstáculo:

A) Debo conseguir virar en un ángulo de 90 grados de la posición angular absoluta del obstaculo1 con respecto a la posición inicial del vehículo (a derecha o izquierda) cual sea el menor ángulo con respecto de mi versor dir (en nuestro ejemplo sería 180)

B) Si la celda se encuentra desocupada AGREGOUNPASO y obtengo mi nuevo versor dirección (dir2).

C) De encontrarse también ocupada utilizo EVASION2:
· Utilizo la otra alternativa (en el ejemplo 0 )
· Si se halla desocupada ejecuto AGREGOUNPASO ,y proxcelda
es la dirección de mi movimiento original antes de detectar el obstaculo1

 

Sistema de comando y navegacion para robot movil con arquitectura distribuida (PDF)

 

 

Control de dirección por Lógica Difusa

 

La idea del control por lógica difusa es que el robot móvil sea guiado en forma suave a lo largo de su recorrido de manera de minimizar los efectos que podrían causar los errores de posición.
La lógica difusa es una técnica de control basada en reglas del tipo:
IF Rad_E IS Positivo AND Rad_dE IS Zero THEN dtita Poco_Izquierda
IF Rad_E IS NearZero AND Rad_dE IS Zero THEN dtita Derecho
IF Rad_E IS Negativo AND Rad_dE IS Zero THEN dtita Poco_Derecha

 

 

Se puede observar que también entran en juego sustantivos como Rad_E (error de radio) y adjetivos que se refieren a esos sustantivos como son Positivo, Poco_Izquierda, se nota también que puede aplicarse a sistemas de múltiples entradas y salidas.

 

A diferencia de la lógica convencional, las transiciones entre los estados no son discretas sino que son suaves, evitando de esta manera los saltos bruscos.
Las reglas y los adjetivos deben ser definidos por un operador que tiene experiencia en el proceso que desea controlar, y lo hace de manera que el sistema trate de imitar las acciones de control que tomaría el mismo operador según las condiciones de las entradas y salidas.

 

El operador debe definir cada uno de los adjetivos, esto puede hacerse en forma gráfica como se ve en la figura, de este modo según el valor de la entrada se obtiene un grado de pertenencia para cada adjetivo (numero de 0 a 1). Estos grados de pertenencia serán los que hagan disparar las reglas antes definidas con diferente intensidad, mayor intensidad para las reglas con antecedente “mas verdadero”.

 

Una vez que están definidos todos los puntos mencionados anteriormente pueden realizarse simulaciones del control por lógica difusa, para esto es necesaria el desarrollo de un modelo de lo que se quiere controlar y su entorno, en nuestro caso el robot móvil y el ruido presente en el posicionamiento. En la siguiente figura se muestra una corrida de simulación del robot controlado por lógica difusa en donde trata de seguir una trayectoria diagonal comenzando con un error de posición inicial que debe ser minimizado a lo largo del trayecto.

 

 

 

 

 

Control de Motores

 

Objetivo

 

El objetivo de este módulo es ejercer la acción de control Proporcional-Intergral-Derivativa (PID) sobre dos motores de corriente continua (CC). Uno de los motores es el encargado llevar a la posición angular deseada la rueda de dirección de la plataforma móvil. El segundo motor, por otra parte, controla la tracción a fin de darle desplazamiento a la misma.

 

Requerimientos, Especificaciones

 

El sistema está compuesto por un motor de CC con reducción, un codificador de cuadratura para sensar la posición del eje de salida, un microcontrolador que ejecuta el sistema de control y la interfaz con el usuario y una etapa de potencia PWM “inteligente” en puente H tipo D-MOS.

El control PID se implementa en forma digital utilizando como procesador el microcontrolador de 8-bits AVR AT90S8515 de Atmel.

 

Diseño

 

 

Implementación

 

Se utilizó como herramienta de desarrollo el kit de Atmel STK-200 con un AVR 90s8515. Luego se desarrolló en el GIA una placa propia que permitió no solo el control del motor, sino también la programación del micro, dejandose de lado entonces el Kit de Atmel.

 

Microcontrolador

 

90S8515 Características:· AVR tecnología RISK
Salida PWM que se modula con una simple escritura de un registro interno.
Comparador analógico
Programable vía Serie
Memoria Flash
Operaciones matemáticas en 16 bits

 

Motor de CC con reducción

 

marca IGNIS, modelo MR-8. (VNOM=12V, IA=400mA). Para la dirección se eligió la reducción de 78RPM nominales (MR8-78). Para la tracción se eligió una versión potenciada (IA=600mA, cupla 50% mayor) con reducción de 258RPM nominales (MR8-258, potenciado). Las especificaciones físicas, mecánicas y eléctricas de estos motores se encuentran en el catálogo

 

 

Codificador de cuadratura (Encoder)

 

HP HEDS-5600 que sensa la posición del eje del motor y constituye por lo tanto la retroalimentación del sistema de control. Único codificador disponible en el país a bajo costo. Se trata de un codificador de dos canales, sin índice, de 500 pasos por revolución, para un eje de 6mm.

 

 

Etapa de potencia en puente H

 

Utilizando el puente LMD18200T DMOS de National Semiconductor. Este puente es capaz de manejar motores de hasta 3A continuos de corriente de armadura y tensión nominal de hasta 55V. Está integrado por cuatro transistores D-MOS. Cuenta con sensor de corriente integrado, salida de sobre temperatura y entrada directa de PWM y entrada de freno. Este componente no se consigue en el país.

 

 

 

 

Conclusión

 

La placa de control de motor se encarga de mover el motor a la posición deseada, controlando la velocidad y corrigiendo errores a través del control Proporcional Integral Derivativo. También se encarga de medir cuanto se ha movido la rueda, y evita cálculos engorrosos al control central (navegador), que solo debe indicarle cuanto debe moverse.

 

Bibliografía

 

“Sistemas de Control” de Ogata.

Microchip AN-532 “Servo Control of DC-Brush Motor” (PDF)

 

 

Publicaciónes asociadas

 

Variante en el algoritmo pid para evitar el uso de un generador de trayectoria trapezoidal (PDF)

 

Control PID con esquema adaptivo de filtrado de ruido (PDF)

 

Fast self tuning PID controller specially suited for mini robots (PDF)

 

Control PID con Filtro Dinámico de Promedios Móviles Ponderados Exponencialmente (dEWMA-PID) (PDF)

 

 

Sonar

 

La función principal del módulo de sonar es permitir al robot móvil conocer la distancia que lo separa de los objetos que lo rodean.

 

Para lograr realizar esta medición de distancia, en realidad lo que se mide es el tiempo que le toma a un tren de pulsos de ultrasonido el recorrer el camino desde el robot al objeto y el camino de vuelta del objeto al robot, es decir, el tiempo de arribo del eco. Una vez obtenido este valor tiempo y conocida la velocidad del sonido en el medio en el que se encuentra el robot puede conocerse la distancia.

 

En la siguiente figura se observa un diagrama en bloques del modulo de sonar.

 

 

El microcontrolador empleado para este módulo de hardware es un PIC16F874 de tipo RISC que ejecuta 1 millón de instrucciones por segundo, este tiene varias facilidades de temporización de eventos que hacen posible la medición del tiempo de vuelo del ultrasonido. También cuenta con un conversor A/D que permite medir la amplitud del eco recibido y la temperatura ambiente, esto puede servir para realizar correcciones en los valores de distancia obtenidos. El microcontrolador también cuenta con un puerto serie que permite comunicar al modulo de sonar con el resto del robot móvil a través de la red interna, de este modo el sonar queda a la espera de algún comando y cuando lo recibe realiza las tareas necesarias para obtener el resultado pedido y lo devuelve por la red al solicitante.

 

Una parte importante de este modulo es la etapa de amplificación de la señal recibida y el detector posterior, que debe ser capaz de discriminar el eco de ultrasonido del ruido ambiente, esto es especialmente crítico cuando se desean medir distancias grandes (3 a 6 m) debido a que la señal de eco que llega es pequeñísima. El detector tiene dos modos de funcionamiento, el modo de detección por amplitud que es conveniente para distancias cortas por su precisión y el modo de detección por tonos que es conveniente para largas distancias por su mayor inmunidad al ruido. Estos modos de funcionamiento son automáticamente seleccionados por el microcontrolador según en que etapa de la medición se encuentre lográndose así un resultado óptimo.

 

El sonar podría montarse en una tortea giratoria, para poder barrer el entorno del robot y confeccionar un mapa ultrasónico del entorno.

 

Disposición Mecánica

 

La disposición mecánica del robot móvil es de gran importancia ya que una buena elección según el caso permite minimizar los factores que causan errores en el calculo de la posición por odometría. La odometría es uno de los métodos más empleados para la guía de vehículos robot, permite obtener ubicaciones precisas en cortas distancias, con un muy bajo costo y una alta velocidad de muestreo.

 

El principio básico de la odometría es la integración de la información de los movimientos incrementales a través del tiempo. El hablar de integración nos señala de forma intuitiva que toda clase de error será acumulativa. Especialmente el error de orientación es el que más afecta debido a que es proporcional con la distancia recorrida. A pesar de estas limitaciones en general se coincide en que la odometría es una parte importante en los sistemas de guía de vehículos y que cuanto mejor sea la calidad de esta técnica mas se simplificaran las tares y sistemas que mejoran el posicionamiento del vehículo. En la figura vemos la primer configuración analizada, es la de un vehículo con par diferencial. En este diseño se montan un par de encoders incrementales en ambos motores para contar las revoluciones de cada rueda. También posee un juego de ruedas libres que le dan la estabilidad.

 

El robot puede reconocer su posición utilizando ecuaciones de geometría para calcular la posición relativa actual del vehículo con respecto a una posición de inicio conocida.

 

Los vehículos con ruedas libres que soportan una parte importante del peso total estarán mas expuestos a sufrir resbalamiento cuando se invierta el sentido del movimiento (efecto “carro de supermercado”). Por el contrario si el peso que soportan es relativamente pequeño inducirán un menor deslizamiento.

 

 

La segunda configuración analizada es la de Triciclo Simple que emplea una sola rueda tractora direccionable (dos grados de libertad) y dos ruedas pasivas alineadas lo que permite que esta disposición sea muy utilizada por su simplicidad inherente.

 

Una desventaja de esta configuración es que el centro de gravedad del vehículo tiende a alejarse de la rueda tractora cuando este esta atravesando un plano inclinado.

 

 

Esto ultimo puede producir una perdida momentánea de tracción lo que introducirá un error acumulativo en el posicionamiento. Las ecuaciones que vinculan la nueva posición y orientación en función del la dirección de la rueda, su avance y la posición y orientación anterior permiten mantener el posicionamiento del robot en forma indirecta.

 

Esta configuración no tiene los inconvenientes que acarrean las ruedas libres y además permite una posible mejora que consiste en dotar al robot con dos ruedas delanteras tractoras que minimizan los deslizamientos, para simplificar el análisis puede seguir considerándose como un triciclo virtual. Se opto para nuestro robot móvil por la configuración de triciclo simple debido a sus ventajas sobre el diferencial y su simplicidad aunque no se descartar para un futuro la configuración con dos ruedas tractoras.

 

 

 

Sonar: Versión 2007

 

 

 

Módulo conversor de protocolo RS232 – RS485

 

Objetivo

 

Permitir que dispositivos que no soporten el protocolo de la red interna del robot puedan conectarse a la misma.

 

El protocolo del robot especifica una capa física basada en RS-485 y una capa de enlace con entramado y direccionamiento basado en caracteres de 9 bits. Los 8 bits menos significativos de cada carácter contienen el byte a transmitir. El bit más significativo o 9° bit controla el entramado. El primer carácter de cada trama debe llevar dicho bit en 1. Todos los demás caracteres lo llevan en cero. Por otro lado, muchos dispositivos, y en particular las PC, tienen puertos serie RS-232 y emplean caracteres de 8 bits. Si bien es posible salvar la diferencia de capa física con un convertidor de niveles estándar, no es posible operar con caracteres de 9 bits.

 

Esta dificultad es más notable cuando la PC corre sistemas operativos que no permiten un control directo del puerto serie, como ser MS-Windows. El dispositivo propuesto permite a una PC, mediante un protocolo de enlace basado en caracteres de 8 bits, comunicarse con dispositivos que se encuentren la red del robot. Para ello, traduce los mensajes en tiempo real, en forma bidireccional y transparente entre ambos protocolos.

 

Requerimientos, Especificaciones

 

Alimentación Tensión: entre 7.5V y 12V, corriente contínua. Consumo: 100mA máximo. Conector: hueco, pin central fino. Positivo al centro.

 

Puerto RS-232 Conector DB9 Hembra. El sentido de los pines están vistos desde el Adaptador. Conforma un dispositivo DCE, según la norma RS-232. El pin DTR debe estar activo para que el AP funcione. Desactivando dicho pin se resetea el AP. Comunicación a 19200bps, 8 bits de datos, 1 bit de parada, sin paridad.

 

Indicadores El AP cuenta con dos indicadores luminosos o LED, uno de color rojo y otro de color verde. El LED rojo indica la presencia de tensión de alimentación. El LED verde indica que el AP está en operación, cambiando de estado con cada carácter transmitido o recibido.

 

RESET El uP cuenta con un pulsador de RESET para reiniciar la operación en forma manual de ser necesario. Esta función también puede controlarse desde el pin DTR del puerto RS-232.

 

 

Diseño de Hardware

 

 

 

Implementación

 

La aplicación requería un hardware con dos UARTS. De los microcontroladores fácilmente disponibles al momento del desarrollo, ninguno cumplía con este requisito. Implementar la segunda UART por software implicaba más tiempo de programación y era difícil alcanzar la velocidad de comunicación requerida.

 

Se eligió una implementación con dos microcontroladores de 20 patas, basados en memoria FLASH y de bajo costo, en una configuración “espalda contra espalda”, de forma tal que la UART de cada micro maneje su puerto respectivo y los datos se intercambien sobre un bus bidireccional de 8 bits con dos líneas de control en cada sentido (carga y asentimiento).

 

El micro del lado RS-232 funciona sólo como UART, con doble buffer en transmisión y en recepción. El micro del lado Robot (RS-485) controla todos los aspectos de ambos protocolos de enlace y la operación del puerto RS-485. El protocolo de enlace RS-232 encapsula la trama del robot, facilitando su entramado en sistemas de 8 bits. El firmware está íntegramente desarrollado en lenguaje C.

 

 

Conclusión

 

La presente es una solución económica y simple al problema planteado. Sólo requiere que el dispositivo RS-232 a conectar pueda soportar el protocolo de enlace. En el caso típico de ser una PC, esto no representa ningún problema. Además, como el uP es transparente al direccionamiento de la red del robot, varios “nodos lógicos” podrían coexistir en la PC

 

 

Bibliografía

 

“Robot – Protocolos Capas 1 y 2”. Ing. Javier I. Roitman. Marzo 2002 (DOC)

 

 

Enlace digital por radio (radio-Modem)

 

 

• Modulación de frecuencia a 433MHz
• Transmisión Half Duplex
• Velocidad de señalización: 40kBaud
• Tasa de transmisión: 20kbps
• Codificación de canal: Manchester
• Filtro gaussiano en el canal de transmisión

 

Transferencia de Datos a través de un enlace de Radiofrecuencia.
 
 

Introducción

 

La comunicación del robot movil con otros robots o con una o mas Computadoras Personales para la transferencia de información se puede realizar de dos maneras:

 

• Con una conexión física (cable).
• Sin conexión física (radio, infrarojos).En nuestro prototipo de robot movil de desarrollan los dos tipos de comunicación. La comunicación por cable por ser sencilla de realizar, segura y confiable pero incómoda por el hecho de que la movilidad del robot limita la comunicación a los intervalos “entre pruebas”.

 

La comunicación por radio ya que con ella se pueden realizar telemetría del robot en tiempo real mientras se desenvuelve en un entorno, y también se puede utilizar una Computadora personal para realizar cálculos que fueran imposibles para la capacidad computacional del robot, o para aprovechar un entorno de desarrollo de algoritmos mas “amigable” que el Hardware dedicado que posee el robot.

 

Radio Modem

 

La interfase de datos del robot móvil con el mundo exterior debe cumplir ciertos requisitos funcionales, éstos requisitos son tasa de transmisión aceptable, movilidad, esquema multipunto. El método de transmisión mas fiable, sencillo y barato es la transmisión serie por cable, por ello es el método de transmisión mas usado comunmente en la industria, con infinidad de protocolos disponibles. Para el caso de un robot móvil, la transmisión por cable limita el uso del robot a un entorno limitado y entorpece su desplazamiento. Con lo cual se puede llegar a una solución por medio de un sistema de transmisión inalámbrico, ya sea óptico (infrarojo), radiofrecuencia o acústico (se detalla en la sección de reconocimiento de voz). Para esta platafoma móvil se adoptó el sistema de transmisión por RF ya que el sistema óptico tiene la limitación que el transmisor y el receptor deben estar “en la línea de visión” lo que limita el uso en lugares intincados.

 

El RadioMoDem (Modulador-Demodulador por Radio) utiliza un módulo de última generación para la transmisión y recepción de señales de radio. Dicho módulo es utilizado comunmente para telemetría y cumple con todos los estandars internacionales. Transmite señales moduladas en frecuencia en 433MHz, que es la banda asignada para la transmisión de señales de telemetría en Europa.

 

En la cadena de transmisión utiliza filtros SAW (onda acústica de superficie) y el receptor es superheterodino de doble conversión. La potencia de transmisión es de 1mW (0dBm) y la sensibilidad de recepción es de -107 dBm. Esto hace que el rango de utilización sea de 120 metros en espacio abierto y 30 metros dentro de un edificio. El ancho de banda de la transmisión es de 32kHz.

 

Para poder realizar la comunicación de datos se debe tener, ademas del módulo de radio, una etapa de codificación del canal, una etapa de CRC, una etapa de interfaz de línea y control de flujo, memoria y lógica adicional. Nosotros hemos optado por integrar la mayor parte de estas etapas en un solo chip, un microcontrolador de 20 pines y muy bajo costo. Con lo cual se implementó módulos de software en lugar de electrónica discreta.

 

La arquitectura de diseño “todo software” tiene gran auge actualmente ya que brinda una gran flexibilidad, ya quer se puede hacer personalizxaciones del radiomodem a mucho mayor velocidad y a costo mucho menor que con electrónica “en hardware”. Además cualquier adaptación futura como ser cambio de código corrector, tipo de codificación, lógica de transmisión, etc, se realiza solo cargándole el nuevo software al microcontrolador.

 

La figura muestra el diagrama en bloques completo del radiomodem.

 

 

El primer bloque del transmisor comprende la interfáz de línea del tipo RS232 para el lado de la PC y RS485 para el lado del robot, la UART de recepción y la despaquetización de los datos. Dicho paquete de datos está compuesto de un Start of Text (STX = 02h) luego los datos con formato y luego un End of Text (ETX = 03h). El STX y el ETX se eliminan y los datos se repaquetizan para poder ser enviados por radio. Ello implica agregarle un preambulo (1010101…10) y un sincronismo en la cabeza del mensaje, y un código corrector robusto y especialmente diseñado para la transmisión por radio en el final. El paquete completo queda de la siguiente forma.

 

El CRC es del tipo convolucional de 15 bits mas uno de paridad conforme a la norma MPT1327 de transmisión por radio.

 

Los períodos largos de en los que no existen variación en la información (todos unos o todos ceros) afectan el funcionamiento del transmisor de FM por lo cual se debe realizar una codificación del canal, para que siempre existan variaciones de nivel. Para realizar esto existen muchas técnicas aplicables bajo distintas circunstancias en nuestro caso elegimos la codificación Manchester por tener un buen compromiso entre beneficios obtenidos y cantidad de recursos de procesador necesarios para su implementación. La figura muestra la codificación Manchester.

 

Mediante la codificación Manchester se puede realizar además la recuperación del clock de transmisión desde la señal recibida que es de utilidad para los sistemas de transmisión sincrónicos.
Luego de la codificación se realiza el pasaje de la señal por un filtro gausiano aproximado que mejora en gran medida el rendimiento de la detección.

 

El radiomodem puede trabajar en un esquema de red ya que posee un algoritmo de detección de portadora por el cual si el radiomodem A tiene datos para transmitir pero existe un radiomodem B transmitiendo, el radiomodem A disparará una rutina de demora aleatoria acotada y al cabo de ella intentará la transmisión. Así hasta que pueda transmitir finalmente la información.

 

Otra facilidad del radiomodem es la de poder configurarlo por la misma interfaz serie ya que él posee una dirección propia (y configurable) con lo cual es posible enviar un paquete dirigido a él y no para enviar al aire.