3.1....

CAPÍTULO 3

SOFTWARE

3.1. Software de control para el vehículo autobalanceado

El funcionamiento del vehículo autobalanceado se basará en la ejecución de unprograma cargado en la memoria del microcontrolador del sistema principal. Dichoprograma se encargará de gestionar las entradas de información al microcontroladory de generar las salidas adecuadas para el correcto funcionamiento.

El microcontrolador Atmega128 presenta una arquitectura basada en RISC. Losprogramas para estos microcontroladores pueden escribirse en lenguaje ensamblador(lenguaje de bajo nivel), a través de lenguajes de alto nivel como C o BASIC, o me-diante el uso de sistemas operativos para sistemas embebidos.

El uso de lenguaje ensamblador, a pesar de poder generar programas más eficien-tes enmemoria y tiempo de ejecución, implica una mayor dificultad de programación,un tiempo muy elevado en el diseño del programa y la generación de un código queno es portable. Mediante un proceso de ensamblado se crearía el código máquina conlas instrucciones RISC a partir del lenguaje de programación.

Frente a la dificultad técnica de programar en lenguaje ensamblador se presenta laopción de la programación a mas alto nivel en lenguajes como C o BASIC. Se trata deun lenguaje de programación con un nivel de abstracción más elevado que medianteun compilador permite crear el código máquina que puede ejecutar el microcontrola-dor.

A un nivel de abstracción por encima de los programas más simples en estos len-guajes, se presentan los sistemas operativos con compilación cruzada. Estos sistemasoperativos están creados en los mismos lenguajes de programación, pero se compo-nen de diferentes módulos que pueden ser utilizados por el programador para, juntocon los módulos propios, generar programas.35

3. SOFTWARE

Para la programación del vehículo autobalanceado se va a utilizar el sistema ope-rativo TinyOS. Se trata de un sistema operativo desarrollado en la Universidad deBerkeley para la construcción de aplicaciones en sistemas embebidos y especialmentepara redes de sensores inalámbricas.

A través de TinyOS se generará un programa en el que de manera periódica seleerán los valores de inclinación y velocidad del vehículo, y se calculará la actuaciónnecesaria sobre los motores para lograr el equilibrio del sistema en la posición vertical.Además de estas tareas periódicas, el sistema operativo permite gestionar el uso deeventos o interrupciones que facilitan la implementación de las comunicaciones entredispositivos y otro tipo de tareas no periódicas. El sistema operativo permite tambiéngestionar las prioridades entre tareas.

La plataforma Atmega128 es una de las soportadas por TinyOS ya que éste micro-controlador se encuentra presente en una amplia gama de sensores para redes inalám-bricas.

El programa del vehículo realizará también tareas de seguridad (como por ejem-plo, paradas de emergencia), interacción con el usuario (le mostrará información ypermitirá recoger consignas de funcionamiento) y se encargará de comunicacionescon el sistema de control de bajo nivel de los motores y con un PC para intercambiode datos.

3.1.1. Características de TinyOS

Como se ha comentado anteriormente, TinyOS es un sistema operativo de códigoabierto diseñado para redes de sensores inalámbricos embebidos. Está desarrolladopor un consorcio liderado por la Universidad de California en Berkeley en coopera-ción con Intel Research.

Este sistema operativo ofrece una arquitectura basada en componentes que per-mite realizar rápidas implementaciones minimizando el tamaño del código como re-quieren las restricción de memoria propias del tipo de procesadores a los que va di-rigido. Las librerías de componentes de TinyOS incluyen protocolos de red, serviciosdistribuidos, redes de sensores y herramientas de adquisición de datos. Todos esoscomponentes pueden usarse tal cual o ser modificados para una aplicación concreta.

TinyOS soporta un amplio rango de plataformas hardware y características paraplacas de sensores concretas. La existencia de una gran comunidad que usa y desa-rrolla algoritmos y aplicaciones de protocolos que se introducen en TinyOS hace quenumerosos grupos de investigación y compañías se unan a él desarrollando inclusoestándares y ampliando sus librerías.36

3.1. SOFTWARE DE CONTROL PARA EL VEHÍCULO AUTOBALANCEADO

La versión de TinyOS usada para el desarrollo del software del vehículo autoba-lanceado es la 1.1.0.

Este sistema operativo está escrito en el lenguaje de programación nesC como unconjunto de tareas y procesos que colaboran entre sí. Las aplicaciones también se es-criben en nesC, que es un meta-lenguaje que deriva del C y que está optimizado paralas limitaciones de memoria de los dispositivos a los que va destinado. Existen otraherramientas para facilitar el uso de TinyOS que están escritas en su mayoría en Javay en Bash (intérprete de órdenes Unix). Otras herramientas y librerías asociadas estánescritas principalmente en C.

Para generar un programa en TinyOS se realiza una compilación cruzada entre elcódigo de la aplicación (nesC), el kernel de TinyOS (C) y las librerías de TinyOS (nesC)mediante un compilador de nesC. El resultado es un programa conjunto de aplicacióny TinyOS en C que se vuelve a compilar con un compilador de C para generar laaplicación ejecutable por el dispositivo.

