26 de Marzo - Hardware

En esta sesión se ha trabajado en dos frentes simultáneamente.
Por un lado, se ha preparado el software que permita leer del teclado del coldfire y escribir en la pantalla LCD así como habilitar la comunicación por vía UART-2 para poder controlar el robot a distancia.

Por otro lado, se ha construído un circuito para adaptar la señal que proviene del módulo de radiofrecuencia al estándar RS-232 y así mismo adaptar la señal que se recibe desde el coldfire mediante el estándar RS-232 al módulo radiotransmisor.

Centrándonos en este último concepto, cabe destacar la utilización del circuito MAX 3232 como adaptador de señal. La configuración de este circuito integrado es la estándar, definida en su hoja de características como típica.



El flujo de datos en dirección módulo radio --> coldfire se ha conectado al puerto R1 (pines 13 para entrada y 12 para salida) mientras que el flujo coldfire --> módulo radio se ha conectado al puerto T1 (pines 11 para entrada y 14 para salida).
En cuanto a la conexión de la clavija hembra del interfaz RS-232, cabe mencionar la conexión cruzada. El terminal de la clavija "Tx" (pin 3) se ha conectado a recepción ((R-1) datos provenientes del módulo radio) y el terminal "Rx" (pin 2) se ha conectado a la transmisión ((T-1) datos provenientes del coldfire) .
Con esta configuración, el siguiente paso es probar el correcto funcionamiento en ambos sentidos.

• Para el flujo Robot - Coldfire se ha utilizado el mismo programa que para probar el módulo de radio (ver día 23 de marzo) Permitiendo que el coldfire imprima por la pantalla del PC lo que recibe. Las pruebas en este sentido resultaron satisfactorias, aunque se detectó que envíos continuados y sin pausas de datos dan lugar a errores, no obstante, se espera profundizar sobre este tema en sucesivas sesiones.

• Respecto al flujo Colfire - Robot, los resultados no son tan esperanzadores. Se elaboró un programa que, mediante el uso del teclado del Coldfire, permitiese enviar datos, concretamente el valor representado en la tecla, al módulo de radio para que el robot, una vez recibidos, ejecutase una orden concreta en función de lo que recibiese. El problema es que la señal llegaba distorsionada a nivel alto, no presentaba "1´s" estables, sino que parecía una sinusoide. Este tema, hasta el momento sin explicación, queda pendiente para analizar en próximas sesiones, ya que la falta de tiempo lo imposibilitó.

Día 23 de Marzo

Esta sesión ha sido dedicada en su mayor parte a preparar la comunicación inalámbrica entre robonova y el módulo coldfire. Gracias a ello, se podrá en un futuro controlar por radiofrecuencia el movimiento del robot. Para llegar a conseguir este objetivo, primeramente se ha realizado una prueba conectando el módulo emisor de radiofrecuencia al puerto de transimisión en serie del MR-3024 y adquiriendo la señal de salida del módulo receptor mediante el osciloscopio, para que este módulo funcione se debe alimentar con la fuente del puesto a valores de 5 voltios y masa. La rutina que se ha utilizado en el desarrollo de esta prueba contiene como lineas más relevantes:

Dim A as byte 'declaración de las variables que vamos a utilizar.
Dim B as byte
A = "a" 'inicializacón de las variables.
B = "b"
ETX 9600,A 'Transmisión por puerto en serie.
ETX 9600,B

Analizando el código anterior, se puede apreciar que la prueba simplemente consiste en enviar consecutivamente los caracteres ASCII "a" y "b" que en binario son: 01100001 y 01100010 respectivamente. El resultado de la recepción fue que existe un bit de arranque a "0" y un bit de parada a "1", además los datos comienzan a enviarse por el bit menos significativo y terminan por el más significativo, es decir, ocurre lo siguiente:

Símbolo --- Emisor ---- Receptor

a --------01100001 ----0100001101
b --------01100010---- 0010001101

Una vez probado el correcto funcionamiento del módulo, se ha fijado en el brazo izquierdo (esperamos mostrarlo próximamente en foto).

Por otro lado se ha trabajado en la familiarización con el control del módulo UART del coldfire gracias al tutorial de la práctica de GSM.

Como ya se ha dixo, el objetivo para próximos días es poder conectar el receptor de radiofrecuencia al coldfire por puerto serie y así poder tener una comunicacíon bidireccional con el robot. Esto aumentaría sensiblemente las posibilidades del robot. Para este propósito el próximo día se elaborará una placa conversora que permita la comunicación del módulo receptor que funciona entre 5 voltios y 0 con el coldfire cuyos valores son mayores. En proximas sesiones se profundizará sobre el tema.

Dia 16 de Marzo

