Final

Después de varios meses trabajando, llegando incluso a dividirnos el trabajo, hemos conseguido nuestro objetivo. Robonova ya habla.
La demsotración se puede ver en http://www.youtube.com/watch?v=gsWwIh8Q0W0.
Conseguir ésto es resultado de técnicas tftp, implementación DAC, comunicación vía UART y demás funcionalidades descritas a lo largo de este blog.
El resultado, si bien puede parecer simple, responde a un gran esfuerzo, debido a que se ha tenido que partir prácticamente desde 0 con el robot. No obstante, nos gustaría remarcar lo positivo de la experiencia y lo recomendable que es hacia aquellos que denoten interés por la robótica.
Finalmente, nos gustaría concluir con la esperanza de que todo este trabajo sirva de reclamo para que sea mejorado en un futuro, ya que el tiempo ha sido nuestro mayor enemigo.

Servidor TFTP

Durante las semanas anteriores se ha conseguido reproducir sonidos por medio del DAC del Coldfire, pero presentaba un problema: cada vez que había que cargar el programa en la memoria del Coldfire se hacía necesario volver a cargar los arrays con las muestras de voz, con el consiguiente tiempo que conllevaba.
Para solucionar, o al menos disminuir el tiempo de carga, lo que se ha realizado es montar un servidor TFTP en un ordenador. A este servidor accederá el Coldfire por medio del puerto Ethernet y se descargara los archivos de voz que necesite para posteriormente reproducirlos.
El programa en C que realiza esta tarea tiene dos partes. Por un lado se encuentra el cliente TFTP que se descarga el archivo que especifiquemos y los guarda a partir de la posición de memoria 0x60000 del Coldfire, que se corresponde con la memoria de usuario que asigna el cliente para la descarga de archivos. Esta memoria se extiende hasta la posición 0x70000 por lo que en principio nos podemos descargar archivos de hasta un tamaño máximo de 64 KB.
Una vez descargado el archivo se accede a la posición 0x60000 y mediante un bucle vamos recorriendo todos los valores hasta alcanzar el tamaño del archivo y los vamos transmitiendo al DAC, igual que hacíamos con el array de datos.
En la dirección http://docs.google.com/Doc?id=dgs9sf7s_3thk754 se puede encontrar el archivo principal del programa (habla.c).

Programa arrayC

Como ya se ha comentado en la entrada anterior, necesitamos tener un array en C que contenga las muestras de nuestra señal de voz digitalizada. Para poder generar dicho array se ha desarrollado un pequeño programa en java que proporcionándole un archivo de audio WAV con formato PCM es capaz de generar dicho array.

Para el desarrollo de este programa se ha tenido que tener en cuenta las especificaciones del formato WAV que se encuentran en la siguiente Web http://ccrma.stanford.edu/courses/422/projects/WaveFormat/ aunque la siguiente tabla las resume bastante bien.

















El programa se puede ejecutar de dos maneras distintas. Una consiste en modo texto, en la cual al ejecutar el programa se le pasa como parámetro el nombre del archivo WAV que queremos convertir, generando en ese mismo directorio un fichero con nombre array.c que contiene las muestras.













Otra forma de ejecutar el programa es en modo gráfico. De esta forma solo tendremos que seleccionar el fichero WAV que queremos convertir en el menú archivo->Abrir fichero *.wav. En la ventana nos aparecerá la información correspondiente al archivo y para generar el array tan solo habrá que pulsar el botón “¡¡Generar array!!”.









¡IMPORTANTE!


Como el audio que vamos a reproducir se trata de voz los archivos wav deberán de tener las siguientes características.

1 canal de audio (Mono)

8 bit/muestra

8000 Hz de frecuencia de muestreo

Formato PCM (Sin compresión)


Los archivos JAVA se pueden obtener de los siguientes enlaces:

Sin interfaz gráfica: http://docs.google.com/Doc?id=dgs9sf7s_0hmf293

Con interfaz gráfica: http://docs.google.com/Doc?id=dgs9sf7s_1dgj67s

Para la ejecución del programa con interfaz gráfica es necesario tener compilados en la misma carpeta las dos clases.


Para descargar el programa ya compilado: http://www.mediafire.com/?9zmymim0gfj

Haciendo hablar a Robonova