TinyOS proporciona interfaces, módulos y configuraciones específicas, que permi-ten a los programadores construir programas como un conjunto de módulos que ha-cen tareas específicas. Los módulos de TinyOS proporcionan interfaces para los tiposestándar de entradas y salidas de hardware y sensores.

El diseño del Kernel de TinyOS está basado en una estructura de dos niveles deplanificación:

Eventos: Pensados para realizar un proceso pequeño (por ejemplo, para aten-der la interrupción de un contador o timer, o la interrupción de un conversoranalógico-digital). Los eventos pueden interrumpir la ejecución de una tarea.

Tareas: Están pensadas para realizar una cantidad mayor de procesado y no soncríticas en tiempo (por ejemplo, el cálculo de la media de un conjunto de datos).Las tareas se dividen en dos estados, la solicitud de ejecución de una tarea y lapropia ejecución de la misma. Un comando solicita la tarea y el hilo de control esdevuelto. La ejecución de la tarea queda en manos del planificador que una vezejecutada señalará el éxito de la misma a través de un evento. Esto es algo típicode la programación orientada a componentes.

Con este diseño se está permitiendo a los eventos (de ejecución rápida) tener prio-ridad de ejecución, pudiendo interrumpir la ejecución de una tarea (de ejecución máscompleja que los eventos generalmente). La tarea se pone en cola en segundo planorecuperándose en el momento en que no hay otro proceso de prioridad superior. 37

3. SOFTWARE

3.1.2. NesC

NesC es un meta-lenguaje de programación basado en C, orientado a sistemasembebidos que incorporan manejo de red. Soporta un modelo de programación queintegra el manejo de comunicaciones, las concurrencias que provocan tareas y eventos,y la capacidad de reaccionar frente a sucesos que puedan ocurrir en el ambiente quese desempeña (por ejemplo, la lectura de un sensor).

Los conceptos básicos acerca de nesC son:

Separación entre la construcción y la composición: Los programas están cons-truidos a partir de componentes, que son conectados ("wired") para formar pro-gramas completos. Los componentes se dividen en dos ámbitos, uno para susespecificaciones (conteniendo el nombre de las instancias o interfaz) y otro parala implementación (módulos). Los componentes presentan concurrencia interna amodo de tareas. El hilo de control debe llegar a los componentes a través de susinterfaces. Esos hilos parten de una tarea o de una interrupción hardware.

La especificación del componente se realiza a través de interfaces. Las interfacespueden ser proporcionadas o usadas por el componente. La interfaz proporcio-nada especifica la funcionalidad que el componente ofrece al usuario, mientrasque la interfaz usada representa la funcionalidad que el componente necesitapara realizar su trabajo.

Interfaces bidireccionales: Especifican un conjunto de funciones implementadaspor el proveedor de la interfaz (comandos) y un conjunto de funciones a imple-mentar por el usuario de la interfaz (eventos). Esto permite una interacción com-pleja entre componentes a través de una misma interfaz (por ejemplo, se puedemanifestar el interés en un evento y seguidamente incluir la función a realizarcuando el evento ocurra). Esto es crítico porque todos los comandos largos enTinyOS (por ejemplo, send packet) no bloquean la ejecución; su finalización seseñala a través de un evento (send done). Especificando las interfaces, un com-ponente no puede llamar al comando send a menos que proporcione una imple-mentación para el evento sendDone. Normalmente los comandos realizan llama-das hacia abajo, es decir, de los componentes de aplicación hacia los cercanos alhardware, mientras que los eventos realizan llamadas hacia arriba.

Los componentes están unidos estáticamente unos a otros a través de sus interfa-ces. Esto aumenta la eficiencia en tiempo de ejecución, fomenta el diseño robustoy permite un mejor análisis del programa sin ejecutarlo.38


NesC está diseñado bajo la hipótesis de que el código está generado para sucompilación con el programa completo. Esto permite un mejor análisis del códi-go por ejemplo pudiéndose detectar condiciones de carrera en datos durante lacompilación.

La conexión entre componentes se realiza de manera jerárquica. En la Fig. 3.1 semuestra un ejemplo de estructura jerárquica entre componentes conectados.

Figura 3.1: Estructura jerárquica de conexión entre componentes.

En el modelo de concurrencia de nesC tendremos tareas que se ejecutarán de ma-nera completa y un manejador de interrupciones que son comunicadas de maneraasíncrona por el hardware. El sistema organiza la ejecución de tareas de manera or-denada, pero pueden ser interrumpidas por los eventos externos. En los eventos sedebe guardar el estado del sistema y lanzar una tarea para que no sea bloqueante. Laexistencia de la sentencia atomic permite la ejecución de fragmentos de código comounidad inseparable.

El código nesC se puede dividir en tres tipos diferentes de ficheros: interfaz, mó-dulo y configuración.

3.1.2.1. Interfaz

Define los métodos públicos que un componente puede usar. Especifica los coman-dos que se pueden llamar y los eventos que deben ser implementados por quien utilicela interfaz. 39

3. SOFTWARE

La interfaz se suele utilizar para agrupar funcionalidades del sistema o de algúnperiférico. Por ejemplo una interfaz de control estándar agrupa las funcionalidades deinicialización, inicio y parada de la ejecución del proceso (init, start, stop).

Los comandos, o funciones que el proveedor implementa y ofrece al usuario,reúnen las siguientes características:

Deposita los parámetros requeridos en el bloque de datos (frame) del componen-te.

No bloquea la ejecución.

Necesita devolver el estado. Pospone el consumo de tiempo de trabajo solicitan-do la ejecución de una tarea.

Puede llamar a comandos de nivel inferior.

Los eventos, como funciones que deben ser implementadas por el usuario de lainterfaz, tienen las siguientes características:

Pueden llamar a comandos, comunicar eventos y solicitar la ejecución de tareas,pero no pueden ser comunicados por los comandos.

Inician tareas, pero no pueden ser iniciados por éstas.

Interrumpe el disparo de eventos de nivel inferior.

Deposita la información en el bloque de datos (frame).

A continuación se muestra un ejemplo de interfaz.

i n t e r f a c e Timer {/ / t y p e i s : TIMER_ONE_SHOT/ / or TIMER_REPEATcommand r e su l t _ t s t a r t ( char type , u in t32_ t period ) ;command r e su l t _ t stop ( ) ;event r e s u l t _ t f i r ed ( ) ;

}40


3.1.2.2. Módulo

Es donde se implementa la interfaz, es decir, es donde se escribe el código de loscomandos asociados a la interfaz.

La estructura que presenta el módulo responde a:

module identificador especificación implementación

El nombre del componente viene especificado por identificador. Este identificadores global y pertenece al espacio de nombres de componentes e interfaces.

Un componente presenta siempre dos campos: un campo de especificación, asociadoal ámbito global de la aplicación, y un campo de implementación asociado al campo deespecificación.

Un componente puede incluir archivos C opcionalmente a través de una lista deincludes.

La lista de especificación enumera los elementos usados (used) o proporcionados(provided) por el componente. Un hilo de control del programa cruzará los componen-tes a través de su lista de especificaciones.

El nombre de los elementos en la lista de especificación pertenece al espacio denombres de cada componente, por lo que se pueden renombrar elementos para su usoen el ámbito del componente.

El campo de implementación está formado por declaraciones y definiciones en C.Se compone de un bloque de datos (frame), tareas e interfaz (eventos y comandos).Alguna de estas partes puede estar vacía.

En el frame es dónde se almacena el estado interno del módulo, es decir, es la zonaque recoge todas las variables del mismo. Hay un solo bloque de este tipo por módulo,tiene un tamaño fijo y tiene colocación fija en la memoria.

Las tareas realizan las procesos de computación del módulo.

La parte de la interfaz incluye la implementación de los comandos y las tareasasociadas al módulo.

A continuación se incluye un ejemplo demódulo en el que semuestran las distintaspartes que lo componen:

module NombreModulo{provides {

i n t e r f a c e StdControl ; 41

3. SOFTWARE

} uses {i n t e r f a c e Timer ;i n t e r f a c e Otra In te r faz ;

}}implementation {# include " Constantes . h"

in t x ; / / v a r i a b l e en e l b l o qu e de d a t o s

task void procesado ( ) { / / t a r e a a r e a l i z a r}

command r e su l t _ t StdContol . s t a r t ( ) {c a l l Timer . s t a r t (TIMER_R , 1000 ) ;return SUCCESS ;

}

event r e s u l t _ t Timer . f i r ed ( ) {post procesado ( ) ;

}}

3.1.2.3. Configuración

Es el archivo en el que se especifica la unión de componentes, es decir, se dice quéinterfaces se van a utilizan, por quién se van a utilizar y quién las implementa.

Una aplicación debe tener un componente principal o Main que se conecte a otroscomponentes. De esta forma una aplicación será un conjunto de componentes interco-nectados entre ellos.

Los componentes conectados deben ser compatibles en su contenido. Es decir, loscomponentes deben ser compatibles interfaz a interfaz, comando a comando y eventoa evento.

La estructura de una configuración responde a:

configuration identificador especificación implementación

El identificador es el nombre de la configuración, suele coincidir con el nombre del42


fichero contiene a la configuración. Al igual que con el módulo, la configuración poseedos campos, uno de especificación y otro de implementación.

El campo de especificación lista los interfaces proporcionados (provided) o usados(used) por el componente.

El campo de implementación consta de una lista de componentes donde se enumeranlos componentes que son usados para construir la configuración, y una lista de conexio-nes donde se muestran qué componentes están conectados o cableados (wired) unos aotros para especificar la configuración.

El nombre de los componentes pertenece al ámbito de la implementación. Los com-ponentes listados se pueden renombrar para su utilización en la implementación. Elformato de la lista de componentes es el siguiente:

components identif1, identif2, identif3 as nuevoIdentif;

La conexión de elementos (interfaces, comandos, eventos) unos a otros se denomi-na cableado (wiring). A los elementos de una conexión se les llama terminales (end-point). Existen tres sentencias de conexión:

terminal1 = terminal2

terminal1 ->terminal2

terminal2 <- terminal1

La primera de las sentencias establece una equivalencia entre los dos componentes,mientras que las otras dos, que son equivalentes entre sí, conectan un elemento usedespecificado por terminal1 a uno provided especificado por terminal2.

A continuación se muestra un ejemplo de configuración.

