Capítulo 1 GUÍA DE MANEJO DEL DRIVER DE LA TCS 1 Introducción El presente documento tiene como objetivo describir cómo se maneja el driver que permite realizar programas en una PDA para controlar a la TCS. Un driver no es más que un objeto que tiene un conjunto de funciones que permiten manejar un dispositivo y un conjunto de variables que permiten monitorizar el estado del mismo, sin necesidad de conocer cómo está hecho. Lo único que se necesita conocer es el conjunto de funciones del driver que son interfaz con el usuario.

2 Nociones básicas del driver La clase que maneja la TCS se llama Comm y se encuentra declarada en el fichero Comm.h y definida en el fichero Comm.cpp. Esta clase necesita el driver del puerto serie para poder funcionar, que es el medio de comunicación que el PC o la PDA tiene con la TCS. Este driver se encuentra en los ficheros Serial.h y Serial.cpp.

Para entender el funcionamiento del driver es necesario entender qué es una comunicación entre el PC/PDA con la TCS. Una comunicación consiste de una petición de ejecución de comandos a la TCS y de una respuesta por parte de la TCS a esa petición; es decir, una comunicación implica el trasiego de dos flujos de datos: uno del PC/PDA a la TCS y otro en sentido contrario. Por ejemplo, una comunicación podría consistir en la petición a la TCS de la ejecución de dos comandos: que mueva los motores a una determinada velocidad y que le devuelva todas las medidas analógicas que tenga en ese momento; como contrapartida la TCS respondería con los valores de las medidas analógicas pedidas. Se pueden realizar tantas comunicaciones con la TCS como se quieran, de hecho el ejemplo anterior podría haberse llevado a cabo con dos comunicaciones en vez de con una, simplemente enviando un sólo comando en cada una de las comunicaciones. En cualquier caso, en este esquema de funcionamiento es la PDA la que actúa como maestro; es decir, toma la 1

iniciativa en las comunicaciones, y la TCS actúa como esclavo; es decir, responde a la PDA cuando esta se lo pide únicamente.

3 Variables y funciones del driver A continuación se describen las variables del driver que puede utilizar el programador cuando maneja el driver: •

interrupcion: vector de cuatro elementos que informa de los datos no esperados que se reciben en una comunicación con la TCS; es decir, es información que no se ha pedido a la TCS y que en cambio la TCS decide mandar para informar al robot de eventos que ocurren y que debe conocer. Estos eventos se llaman interrupciones, aunque no lo son propiamente, porque surgen sin esperarse de la misma forma que las interrupciones, lo que lleva a tener que programar líneas de código que atiendan estos eventos. Cada uno de los elementos del vector tiene dos posibles estados: 1 si hay interrupción y 0 si no la hay. Las posibles fuentes de interrupción son: o interrupcion[1]: información recibida por radiofrecuencia. El PC/PDA no sabe cuándo puede recibir información por radio. Por ello cuando la TCS recibe información por radio, se lo comunica a la PDA. Para la recepción de mensajes por radio se usa el elemento 1 del vector interrupcion. o interrupcion[2]: medidas de los ultrasonidos. Los sensores de ultrasonidos no pueden estar midiendo de continuo ya que el transductor se desgasta con el uso. Esto lleva a realizar medidas de forma no discriminada y bajo petición. Dado que un sensor de ultrasonido puede tardar hasta 20ms en hacer una medida (por lo tanto 8 sensores pueden tardar hasta 160 ms), no se puede permitir que cada vez que la PDA pida medidas de ultrasonido tenga que esperar a que se obtenga el dato ya que estaría perdiendo un tiempo en el cual podría estar haciendo otra cosa y le podría llevar a que el robot se chocara. Por ello, se ha optado por gestionar los ultrasonidos como una interrupción; es decir, en una comunicación con la TCS, la PDA pide que se hagan ciertas medidas de ultrasonido, pero no espera a que se hagan, sino que sigue realizando 2