Tras la sesión de demostración de las practicas especiales que se llevó a cabo en semanas anteriores nos hemos dividido el trabajo para avanzar en dos direcciones. Por un lado se esta trabajando con los ultrasonidos (Ver entradas del blog publicadas por Eisen) y por otro lado se esta trabajando con el Coldfire para que el robot pueda hablar e ir comentando las cosas que va haciendo, como por ejemplo cuando mida una distancia con los ultrasonidos que diga el valor de la distancia a la que se encuentra del objeto.

Durante estos días se ha estado trabajando con el DAC (Convertidor digital-analógico) del Coldfire. Para poder reproducir audio con el Coldfire primero nos tenemos que generar un array en C que contenga las muestras de la señal y posteriormente ir recorriendo dicho array enviando las muestras al DAC, generando este una señal analógica que podremos escuchar si conectamos unos auriculares a la salida del DAC.

El siguiente código se encarga de recorrer el array “A” e ir enviando las muestras al DAC,

for(;i <>

DAC_dato(A[i]);

}

pero las manda a la máxima velocidad que permite, con lo cual tendremos que introducir un retardo para que la frecuencia de envió de las muestras del DAC corresponda con la frecuencia de muestreo de la señal (tipicamente en nuestro caso sera de 8000 Hz) para que se reproduzca correctamente, por ello el código quedara como sigue:

int i=0;

for(;i <>

DAC_dato(A[i]);

sleep(1); //Esperamos 1/8000 segundos

}

Se puede consultar el programa completo en C en la siguiente dirección: http://docs.google.com/Doc?id=dgs9sf7s_2gh37zr

Presentacion jueves 12

La presentación ha consistido en un pequeño ejemplo de control del robonova desde el coldfire. La forma de implementarlo ha consistido en utilizar el módulo radio tanto del robot como del coldfire para enviar instrucciones.
Las instrucciones mostradas consistían en un saludo, un paso hacia delante, otro hacia atrás, giros a ambos lados y la toma de medidas.
Esta última ha sido la instrucción más tediosa a la hora de implementarse, ya que exigía dos comandos, uno que indicase el deseo de realizar la medida, y otro que fijase el ultrasonido a utilizar. Posteriormente el coldfire imprimiría por pantalla la medida recibida. Para evitar o al menos detectar, los problemas de comunicación, se optó por la espera de la medida durante 4 segundos y de no ser recibida previo aviso se pasaría a la posición por defecto, en la que se puede realizar cualquiera de las instrucciones arriba definidas.
En los sucesivos días se ha cambiado la ubicación tanto de los módulos sonar, como del módulo radio del robot. Los sonar pasan a estar en los brazos, permitiendo realizar medidas omnidireccionales. Mientras que el modem pasa a estar en la espalda, intentando así corregir desequilibrios a la hora de caminar.
Los siguientes objetivos se centran en implementar la funcionalidad DAC del coldfire para que pueda reproducir voz así como en realizar un abanico de medidas gracias al cual el robot autónomamente pueda detectar donde está la pared más próxima.

30 de Marzo

El trabajo de hoy ha consistido íntegramente en intentar solucionar el problema que ya nos apareció el último día con la comunicación Coldfire – Robonova. Como ya comentamos, el ultimo día conseguimos la comunicación contraria, es decir, transmitiendo datos desde Robonova conseguíamos recibirlos en el Coldfire y mostrarlos por pantalla pero no en sentido contrario. Tras asegurarnos con el osciloscopio que transmitíamos exactamente los mismos datos en ambos sentidos y que en uno si funcionaba y en el otro no, comprobamos que no estuviera dañado ningún modulo radio.

Después de probar que usando el modulo que tiene el robot en la brazo como transmisor del Coldfire y el que tiene el Coldfire como receptor para el robot seguía sin funcionar, cambiamos los dos módulos por otros dos distintos, pero aun así seguía sin funcionar.

Tras varias pruebas similares sin éxito, se empezó a sospechar que el problema podía estar en la alimentación de los módulos, así que se alimento el circuito que contiene al MAX-3232 con una fuente de alimentación distinta a la del modulo radio, logrando, esta vez si, la tan deseada transmisión desde el Coldfire al Robonova consiguiendo de esta forma una comunicación bidireccional entre el Robonova y el Coldfire.

Una vez identificado el problema, durante el próximo día procederemos a filtrar la alimentación del circuito MAX-3232 con los correspondientes condensadores para intentar conseguir alimentar con una única fuente de alimentación el modulo radio y el circuito del MAX-3232.