con f igura t ion TimerC {provides i n t e r f a c e Timer [ u in t8_ t id ] ;provides i n t e r f a c e StdControl ;

}implementation {

components TimerM , ClockC , NoLeds , HPLPowerManagementM;TimerM . Leds −> NoLeds ;TimerM . Clock −> ClockC ;TimerM . PowerManagement −> HPLPowerManagementM;StdControl = TimerM ; 43

3. SOFTWARE

Timer = TimerM ;}

Se podrá asignar un puerto a una interfaz, de manera que un proveedor puede dis-tinguir a distintos usuarios. Esto se usa porque el componente no puede saber cuántosusuarios se conectan a él de manera concurrente. A continuación se muestra un ejem-plo de utilización de una interfaz a través de un puerto.

con f igura t ion SenseLightC {}implementation {

components Main , SendLightM , TimerC ;Main . StdControl −> SendLightM . StdControl ;Main . StdControl −> TimerC ;SendLightM . Timer −> TimerC . Timer [ unique ( " Timer " ) ] ;

}

Para mayor profundización en los conceptos y en la sintaxis de nesC se puedeconsultar un manual de referencia a este lenguaje en [5].

3.1.3. Instalación de TinyOS

TinyOS fue desarrollado inicialmente sobre BSD (Unix), por lo cual para su funcio-namiento enWindows es necesaria la instalación deCygwin, un simulador de platafor-mas unix, siendo necesarios también conocimientos básicos de éste entorno. Además,muchas de las herramientas disponibles se encuentran desarrolladas para plataformasJAVA, por lo que también es necesaria su instalación. La instalación de estas platafor-mas en entorno Windows se realiza de manera transparente ya que existe un paqueteejecutable que permite realizar todo el proceso de instalación de forma automáticay se encarga de la configuración del sistema. El compilador avr-gcc se instalará pordefecto con el paquete de TinyOS.

Existen programas que ayudan a la programación en lenguaje nesC resaltando dis-tintas partes del código o diferenciando ciertos tipos de variables. En nuestro caso seva a utilizar Programmers Notepad 2 que, a través de una plantilla para nesC, facilitala visión del código. La instalación de este programa es independiente a la instala-ción del paquete de TinyOS aunque paquetes adaptados como el de MoteWorks loincluyen por defecto ya configurado.

Para la programación del Atmega128, es decir, para transferir el programa a lamemoria del microcontrolador, es necesario instalar los drivers proporcionados con el44

3.2. PROGRAMA PARA EL VEHÍCULO AUTOBALANCEADO

programador junto con las herramientas software incluidas, entre las que se encuentrael programa para programación con STK500 que es compatible con el AVRISP-mkII.

En el Apéndice F se ha incluido un pequeño manual de cómo cargar el programaal microcontrolador una vez se compilado.

3.2. Programa para el vehículo autobalanceado

Una vez que se han introducido el sistema operativo TinyOS y el lenguaje nesC ysus principales características se va a detallar la forma de crear una aplicación. Esteproceso se va a ilustrar a través de la aplicación para el vehículo autobalanceado.

De cara al programador, la estructura de directorios que presenta TinyOS lo divideen:

interfaces: definen una especie de API que es implementada por un módulo yque puede ser usada por cualquier aplicación.

librerías: listas para ser usadas por cualquier aplicación, implementan contado-res, colas, protocolos de cifrado (TinySec), sistema embebido de bases de datos(TinyDB).

platform: implementación a bajo nivel que es dependiente de la plataforma hard-ware que se utilice y sobre todo del microcontrolador.

sensorboards: implementación a bajo nivel de las placas de expansión con sen-sores que existen para las diferentes placas.

system: en este directorio está el código del núcleo del sistema y donde se im-plementan las funciones esenciales para su funcionamiento.

types: en este directorio aparecen una serie de ficheros donde se implementanlos distintos tipos que se utilizan en este sistema.

Esta estructura está contenida en el directorio /tos. Al mismo nivel que éste, en-contramos el directorio donde se encuentran las aplicaciones, llamado /apps. En estedirectorio se encontrará nuestra aplicación. La carpeta de la aplicación contendrá dosficheros o dos componentes. El primero es una configuración en la que se especifica elcableado de los componentes que va a utilizar la aplicación principal. Y el segundo esun módulo en el que se implementan las funciones específicas de la aplicación.

El Main de la aplicación se corresponde con el componente genérico proporciona-do en las librerías de sistema de TinyOS. La función que realiza es la de inicializar el45

3. SOFTWARE

hardware e iniciar la ejecución de los procesos a través de los componentes conectadospara formar la aplicación.

Para la compilación de la aplicación tendremos un makefile o fichero de configura-ción de los elementos que se han de usar en la compilación y linkado para generacióndel código ejecutable. En este fichero es donde se especifica cuáles son los componen-tes específicos para la plataforma hardware para la que se compila.

Para la inicialización del hardware acudimos al directorio de TinyOS y en /to-s/platform/mica128 encontraremos el fichero ”hardware.h” donde se especifican lospines de entrada o salida que se van a usar de cada puerto, se configuran como tal yse les asigna un identificador.

En nuestro caso, se van a conectar los pines B0 y B2 como salida para leds, F0-2para la entrada a los conversores A/D, A0 como entrada para el pulsador, A4-5 comoentrada-salida para el bus I2C, E0-1 para el puerto serie 0 y D2-3 para el puerto serie1.