comunicaciones para pedir otro tipo de medidas a la TCS o para actuar. Cuando la TCS ha terminado de hacer las medidas, introduce los resultados en una comunicación con la PDA sin que ésta sepa a priori en qué comunicación la TCS le va a enviar las medidas. Para los sensores de ultrasonido se usa el elemento 2 del vector interrupción. o interrupcion[3]: medidas de sensores digitales. Este tipo de sensores miden 0 o 1. Como sólo existen dos posibles estados este tipo de sensores ofrecen medidas muy estáticas ya que cambian poco en el tiempo. Para evitar trasiego de información innecesaria en la comunicación entre el PC/PDA y la TCS, la TCS enviará a la PDA las medidas de los sensores digitales cuando alguno de estos cambie de estado. Por ejemplo, este tipo de sensores se suele usar para saber si el robot se ha chocado; en ese caso la TCS informará al robot sólo cuando se acabe de chocar o cuando deje de hacerlo. Para los sensores digitales se usa el elemento 3 del vector interrupcion. •

compruebaPing: variable de dos estados que indica si al mandar el comando “ping” (comando que se usa comúnmente en comunicaciones para determinar si un dispositivo está vivo: ¿estas ahí?) a la TCS, éste ha respondido. A veces se usa para establecer una comunicación con la TCS, únicamente para saber si existe algún evento que deba ser recibido; ya que como se comentó en la sección 2 la TCS sólo puede mandar eventos si la PDA a tomado la iniciativa de abrir una comunicación.

•

RFrespuesta: variable de dos estados que indica si el último mensaje de radiofrecuencia

espera

una

respuesta

(RFrespuesta==1)

o

no

(RFrespuesta==0).

A continuación se describen las funciones del driver que permiten controlar y establecer una comunicación entre la PDA y la TCS: 1. inicio(): función que se debe llamar al principio de cualquier comunicación entre la PDA y la TCS. 2. comunica(): establece la comunicación de la PDA con la TCS, enviando todas las ordenes a la TCS y recibiendo la respuesta de la misma. En caso de que surja algún problema durante la comunicación devolverá un 0 y sino un 1.

3

A continuación se describen las funciones interfaz del driver que permiten enviar ordenes para manejar la TCS: 1. configuracion(número de ADs, número de USs): función que indica a la TCS cómo se configuran los pines de conexión con el exterior en función del número de sensores de cada tipo que se le manden en esta función. 2. leerAD(sensor): función que pide la medida de un sensor analógico que se manda como parámetro. El parámetro sensor va de 1 hasta el número de sensores analógicos que se hayan configurado. 3. leerADs(): función que pide todas las medidas de los sensores analógicos que se hayan configurado. 4. pedirUS(sensor): función que pide la medida de un sensor de ultrasonido que se manda como parámetro. El parámetro sensor va de 1 hasta el número de sensores de ultrasonidos que se hayan configurado. 5. pedirUSs(): función que pide todas las medidas de los sensores de ultrasonido que se hayan configurado. 6. activarMotores(Byte de configuración): activa los motores. Si el byte de configuración es 1 se activa el motor 1, si es 2 se activa el motor 0 y si es 3 se activan los dos motores. Para que un motor se ponga en funcionamiento es necesario haberlo activado. 7. periodoMotores(Periodo): indica a la TCS el periodo de la señal

PWM que va a utilizar para controlar los motores. El parámetro tiene que ser un número que esté comprendido entre 70 y 255. Cuanto mayor sea el valor, mayor será el periodo. 8. periodoServos(Periodo): indica a la TCS el periodo de la señal PWM que va a utilizar para controlar los servos. Como los servos se controlan siempre a 50Hz, el valor del parámetro afecta poco al comportamiento del servo, ya que es un ajuste fino de la frecuencia entorno a 50Hz. Tiene que ser un número que esté comprendido entre 0 y 255; por ejemplo 200. 9. DcMotores(Dc motor1, Dc motor0): fija el valor de los anchos del

pulso de la señales PWM que controlan los motores 0 y 1. Variando el ancho del pulso del PWM se puede variar la velocidad de los motores. El parámetro tiene que ser un número que esté comprendido entre 0 y el valor del periodo de 4