26 de Marzo - Software

Durante la jornada de hoy se han desarrollado dos programas, uno escrito en C para el envió de comandos por el puerto RS232 del Coldfire y otro en lenguaje BASIC para la recepción de dichos comandos por el Robonova.
El programa en C para el Coldfire se estructura en tres partes:
La primera se encarga de leer las teclas pulsadas del teclado matricial

//------------------------------------------------------
// char teclado(void)
//
// Descripción:
// Explora el teclado matricial y devuelve la tecla
// pulsada
//------------------------------------------------------
char teclado(void)
{

BYTE fila, columna, fila_mask;
static char teclas[4][4] = {{"123C"},
{"456D"},
{"789E"},
{"A0BF"}};
// Bucle de exploración del teclado
while(TRUE){

// Excitamos una columna
for(columna = NUM_COLS - 1; columna >= 0; columna--){
set_puertoS(EXCIT << style="color: rgb(255, 255, 153);"> // Se envía la excitación de columna
retardo(1150); // Esperamos respuesta de optoacopladores

// Exploramos las filas en busca de respuesta
for(fila = NUM_COLS - 1; fila >= 0; fila--){
fila_mask = EXCIT << style="color: rgb(255, 255, 153);">// Máscara para leer el bit de la fila actual
if(lee_puertoE() & fila_mask){ // Si encuentra tecla pulsada,
while(lee_puertoE() & fila_mask); // Esperamos a que se suelte
retardo(1150); // Retardo antirrebotes
return teclas[fila][columna]; // Devolvemos la tecla pulsada
}
}
// Siguiente columna
}
// Exploración finalizada sin encontrar una tecla pulsada
}
// Reiniciamos exploración
}


La segunda escribe por la pantalla LCD la acción que va a ejecutar el robot

// Situamos el cursor en la posición adecuada
if(teclasEscritas++ >= MAX_TECLAS){ // Si hemos llenado una línea,
if(primeraLinea){ // Si era la línea 1,
LCD_inst(LIN_2LCD); // cambiamos a la línea 2
}else{ // Si no,
LCD_inst(CLR_DISP); // Limpiamos el display
LCD_inst(LIN_1LCD); // y volvemos a la línea 1
}
// Actualizamos variables de estado
primeraLinea = !primeraLinea;
teclasEscritas = 1;
}
LCD_dato(tecla); // Escribimos en el display la tecla pulsada


Y la última se encarga de enviar la tecla pulsada por el puerto RS232


/* ------------------------------------------------------------------------------
Metodo que se encarga de enviar por el puerto serie los datos pasados como
parametro
------------------------------------------------------------------------------- */
void enviaSerie(char* mensaje){
while(*mensaje){ //Mientras haya datos que enviar
//Comprobamos estado del puerto
BYTE estado_tx = mbar_readByte(MCFSIM_USR1);
estado_tx = estado_tx & 0x04;
if(estado_tx != 0x04) continue;
mbar_writeByte(MCFSIM_UTB1,*mensaje++); //enviamos
retardo(RET_3MS);
}
mbar_writeByte(MCFSIM_UTB1,0x0D);

}

El funcionamiento del programa consiste en un bucle que esta a la espera de que se pulse alguna tecla, cuando esto sucede se imprime por la pantalla LCD el mensaje que corresponda con la acción que va a realizar el robot y envía la tecla pulsada por el puerto RS232 del Coldfire volviendo de nuevo a su estado inicial esperando una nueva pulsación. (El código fuente completo de este programa estará disponible en unos días en la sección de programas)
Por otro lado el programa que controla al Robonova esta a la espera de recibir algún comando por el puerto serie del robot, cuando esto sucede identifica la tecla que se ha enviado y dependiendo de esta se ejecuta una acción u otra.

'Definimos teclas
adelante="2"
derecha="6"
izquierda="4"
medida="5"

'Comprobamos datos recibidos y ejecutamos
Retry: ERX 9600,datos,Retry
IF datos=adelante THEN
GOSUB Caminar
END

IF datos=derecha THEN
GOSUB Giro_dch
END

IF datos=izquierda THEN
GOSUB Giro_izq
END

IF datos=izquierda THEN
GOSUB Adquisicion_ultrasonidos
GOSUB envia_medida

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.