En muchas de las variables y nombres en la aplicación aparecerá la abreviaturaVbal, que proviene de la abreviatura de ”Vehículo auto-Balanceado”.

A continuación se presenta el contenido del fichero VBal.nc que implementa laconfiguración para las funciones específicas de la aplicación.

con f igura t ion VBal {}implementation {

components Main , VBalM , TimerC , LedsC , PulsadorC , I2CPacketC ,ADCC, UART;

Main . StdControl −> TimerC . StdControl ;Main . StdControl −> VBalM . StdControl ;Main . StdControl −> UART. Control ;Main . StdControl −> I2CPacketC . StdControl ;VBalM . RTTimer −> TimerC . Timer ;VBalM . Leds −> LedsC ;VBalM .ByteComm −> UART.ByteComm;VBalM . ADCControl −> ADCC. ADCControl ;VBalM .ADCAngle1 −> ADCC.ADC[ 0 ] ;VBalM .ADCAngle2 −> ADCC.ADC[ 1 ] ;VBalM .ADCAngle3 −> ADCC.ADC[ 2 ] ;VBalM . I2CPacket −> I2CPacketC . I2CPacket [0 x58 ] ;

}46


En este fichero se especifican las conexiones entre componentes que se realizan pa-ra construir la aplicación. Como se puede apreciar, se conectan los procesos de controlde los distintos componentes al control del componente principal. Con esto se ejecuta-rán todos los procesos de inicialización, inicio y parada de forma conjunta. Se cableantambién los métodos de los componentes necesarios, para que puedan ser usados porel módulo de la aplicación VBalM. El interfaz del componente ADCC.ADC viene es-pecificado a través de un puerto, esto permite que pueda ser utilizado por distintosusuarios.

El segundo componente de la aplicación se denomina VBalM. Se trata del móduloque implementa los métodos necesarios para la aplicación del vehículo. En su campode especificación se listan los interfaces que proporciona y los que usa en la imple-mentación. A continuación se muestra el campo de aplicación del módulo VBalM.nc.

module VBalM {provides {

i n t e r f a c e StdControl ;}uses {

i n t e r f a c e Timer as RTTimer ;i n t e r f a c e Leds ;i n t e r f a c e I2CPacket ;i n t e r f a c e ByteComm;i n t e r f a c e ADCControl ;i n t e r f a c e ADC as ADCAngle1 ;i n t e r f a c e ADC as ADCAngle2 ;i n t e r f a c e ADC as ADCAngle3 ;

}}

Como se puede apreciar, se van a utilizar componentes que proporcionan la gestiónde timers, control de leds, comunicación I2C, comunicación serie (RS232) y gestión deconvertidor A/D. En el caso del convertidor A/D se renombra como tres interfacesdistintos a los que se accederá a través de puertos independientes.

El campo de implementación comienza con el frame o zona de datos. En esta zonaes donde se almacena el estado del componente. En primer lugar se presenta unaenumeración de las constantes que se van a usar en el componente. A esta lista deconstantes le sigue una lista con la definición de las variables del componente, delas que las variables que así lo requieren, se les asigna valor inicial en este punto.Aquí aparecen todas las variables, tanto las usadas para el control, la comunicación,47

3. SOFTWARE

la medida de datos de los sensores, como las variables auxiliares.

La zona de implementación no se va a mostrar íntegra en este apartado, pero elcódigo fuente del componente se incluirá en el Apéndice G.

A continuación del frame, se incluyen los comandos, tareas y eventos especificadospor el componente.

Los comandos implementados en el componente son los necesarios para el controlde la aplicación. Se utilizarán para sobrecargar el StdControl y son, por tanto, StdCon-trol.init(), StdControl.start() y StdControl.stop(). En el comando init, lo que se hacees llamar a las inicializaciones de los componentes utilizados. Aquí se configurará elpuerto usado para cada uno de los convertidores A/D. También se envían los paráme-tros de configuración de la controladora de los motores a través de un primer paquetede comunicación I2C. En el comando start, se inicia el temporizador que mantendráel cliclo de control del sistema. El comando de stop de utiliza para detener el timer delciclo de control.

Las tareas definidas por el componente son cinco, una para la comunicación con elsistema de control a bajo nivel de los motores, dos para la comunicación con el PC ydos para el procesado de datos de ángulo y de velocidad de motores.

La primera tarea se denomina ComunicacionMotores( ) y en ella se controla el en-vío de la trama de comunicación por I2C a la controladora de los motores. Este envíose realiza en bloques de longitud determinada por el tipo de trama y esta tarea ges-tiona el envío ordenado de la trama completa. Tendremos diferentes tipos de tramapara configuración, escritura y lectura de registros. El envío de los datos se realiza aun nivel más bajo gracias a el componente I2Cpacket. Las características de la comu-nicación I2C se describirán en un apartado posterior.

La tarea PrintPC( ) gestiona el envío de tramas de datos al PC a través del puertoserie. A nivel más bajo, el componente ByteComm realiza el envío de un byte por elpuerto serie y la tarea se encarga de iniciar el envío de la trama completa byte a byte.El resto de la trama se envía gracias al evento que indica que el puerto está listo paratransmitir.