control de los motores. En concreto el valor en el que se encuentra parado el motor es cuando coincide con la mitad del periodo de control de los motores (por ejemplo 100 en caso de que el periodo sea 200); el valor en que el motor gira a la máxima velocidad en sentido negativo es 0; el valor en el que el motor gira a la máxima velocidad en sentido positivo es el que coincide con el valor del periodo de control; y valores intermedios hacen que el motor se mueva a una velocidad que se puede obtener interpolando entre los valores anteriormente citados. 10. DcServos(Dc servo1, Dc servo0): fija el valor de los anchos del pulso de la señales PWM que controlan los servos 0 y 1. Variando el ancho del pulso se puede variar el ángulo de giro de cada servo. El valor del ancho del pulso puede variar entre 50 y 240. Un valor de 50 hace que el servo se encuentre posicionado a -90º, en cambio un valor de 240 hace que el servo se encuentre posicionado a 90º. Valores intermedios hacen que el servo se posicione en un ángulo que se puede obtener interpolando entre los valores anteriormente citados. 11.

Ping(): función que sirve para determinar si la TCS se encuentra en

funcionamiento y que existe comunicación entre la PDA y la TCS. 12. escribeRadio(longitud_mensaje,

mensaje,

espera_respuesta):

función que indica a la TCS que tiene que enviar un mensaje por radio. El parámetro longitud_mensaje indica el número de bytes que se quieren transmitir, el parámetro mensaje representa el mensaje a transmitir y el parámetro espera_respuesta indica si la PDA espera una respuesta de aquel a quien envía el mensaje. Funciones para leer las medidas de los sensores: 1. valorADs(): devuelve un vector de 10 elementos (10 bytes) con todas las medida analógicas que ha devuelto la TCS. 2. valorEncoders(): devuelve un vector de 4 elementos (4 bytes) con las medidas de los encoders. El primer byte es la parte menos significativa de la medida del encoder 0, el segundo byte es la parte más significativa del encoder 0, el tercer byte es la medida menos significativa del encoder 1 y el cuarto byte es la medida más significativa del encoder 1.

5

3. valorUSs(): devuelve un vector de 8 elementos (8 bytes) con todas las medidas de ultrasonido que se han pedido a la TCS. 4. valorDig(): devuelve un vector de 1 elemento (1 byte) con la medida de los ocho sensores digitales. Cada bit del elemento se corresponde con la medida de un sensor. 5. valorRF(nElementos): devuelve un vector de nElementos elementos con el mensaje que la TCS ha recibido por radio.

4 Instrucciones de manejo del objeto Comm A continuación se detallan las instrucciones para el manejo del driver desde una aplicación programada en C++, que será la que se ejecute en un PC o en una PDA. 4.1 Creación de objeto El primer paso es añadir los siguientes archivos al proyecto donde se va a realizar la aplicación deseada: •

Comm.h: Definición de la clase Comm, encargada de la comunicación.

•

Comm.cpp: Código de la clase Comm.

•

Serial.h: Definición de la clase Serial, encargada del manejo del puerto serie.

•

Serial.cpp: Código de la clase Serial.

Una vez añadidos, en el archivo del proyecto donde se vaya a crear el objeto de la clase Comm se introduce el código correspondiente, habiendo incluido anteriormente la cabecera Comm.h: #include “Comm.h” … Comm comunicacion; …

De esta manera se ha creado el objeto comunicacion con el que se podrán establecer comunicaciones con la TCS. 4.2 Inicialización de la comunicación Antes de establecer una nueva comunicación lo primero que hay que hacer es llamar a al método inicio() del objeto Comm: comunicacion.inicio();

6

Este método tiene como función vaciar el buffer de datos de envío. En caso de que no se ejecutara, al introducir las órdenes para la TCS, éstas se irían colocando tras las órdenes solicitadas en la comunicación anterior. 4.3 Introducción de las órdenes a enviar Una vez que se ha inicializado la comunicación, es necesario introducir las órdenes que se quieren mandar al microcontrolador. Para ello, tan sólo se tienen que ejecutar las funciones o métodos de la sección 3 que se encargan de mandar actuaciones o de pedir medidas. A la hora de ejecutar dichos métodos se debe tener en cuenta los siguientes aspectos: •

En la primera comunicación con la TCS se debe configurar, enviando la orden configuracion que le indica el número de sensores de cada tipo que se van a utilizar. Si por ejemplo, se quiere usar sólo el sensor de ultrasonidos 3, se debe configurar el número de ultrasonidos al menos a 3, aunque el 2 y el 1 no se usen. Lo mismo sucede para los sensores analógicos.