El primer trabajo del día de hoy ha consistido en hacer girar al robot cuando encuentre un obstáculo de frente a lo largo de su trayectoria, para ello, como en un primer momento disponíamos de un solo modulo de ultrasonidos instalado, la idea básica era que girara 90º en cuanto detectara un obstáculo y que siguiera caminado.

Lo primero que hemos hecho ha sido calcular el numero de movimientos que hace falta para realizar un giro de 90º, pero debido a las condiciones del suelo los “pies” del robot resbalan y no gira con el mismo numero de movimientos hacia la derecha que hacia la izquierda. La distancia que necesita el robot para realizar el giro es de aproximadamente 14 cm (El ancho del robot).
Posteriormente le hemos instalamos otro modulo de ultrasonidos, de esta forma ya tenemos uno en el frontal del robot (este modulo le hemos cambiado la ubicación y ahora se encuentra en el pecho del robot en lugar de al lado de la cabeza donde lo pusimos provisionalmente) y otro en el lateral izquierdo de la cabeza del robot.
Para la instalación de este segundo modulo de ultrasonidos ha sido necesario desconectar el servo que controla el codo del brazo derecho, pese a que aun quedan libres varios puertos. Esto es debido a que para el control de cada modulo de ultrasonidos son necesarios dos puertos no pudiéndose elegir arbitrariamente cualquiera de ellos, para esta función existe un mapeo impuesto por el software del robot que agrupa por parejas todos los puertos y le asigna a cada pareja un nuevo “puerto virtual” que es el que emplea la función SONAR(). Este problema se hubiera podido solucionar con una mejor elección de los puertos empleados por los servos, ya que estos no tienen esta limitación, y haber dejado los puertos que quedan libres emparejados correctamente para poder usar mas de un modulo de ultrasonidos.
Una vez solucionados los problemas del montaje se programo al robot para que cuando encuentre un obstáculo de frente lo esquive de tal manera que pueda seguir su camino hacia delante. Para que realice esta labor mientras va andando se va comprobando que no haya ningún objeto en su trayectoria (la medición se realiza con el ultrasonidos del frontal), si detecta el obstáculo gira 90º y sigue andando hasta que el ultrasonidos lateral no detecta nada, con lo que se supone que ya se ha salvado el obstáculo y que puede volver a girar 90º hacia el lado contrario que lo hizo anteriormente y de esta forma poder seguir andando hacia delante. En el siguiente enlace se puede ver un video de demostración: http://www.youtube.com/watch?v=DXBUyaRTGKs

.

.

Parte del código del programa que permite al robot esquivar obstáculos

.

PuertoSonar = 5 'Comrpueba ultrasonido delantero

GOSUB Adquisicion_ultrasonidos 'adquiere medidas.

IF camina >= 800 THEN 'si está lejos ( 80 cm ) entonces camina.

FOR bucle = 1 TO 4

GOSUB Caminar

NEXT bucle

ELSEIF camina > 250 THEN ' si está a 25 cm da un solo paso

GOSUB Caminar
ELSE 'Lo esquiva girando al lado que defina giro

GOSUB Giro_ultrasonido
ENDIF

'========Subrutina para girar con ultrasonidos============

Giro_ultrasonido:

DIM I AS BYTE

PuertoSonar = 7

GOSUB Adquisicion_ultrasonidos

IF Lateral <= 400 THEN ' si hay una pared cerca por la derecha gira al otro lado

alea = 1

ELSE

alea = 2

ENDIF

FOR I = 1 TO 4

DELAY 500

GOSUB Giro

NEXT I

Sigue:

GOSUB Adquisicion_ultrasonidos

IF Lateral <>

GOSUB Caminar

GOTO Sigue

ELSE

alea = 2

gosub Caminar

FOR I = 1 TO 4

DELAY 500

GOSUB Giro

NEXT I

ENDIF

RETURN

Algunas fotos del Robot

Día 13 de Marzo

Esta sesión ha consistido en probar el módulo de ultrasonidos. Sobre los programas básicos usados el día anterior se han introducido modificaciones.
El programa de prueba de ultrasonidos a "petición popular" ha dejado de emitir pitidos y ahora genera movimientos de brazos por lo que además puede coger cosas. Cuando está cerca de algo cierra los brazos y sino los abre.
Para caminar se ha modificado levemente el programa, y ahora permite dar varios pasos seguidos cuando está lejos del objeto, y a medida que se acerca da menos pasos.
También se ha generado otro programa que permite caminar rápido.
En cuanto a la ejecución de movimientos, se da por buena la actual, considerándose que los "fallos" al caminar, son por irregularidades del terreno.