Los datos provenientes del PC que se leen por el puerto serie son procesados por latarea LoadData( ). Dicha tarea es llamada por el manejador que implementa el eventode recepción de un byte en el puerto serie cuando se detecta que se ha recibido unatrama completa. El proceso de comunicación con el PC se describe con más detalle enun apartado posterior.

La tarea preparaAngulo( ) se encarga de filtrar la medida del ángulo de inclinaciónque se obtiene a través del convertidor A/D. El filtro utilizado es un Butterworth48


digital paso de baja de primer orden y frecuencia de corte igual a una quinta parte dela tasa de muestreo. Una vez filtrado el dato se convierte a radianes para poder serutilizado en el cálculo de la ley de control.

En esta misma tarea se realiza el cálculo de la velocidad angular, es decir, se cal-cula la derivada del ángulo. Se han comprobado dos métodos de cálculo, el primerorealizando directamente la diferencia entre el ángulo actual y el del periodo anteriordividida por el tiempo de muestreo, y el segundo método utilizando cuatro muestrasde la forma:

ωt =θ + 3θ1 − 3θ2 − θ3

Ts(3.1)

El segundo método permite suavizar el cálculo de la derivada de la señal resultan-do una medida menos ruidosa. Ése ha sido por tanto el método elegido.

La última de las tareas que se incluyen en el método es la tarea preparaVeloc( ).Esta tarea monta el valor leído del contador de pulsos del motor a través de los cuatroregistros. Una vez compuesto el dato, se utiliza para el cálculo de velocidad de giro. Enel proceso se están descartando las medidas erróneas por fallos en la comunicación. Elcálculo de la velocidad se hace directamente en radianes que es como se va a utilizarpor la ley de control. Para terminar, se hace la conversión a velocidad lineal, a travésdel radio de la rueda, para ser enviado en este formato al PC.

Finalmente se definen los eventos que implementa el componente. Apareceráneventos asociados a interrupciones hardware, que se definen como asíncronos (asyncevent) y eventos comunicados por software.

Tendremos eventos asociados a la disponibilidad para la transmisión y la recep-ción en los dos puertos serie. Igualmente un evento, en este caso software, indica lacompleción de una transmisión o recepción por el puerto I2C, y mediante la imple-mentación de un método apropiado se implementará la comunicación.

La disponibilidad de un dato proveniente de la lectura de los sensores de inclina-ción a través del conversor A/D se indica a través de tres eventos, uno para cada eje,en el cual se implementa el almacenamiento del valor en el estado del proceso.

La función principal de control del vehículo está asociada al disparo del evento deltimer que gestiona el periodo de control. A la activación de este evento se asocian lastareas de control que se van a describir a continuación.

Inicialmente se solicitan los datos de ángulo, velocidad angular y velocidad de losmotores. Posteriormente se consulta la entrada asociada al pulsador externo conec-tado al micorocontrolador. La lectura de la posición del pulsador marcará el estadodel control. Cuando el pulsador se encuentra desactivado, el estado del vehículo se49

3. SOFTWARE

asigna como ”STOPPED” (modo de parada), se apaga el led indicador del estado y sedetienen los motores (a través del envío del valor de detención por I2C). En el modode parada se resetea la bandera de activación de parada de emergencia.

En caso de que el pulsador esté activado, el estado del controlador será ”STAR-TED” (modo activo) y se encenderá el led indicador de estado. Como ya se tienepreparados los datos necesarios, se aplica la ley de control obteniéndose un valor deactuación para los motores. El cálculo de la ley de control se corresponde con la apli-cación de una fórmula matemática, por lo que para sustituir una ley de control porotra, no será necesario más que sustituir dicha fórmula.

Una vez calculada la ley de control se realiza una corrección de la misma paraeliminar la zona muerta de acción de los motores debida a la fricción estática de losmismos. Con el valor compensado, se aplica el giro en caso de que en el experimentose esté aplicando un giro de manera externa al vehículo. En esta versión del vehículo,el control no es capaz de calcular giros por sí mismo.

Comomedida de seguridad se comprobará si el ángulo de inclinación del vehículosupera el límite considerado como ángulo permitido y si se sobrepasa ese ángulo encualquiera de las direcciones se detendrá el vehículo (parada de emergencia). Sobre-pasar ese ángulo de seguridad supondría que el vehículo se ha caído y por tanto debedetenerse por esta fuera de control.

Tras ello, se prepara el valor de actuación en el formato necesario para la comuni-cación y se envía a los motores. Ésa misma comunicación se utiliza para leer el valorde velocidad de los motores que se usará también en el cálculo de la ley de control.

Una vez enviados los datos al motor se preparan los datos del experimento paraser enviados al PC y poder ser analizados.

En los siguientes apartados se describen los procesos de comunicación que el sis-tema principal de control realiza con otros dispositivos como son la controladora delos motores y el PC externo.

3.2.1. Control de los motores vía I2C

Se ha dedicado el Apéndice H al bus I2C. En ese apéndice se describe el protocolode comunicación para este tipo de bus y se explica su funcionamiento, detallando elproceso de lectura y escritura de registros a través del bus.