•

En caso de que en la misma comunicación se envíe la orden de configuracion y además alguna otra orden para pedir la medida de sensores analógicos o ultrasonidos, siempre se deberá introducir primero la orden de configuracion, ya que si no, cuando en la TCS vaya a realizar las medidas no estará configurada de la forma adecuada.

•

En las funciones leerAD(sensor) y pedirUS(sensor), se debe tener en cuenta que el primer sensor se pide con un 1 y el último con el número de sensores totales configurados (no como los vectores en C++, que usan los índices que van de 0 al número de elementos – 1).

•

Si se solicita una medida de ultrasonidos antes de haber recibido la respuesta con medidas de una petición anterior, ésta se sobrescribe y no se sigue esperando.

•

Si no se han activado nunca los motores, es aconsejable que no se envíe solamente la orden activarMotores en una comunicación, sino que se acompañe con las órdenes que configuran el periodo de control y los la velocidad (duty cycle) de los mismos. De esta manera se evita que al activar los motores, se pongan en marcha de forma no controlada.

7

•

Cuando se envíen los parámetros de actuación a los servos (fundamentalmente el ángulo de giro, duty cycle), se deben tener en cuenta los límites de estos para no dañarlos: dc mínimo 50 (-90º) y dc máximo 240 (90º).

•

Al enviar un mensaje para la radiofrecuencia, se debe tener en cuenta que mensajes de excesiva longitud (mayor de 30 bytes) pueden presentar problemas a la hora de ser enviados.

Un ejemplo a la hora de introducir las órdenes: ... comunicacion.inicio();

//se reinicia la comunicación

comunicacion.configuracion(5,4);

//se

introduce

una

nueva

configuración

en

los sensores, 5 ADs y 4 USs comunicacion.leerAD(4);

// se solicita el 4º sensor analógico

comunicacion.pedirUSs();

// se pide un barrido de todos los US

comunicacion.periodoMotores(200);

// el periodo de los motores a 200

comunicacion.DcMotores(100,100);

// ambos Dc a 100 (motores parados)

comunicacion.activarMotores(3);

// los dos motores activados

...

4.4 Envío y Recepción Para enviar el vector con las órdenes para el microcontrolador, se llama al método comunica. Este método envía las órdenes y no devuelve el control hasta que no recibe la respuesta y la procesa. En caso de que se produjeran errores durante la comunicación, esta función devolvería un 0. Por ello, sería recomendable que al método se le llamase desde dentro de un if, y si fallase se pusiera de manifiesto al usuario: if(!comunicacion.comunica())

//si devuelve 0 en caso de error

MessageBox(_T("Error en la comunicación"));

Sólo se produce una comunicación si hay órdenes a ejecutar; es decir, que: comunicacion.inicio(); comunicacion.comunica();

no realiza ninguna comunicación. 4.5 Lectura de las medidas Existen tres tipos de medidas: las que se solicitan en una comunicación y se reciben en la propia respuesta (analógicas y encoders); las que se solicitan en una comunicación y, debido al tiempo que se tarda en realizarlas, no se reciben en la propia respuesta sino en 8

la respuesta de una o varias comunicaciones posteriores (ultrasonidos); y las que se reciben sin ni siquiera haber sido solicitadas con anterioridad (digitales y radiofrecuencia). En el caso de las primeras, no existe problema, pues la aplicación principal tratará de leerlas sólo cuando las haya solicitado primero. Para los otros dos tipos se deberá consultar el vector interrupcion de forma periódica en el que se indica, con un 1 (sí) o un 0 (no), si en la última comunicación se ha recibido alguna de estas medidas no esperadas. Cada elemento del vector se refiere a: •

interrupcion[1]: si se ha recibido o no un mensaje procedente de la radio.

•

interrupcion[2]: si se ha recibido la medida o medidas de ultrasonidos solicitadas anteriormente.

•

interrupcion[3]: si se ha producido un cambio en el estado de los sensores digitales.