Para solucionar el problema que presentaba el módulo de ultrasonidos se ha hecho lo siguiente.
Como el comando SONAR() devuelve un número entre 0 y 3000, debemos recogerlo con una variable tipo INTEGER ya que sino se produce desbordamiento, y se efectúa una medida errónea a largas distancias. Concretamente cuando el valor esperado es mayor de 254, máximo dimensionable con las anteriormente utilizadas variables tipo BYTE.
Para próximas sesiones, se espera tomar medidas de qué distancia equivale a el número que devuelve el comando SONAR(). Además se va a empezar a trabajar en esquivar obstáculos, por lo que será necesario comprobar cuanto tarda en girar el robot y qué distancia recorre mientras lo hace. Para girar se utilizarán movimientos del programa de ejemplo. Para esta funcionalidad, se proyectan usar 2 módulos ultrasonidos más, teniendo un total de 3.

En próximos días el código de comprobación del módulo de ultrasonidos será "colgado".

Día 12 de Marzo

Adjunto imagen de patillaje del MR-3024

La primera parte de la mañana el trabajo ha consistido fundamentalmente en adaptar el movimiento por defecto consistente en dar un único paso (mover las dos piernas) para que pudiera caminar de forma continuada e inicialmente indefinida. Para ello se ha eliminado el movimiento de reposo tras cada paso y se ha implementado un bucle para permitir la continuidad. No obstante el movimiento final parece no estar muy depurado, como trabajo para próximas sesiones se piensa en intentar adaptar el movimiento correr.
Seguidamente se procedió a probar los distintos módulos de comunicación del MR-3024, estos módulos son:

1. 
   Módulo de Tx en serie. La prueba consiste en enviar una señal (carácter “a”) por el puerto de tx mediante el comando ETX [Velocidad],[Dato]. La ventaja de este comando frente a TX[escala de velocidad], [Dato] es que mientras el primero permite seleccionar una velocidad concreta dentro de una tabla, el segundo simplemente te permite fijar la velocidad con un número del 1 (más lento) al 4 (rápido). La señal transmitida fue recibida por el osciloscopio con un resultado positivo.
   


2. Módulo PWM. Las pruebas sobre este módulo consistieron en enviar una señal periódica y recibirla con el osciloscopio. La señal fue generada mediante el comando PWM [nº de puerto],[Rango Duty Cycle]. Donde nº de puerto permite seleccionar uno de los 3 puertos PWM (del 0 al 2) mientras que fijando un valor entre 0 y 255 seleccionaremos el duty cycle de la señal. Existe otra función para controlar esto, FPWM [port],[frecuencia],[duty cycle] cuya ventaja es que permite adicionalmente controlar la frecuencia con un valor del 1 (baja frecuencia) al 5. Como conclusiones de esta prueba cabe citar la capacidad del puerto PWM para generar pulsos en segundo plano mientras el procesador hace otras cosas, no obstante la incompatibilidad se presenta cuando se intenta ejecutar un movimiento de servos ya que según el manual esto es incompatible. Las consecuencias de esto pueden ser motivo de estudio en próximos días.
   


3. Módulo AD. El módulo conversor de señal analógica a digital fue probado de la siguiente forma. Se genera una señal desde el tx en serie y se recibe por el módulo AD, si la recepción es correcta ( se recibe algo distinto a 0) se producirá un pitido. El problema que surge es que la tx por el puerto en serie, a diferencia del puerto PWM, no permite trabajar en segundo plano, por lo que cuando se procedía a la recepción ya había concluido la transmisión y por tanto no había “nada” que recibir. Para solucionar este problema se optó por utilizar el puerto PWM, que sí incorpora esa funcionalidad, como generador de señal. La señal se recibe con el comando AD([nº puerto]) donde nº puerto debe ser un número comprendido entre 0 y 7.
   


4. Módulo externo de ultrasonidos. La prueba ha consistido en un primer momento en generar la señal de control del módulo ultrasonidos y captarla con el osciloscopio. Un problema que ha surgido ha sido la ambigüedad en la definición de entrada y salida en el manual, desde el que se define recepción como la entrada de datos dirección MR-3024 a Ultrasonidos. Posteriormente se ha comprobado la generación de respuesta por parte del módulo de ultrasonidos mediante la conexión del osciloscopio al puerto Tx del módulo. Finalmente se ha conectado totalmente el módulo y se ha comprobado mediante un programa que genera pitidos la correcta adquisición de distancias. Esto se realiza mediante la orden SONAR (nºpuerto) que generará un valor del 0 (en caso de error) al 3000 (distancia máxima medible).
   


5. Respecto al puerto I2C no se ha encontrado información por el momento.
   