El sistema de control a bajo nivel de losmotores se utiliza para aplicar a losmotoresel par que se calcula en el controlador a través de la ley de control. También se utilizará50


para realizar la medida de velocidad de los motores a mediante los codificadores depulsos que incorporan.

En el manual de la controladora de motores se especifica que la comunicación conella se realizará vía I2C mediante escrituras y lecturas de sus registros internos. En estacomunicación el microcontrolador principal hace de maestro, siendo la controladorael dispositivo esclavo.

En el funcionamiento del vehículo se realizarán tres operaciones relacionadas conla controladora de los motores.

La primera de ellas es la configuración de la controladora. Este proceso se basaen la escritura de los valores de configuración en los registros adecuados. Los valo-res asignados se guardan en los registros internos de la controladora. Estos registrosdeben estar en memoria no volátil. Por seguridad, se realizará el proceso de configu-ración en la inicialización del programa del vehículo, es decir, en su puesta en marcha.

La configuración de la controladora consistirá en:

1. Deshabilitar la regulación automática de velocidad.

2. Activar modo de operación 0: El cero de la señal de control se establece en elvalor 128, siendo el valor 0 la actuación máxima en un sentido y 255 en el sentidocontrario.

3. Motores parados inicialmente.

4. Resetear el valor inicial de los codificadores de pulsos de los motores.

5. Activar la tasa de aceleración máxima.

Una vez en funcionamiento se realizarán dos operaciones sobre la controladoraque serán la asignación de la actuación sobre los motores y la lectura de los pulsosgenerados por el codificador de cada motor.

La asignación de la actuación sobre cada motor se realiza mediante la escritura deun valor entero sin signo de 8 bits en el registro dedicado a cada motor. Los registrosasignados a los motores son el registro 0 y el 1, de ahí que se nombre a los motorescomo motor 0 y motor 1. El valor 128 se corresponde con la actuación nula, siendo el0 la actuación máxima en un sentido y el 255 la máxima en el sentido opuesto. Paraexperimentos en los que se trate el movimiento en línea recta del vehículo (solo estabi-lización) se escribe el mismo valor en el registro de los dos motores. Para experimentosen los que se estudien movimientos con giros, el valor asignado a cada registro puedeser diferente. 51

3. SOFTWARE

La velocidad de cada motor se calcula a través de la lectura del contador de pulsosque tiene asociado. El valor de cada uno de los dos contadores se compone con cuatroregistros, por lo que será necesario leer cuatro registros para el valor de cada motor.Como se explica en el Apéndice H, la lectura implica una escritura previa para indicarla dirección del registro. Al tratarse de registros consecutivos es posible leerlos todoscon una única escritura previa.

La tarea ComunicacionMotores( ) se utiliza para controlar el envío de las tramasI2C. Para la configuración tendremos una trama fija, por lo que el proceso se realiza deforma distinta a la trama para escritura de la actuación sobre los motores y la lecturadel contador que se ha denominado trama de control. La trama de control se componede una parte inicial de escritura para asignar la actuación y otra posterior de escrituray lectura para obtener el valor de los contadores, esta última parte para la lectura seusa únicamente en los casos necesarios.

La comunicación se inicia desde la tarea principal con el envío del primer sub-paquete, el evento I2CPacket.writePacketDone que se comunica al terminar el envíode un subpaquete vuelve a llamar a la tarea ComunicacionMotores( ), y ésta se en-cargará de enviar el siguiente subpaquete cuando exista, hasta terminar la comuni-cación. En la parte de la comunicación en la que se incluyen lecturas, es el eventoI2CPacket.readPacketDone el que guarda en el frame el dato leído y vuelve a llamar ala tarea ComunicacionMotores( ).

3.2.2. Comunicación entre vehículo y PC

Se establecen dos tipos de comunicación entre el vehículo y el PC. La primera secaracteriza por el envío de datos de experimento desde el vehículo al PC y la segundaes una comunicación en sentido contrario, es decir, del PC al vehículo, para configu-ración y envío de consignas.

La comunicación para el envío de los datos del experimento se realiza de maneraperiódica. En cada ciclo de control se envían los datos más relevantes como son laseñal de control, el ángulo, la velocidad angular y la velocidad de los motores. Esteproceso de envío está activo cuando el control está en modo ”STARTED”.

Como se están enviando datos de forma casi continua es necesario utilizar un siste-ma de tramas para que los datos puedan ser ordenados en la recepción. Para distinguirlas tramas se va a utilizar una cabecera a la que el PC tendrá que sincronizarse paraempezar a recibir datos válidos. Esta cabecera consistirá en el envío de dos bytes fijoscon valores decimales 170 y 85. Tras estos valores se envían los datos con un númerode bytes, formato y orden establecido, de manera que la interpretación en el PC será52


directa. En la Fig. 3.2 se muestra la trama tipo para el envío de datos de experimentoal PC.

Figura 3.2: Trama para el envío de datos de experimento.

El segundo tipo de comunicación que se puede dar es la iniciada por el PC. Estetipo de comunicación se utilizará para enviar datos de configuración al vehículo oconsignas que se pueden utilizar entre otras aplicaciones, para teleoperación.

Se va a establecer un protocolo muy simple para garantizar la comunicación yevitar errores. El protocolo se basará en el envío de tramas de formato definido y eluso de asentimiento para cierto tipo de tramas.