Lo lógico sería que cada vez que se realice una comunicación se comprobara si se ha recibido un nuevo mensaje de la radiofrecuencia o si ha habido cambios en el estado de los sensores digitales. Y, en caso de que se hubiese pedido anteriormente los ultrasonidos, comprobar también si estos se han recibido. Hay que tener en cuenta que el vector interrupcion pondrá a 1 el elemento correspondiente solamente en el momento que se recibe dicha respuesta no esperada, volviendo a ponerse a 0 en la siguiente comunicación. Una vez que se sabe qué medidas se deben leer, la forma de hacerlo es la siguiente. Se crea un puntero constante de tipo BYTE, y éste se iguala a la función de petición de medidas correspondiente (ver sección 3). Un ejemplo de lectura de medidas, suponiendo que anteriormente se ha pedido un barrido de los sensores de ultrasonidos: int elemRadio; const

BYTE

// indica el número de elementos que devuelve la radio

*vectorADs,

*vectorEncoders,

*vectorRadio,

*vectorUSs,

*digit;

//

definición de variables para el manejo de valores entregados por el driver

vectorADs

=

comunicacion.valorADs();

//el

valor

de

los

ADs

se

guarda

vectorADs, que será un const BYTE* vectorEncoders = comunicacion.valorEncoders(); //similar a la función anterior if(comunicacion.interrupcion[1])

//si 1, se ha recibido mensaje de RF

9

en

vectorRadio = comunicacion.valorRF(&elemRadio); //en el caso de la radio se pasa un puntero donde

dejará

el

número

de

elementos

que

tiene el mensaje if(comunicacion.interrupcion[2])

//si 1, se han recibido los USs

vectorUSs = comunicacion.valorUSs(); //se pasa las medidas a vectorUSs if(comunicacion.interrupcion[3])

//si 1, ha habido cambios en digitales

digit = comunicacion.valorDig(); //se pasa el estado a digit ...