Finalmente se ha intentado realizar una pequeña rutina que emplease el módulo de ultrasonidos. El programa consistía en que el robot caminase hasta llegar a las proximidades de un obstáculo momento en el cual se debía parar. Este primer intento se puede considerar fallido ya que se para casi aleatoriamente, consecuencia, ésta, que puede estar motivada por:

• 
  Ruido en el laboratorio que interfiere en el sensor.


• 
  Movimiento excesivo del módulo mientras efectúa la medida debido al caminar del robot.


• Falta batería, se ha comprobado que cuando la batería empieza a agotarse el robot comienza a hacer movimientos imprevistos, y pierde fuerza en los servos.

Una solución preparada y que falta por probar es repetir varias medidas antes de tomar la decisión.

Como cuestión para próximas sesiones, convendría investigar el por qué a la hora de ejecutar sonidos los servos se desconectan provocando la caída del robot.

Adjunto link del manual de comandos

http://www.hitecrobotics.com/Tony%20information/roboBASIC%20English%20Command%20Instruction%20Manual(Version%202.10%2020051115).pdf

Si no abre, buscarlo desde google y abrirlo como html.

Día 9 de Marzo de 2007

Tras la primera semana de laboratorio en la que se ha intentado familiarizarse con el uso y la programación del robonova se ha averiguado que la placa controladora de este robot es la mr-3024 que opera con el procedasor At mega 128 que consta de las siguientes funcionalidades:
1- El sistema tiene capacidad para controlar 24 servos de los cuales hay sólamente 16 utilizados.
2-Existen 2 puertos serie adicionales a parte del utilizado para la conexion pc. Uno de ellos del tipo I2C.
3-Hay 3 puertos PWM independientes.
4-Salida para módulo LCD.
5-Consta de 7 conversores analógicos digitales y uno más ocupado por el receptor de infrarrojos
Los terminales son de 3 pines por lo que se cree que sean Vcc, Masa y Datos. Es decir, que alimenten a los dispositivos que se conecten.
En cuanto al lenguaje de programación, de momento, y a falta de poder abrir el manual de comandos por problemas con el adobe, parece que hay definidas constantes para acceder a los puertos, como puede ser RR para acceder al control remoto.
El manual del controlador está en la siguiente dirección http://www.hitecrobotics.com/Tony%20information/MR-C3024%20Spec%20English_Version%201.pdf.

También se ha llegado a un boceto de lo que se busca conseguir. El objeto del curso es realizar un robot expositor que nos guíe a través del puesto y vaya presentando los objetos que existen en la mesa, tales como pantalla, teclado... Todo ello realizado mediante un trazado previamente fijado ya que la posibilidad de que sea autónomo se ve muy reducida, no obstante no está totalemente descartada ya que no se ha negado la posibilidad de conectar módulos de ultrasonidos.

Dia 27 de Febrero

Entorno de desarrollo de Robonova

El Robonova cuenta con un entorno de desarrollo llamado roboBASIC el cual permite programar al robot en un lenguaje relativamente fácil como son los del tipo BASIC.

Todos los programas creados con el editor disponen de tres partes diferenciadas:

1. Programa básico: Definición de variables y otros comandos.
2. Método main: Manejo principal del programa.
3. Métodos y funciones del programa

Algunos comandos de roboBASIC

Compile -> Set zero point

Este menú nos permite seleccionar los puntos neutros del robot para conseguir de esta forma calibrarlos para una mayor precisión en los movimientos que realice.

Controller –> Servo motor real time control (F7)

En la ventana que se nos abre aparecen una serie de controles correspondientes a cada uno de los servos del robot. Estos controles están agrupados en 4 grupos.
Mediante este control podemos controlarlos en tiempo real con tan solo deslizar las agujas hacia los lados. Si desmarcamos los tick que tiene asociado cada control quedara libre el servo correspondiente, pudiéndose poner el robot en la posición que deseemos para posteriormente volver a marcar los tick y capturar de esta forma el movimiento. El movimiento una vez capturado se puede insertar en nuestro código del programa con el comando “move insert” el cual introducirá en la línea que estemos el código correspondiente a ese movimiento.

Controller -> Robonova motor control

Al igual que el anterior nos permite controlar los servos en tiempo real, pero en esta ocasión aparece un esquema del robot, lo cual facilita la labor de reconocer a que servo maneja cada control.

Controller –> Direct line control (F5)

Seleccionando una línea del código de nuestro programa (por ejemplo un movimiento) y pulsando sobre este comando, se ejecuta en tiempo real la línea selecionada.

Dentro del menú Compile tenemos:
· Make Object Project : Permite compilar el programa.
· Download: Carga el programa compilado a la memoria del robot.
· Run all: Compila, carga y ejecuta el programa en el robot.