El formato de la trama es similar al utilizado en el envío en el sentido contrariode la comunicación, es decir, se basa en una cabecera de sincronización de trama, uncampo que distinguirá el tipo de trama y tras esto se incluyen los campos de datos conuna longitud fija definida para el tipo de trama. En la Fig. 3.3 se muestra la trama tipo.

Figura 3.3: Trama para la recepción de datos procedentes del PC.

El tipo de trama o comando (cmd) define la funcionalidad de la trama. Los co-mandos definidos se muestran a continuación. Con este método se puede ampliar elnúmero de comandos definidos añadiendo nuevas funcionalidades.

LD_PARAM: Carga de parámetros. Permite configurar desde el PC los paráme-tros del controlador y la compensación de zona muerta. Sólo puede realizarsecuando el control está detenido (modo de parada). Requiere el envío de un asen-timiento para asegurar que la carga de parámetros se ha realizado correctamente.El campo de datos estará compuesto por el conjunto de valores de configuración.

SFW_EMR_CMD: Parada de emergencia enviada vía software. Permite activarla parada de emergencia de forma externa desde el PC. No tiene campo de datos.

DIR_CMD: Comando de dirección. Modifica el offset del ángulo forzando el mo-vimiento de avance o retroceso del vehículo. En el campo de datos se envía elvalor de offset. Un valor positivo implica un movimiento de avance, mientrasque un valor negativo implica un retroceso. Este comando sólo es válido en elmodo activo del controlador. 53

3. SOFTWARE

TURN_CMD: Comando de giro. Modifica el valor de giro que hace que se des-compense el valor de actuación sobre los motores para producir el giro. El campode datos contiene un valor proporcional al giro. Este comando sólo es válido enel modo activo del controlador.

FULLMOV_CMD: Comando de dirección y giro. Incluye los datos de direccióny giro en una misma trama. Al igual que los dos que reúne, este comando sóloes válido en el modo activo del controlador.

Si el comando recibido no es uno de los anteriores se desecha la trama. Para añadirnuevos comandos habrá que incluirlos en el código de la aplicación.

Para la implementación del protocolo se utiliza la tarea asociada al evento de recep-ción del puerto serie. Al recibir los datos se busca la cabecera para la sincronización.Una vez detectada la cabecera se comprueba el tipo de comando enviado y se recogenlos datos necesarios (la longitud de los datos está definida para cada comando). Unavez que se han recogido los datos asociados al tipo de trama, ésta es procesada y selimpia la bandera que indica la espera de una nueva trama completa. El procesado serealiza a través de la tarea LoadData( ). Esta tarea es la encargada de, en función deltipo de comando, asignar los valores provenientes de la trama a las variables adecua-das del sistema, y en el caso de la configuración de parámetros, de iniciar el envío dela trama de asentimiento.

3.3. Software de comunicación externo al vehículo

Como se ha comentado con anterioridad, se ha dotado al vehículo de la posibilidadde comunicarse con un PC a través de un enlace inalámbrico. En el apartado anteriorse describe la comunicación desde el extremo del sistema de control del vehículo. Eneste apartado se pretende presentar las herramientas software utilizadas desde el PCpara realizar esta comunicación.

El adaptador inalámbrico que se va a utilizar en el PC es el mismo incluido en elvehículo, es decir, utiliza el puerto serie como interfaz con el ordenador. Por ello, elsoftware de comunicación podrá programarse en cualquier plataforma desde la quese tenga acceso al puerto serie.

En nuestro caso, se han utilizado las facilidades de programación de Matlab parael diseño de funciones y programas que permiten la implementación de las comuni-caciones descritas para el vehículo.54

3.3. SOFTWARE DE COMUNICACIÓN EXTERNO AL VEHÍCULO

Se han creado dos funciones para Matlab que permiten configurar y recibir losdatos de un experimento respectivamente. La función paramVBal permite la configu-ración de los parámetros necesarios para realizar un experimento utilizando una leyde control lineal LQR. La función capturaVBal permite realizar la captura de los datosde experimento enviados por el vehículo durante un periodo de tiempo que se indicacomo parámetro. Estas dos funciones se describen en los Apéndices I y J incluidos amodo de manual de usuario para cada una de ellas.

Finalmente se ha diseñado una aplicación a través de una interfaz gráfica de usua-rio en Matlab (GUI) que permite teleoperar el vehículo mediante el envío de los co-mandos demovimiento anteriormente descritos. Su utilización esmuy sencilla al estarcompuesta por una ventana en la que aparecen colocados, de manera intuitiva paracontrolar el movimiento, botones con una trama de comando asociada cada uno. Elvalor asociado a los comandos se puede introducir mediante una barra de desplaza-miento o mediante un campo de texto. En la Fig. 3.4 se presenta la interfaz de teleope-ración en Matlab. En la interfaz gráfica se incluyen botones para realizar la parada deemergencia y para restaurar los parámetros para la posición de equilibrio que detieneel vehículo en un punto, y también un botón que permite cortar la comunicación ysalir de la aplicación.

55

3. SOFTWARE

Figura 3.4: Interfaz para la aplicación de teleoperación del vehículo.

56

3.1....

Documents

Transcript of 3.1....