Además, en el caso de la radio se debe tener otro factor en cuenta. Los envíos recibidos desde la radiofrecuencia pueden esperar una respuesta de la PDA hacia el que envió el mensaje. La forma de saberlo es a través de la variable RFrespuesta, que tendrá valor 1 si espera respuesta y 0 en caso contrario. if(interrupcion[1]) {

//si 1, se ha recibido mensaje de RF

vectorRadio = comunicacion.valorRF(&elemRadio); if (RFrespuesta

== 1)

// aquí el código para responder }

Por otra parte, para saber si la TCS está funcionando y existe comunicación entre la PDA y la TCS se puede usar la función Ping. En caso de que exista comunicación la variable compruebaPing se pone a 1 y en caso contrario a 0. comunicacion.inicio();

//se reinicia la comunicación

comunicacion.Ping(); if (comunicacion.comunica()){ if (comunicacion.compruebaPing) MessageBox(_T("Comunicación OK. La TCS está viva"),_T("Aviso"),MB_OK); else MessageBox(_T("Error de

comunicación"),_T("Error"),MB_OK);

}

4.6 Problemas que pueden surgir •

Al pedir ultrasonidos y esperar la respuesta el programa deja de responder. En ocasiones pudiera ocurrir que alguna comunicación fallase, o que la TCS no entendiese la orden de realizar la lectura de los ultrasonidos. Si esto ocurre, teniendo la aplicación programada para no continuar hasta recibir la medida, 10

podría quedarse colgado el programa ya que la TCS nunca responderá. La solución de este problema consiste en reprogramar la aplicación indicando que si en diez comunicaciones (número orientativo) no se ha recibido la medida se volviese a pedir. •

Al crear el objeto Comm salta el mensaje “No se puede abrir el puerto”. Si no se puede abrir el puerto serie es debido a que hay otro programa usándolo. Cerrando dicho programa se solucionaría el problema. Si no se puede cerrar o no hay ningún programa abierto la solución será resetear la PDA (botón de reset situado en la parte inferior o trasera).

•

No se puede establecer la comunicación. Normalmente esto es debido a que la última vez que se utilizó la comunicación serie, el puerto se cerró mal, o a que hay algún problema en la TCS. En tal caso se debe resetear la PDA y la TCS.

4.7 Ejemplo de uso Suponemos que se tiene un robot con las siguientes características: •

El robot cuenta con dos motores situados en sus ruedas traseras.

•

La navegación se quiere controlar por medio de tres sensores de ultrasonidos.

•

También tiene el robot dos sensores de infrarrojos (analógicos) situados en un costado, para poder controlar la distancia a la pared.

•

Además el robot cuenta con tres sensores digitales (lógica negada) que le advierten en caso de contacto.

•

También se quiere llevar un control de la posición, y esto se realiza por medio de dos encoders situados en cada una de las ruedas motoras.

En una primera comunicación se deberían pasar los parámetros de configuración de la plataforma: el número de sensores, tanto de ultrasonidos como analógicos; y la configuración inicial de los motores, es decir, activarlos pero que se encuentren parados. Ésta primera comunicación quedaría: // definición de variables globales BYTE Dc1=0, Dc2=0;

// Primera comunicación con el robot, donde se activan los motores, se configuran el número de sensores analógicos y de ultrasonidos. comunicacion.inicio();

// se reinicia las colas Rx y Tx

comunicacion.configuracion(2,3);

// 3 sensores US y 2 sensores AD

comunicacion.periodoMotores(200);

// se pone un periodo de 200

11

comunicacion.DcMotores(100,100);

// inicialmente parados

comunicacion.activarMotores(3);

// se activan los dos motores

comunicacion.comunica();

// se pasan los parámetros al PIC

En el funcionamiento normal del robot, la función periódica a ejecutar cuando el robot esté activo podría ser: // definición de variables locales const BYTE *Digitales, *USs, *ADs, *Encoders;

comunicacion.inicio();

// se reinician las colas Tx y Rx

comunicacion.pedirUSs();

// se pide el barrido de los tres USs

comunicacion.comunica();

//

se

comunica,

sabiendo

que

los

USs

no

pueden llegar en la propia comunicación // Se inicia un bucle hasta que se reciben las medidas de los ultrasonidos, o bien se recibe un cambio en los digitales. En el bucle se está continuamente pidiendo los encoders y los ADs, para que cuando se salga del mismo estos no estén desfasados respecto a los USs. int i = 0;

//

se

establece

un

contador

para

que

no

se

quedara

infinitamente en el bucle si hubiera algún problema en la comunicación y no se recibiesen nunca los USs while(comunicacion.interrupcion[3]!=1 && comunicacion.interrupcion[2]!=1 && i < 10) { i++; comunicacion.inicio();

// se reinician las colas

comunicacion.leerEncoders(); // petición de los Encoders comunicacion.leerADs();

// petición de los ADs

comunicacion.comunica(); } if(comunicacion.interrupcion[3] == 1)

// si hubo cambio en digitales

{ Digitales = comunicacion.valorDig(); // se toma el valor de los sensores digitales if (Digitales[0] < 15) { // ha habido choque y paro el robot por ejemplo Dc1 = 100; Dc2 = 100; } } else if(comunicacion.interrupcion[2] == 1)

// si hubo medida de los US

{ USs = comunicacion.valorUSs();

// se guardan las medidas de los USs

ADs = comunicacion.valorADs();

// se guardan las medidas de los ADs

Encoders

=

comunicacion.valorEncoders();//

Encoders

12

se

guardan

las

medidas

de

// lógica de control en función de las medidas. Por ejemplo una sencilla if (USs[0] < 20 || USs[1] < 20) { // gira en un sentido Dc1 = 100; Dc2 = 0; } else if (USs[1] < 20) { // gira en otro Dc1 = 0; Dc2 = 100; }

} comunicacion.inicio(); comunicacion.DcMotores(Dc1,Dc2); comunicacion.comunica(); //

se

volvería

a

enlazar

con

el

principio,

bien

siendo

esto

una

función

que

la

volverían a llamar, o dentro de un bucle, etc.

Este es un modelo de comunicación, pero se podrán idear multitud de ellos. Es necesario darse cuenta de la ineficiencia de este código, ya que precisa de tres comunicaciones al menos por cada ciclo de control: una para pedir los ultrasonidos, otra para recoger las medidas y otra para actuar. Si en el control no intervinieran los sensores de ultrasonidos, el modelo sería muy distinto.

13