rtfCANopen
- Una
implementación de CANopen para Sistemas de Tiempo Real -
Aitor Olarra (aolarra@tekniker.es)
Javier Portillo (jtppobej@bi.ehu.es)
Marga
Marcos
Itziar
Cabanes
ÍNDICE
CAN bus y los protocolos de alto nivel
Aplicación a un robot móvil autónomo
Aunque inicialmente el bus CAN (Controller Area Network) se desarrolló en la industria del automóvil (CAN 1991), posteriormente se demostró que es un bus muy adecuado para aplicaciones industriales. Entre sus características, cabe destacar:
- Fiabilidad a interferencias electromagnéticas
- Tiempos de latencia bajos, lo que le capacita para aplicaciones con
requisitos temporales
- Capacidad multi-maestro. Cualquier nodo puede iniciar la comunicación
- Muy baja probabilidad de errores residuales
- Soporte tanto del modelo Cliente/Servidor como del modelo
Productor/Consumidor
El protocolo CAN básico sólo especifica hasta el nivel 2 del Modelo de Referencia OSI de ISO, por lo que es abierto a protocolos superiores y se pueden adoptar tanto protocolos propietarios como estándares. Se han propuesto diferentes protocolos de alto nivel: CAL/CANopen de Can in Automation (CiA), DeviceNet de Open DeviceNet Vendor Association (ODVA), SDS de Honeywell,... Los beneficios de adoptar un protocolo de alto nivel estándar se pueden resumir en los siguientes:
- Pueden conectarse o intercambiarse productos de diferentes fabricantes
- Fácil conexión y configuración de nuevos dispositivos
- Proporcionan un conjunto de servicios para el arranque y configuración
de la red
Uno de los protocolos más utilizados es CANopen (CiA 1996). En él se definen varios tipos de mensajes para tratar con datos de diferente naturaleza:
- Mensajes PDO (Process Data Object) para datos de tiempo real
- Mensajes SDO (Service Data Object) para datos de configuración de los
nodos
- Mensajes NMT para datos de gestión de red
Asimismo, es interesante comentar la función del mensaje SYNC, que permite el funcionamiento síncrono de mensajes con de tiempo real. Sólo el nodo maestro NMT puede enviar mensajes de sincronismo. Este funcionamiento permite coordinar la transmisión de mensajes PDO, haciendo, por ejemplo, que un nodo concreto sólo envíe sus datos una vez recibidos un número concreto de mensajes de sincronismo, lo que permite programar la frecuencia de refresco de datos de dicho nodo.
El comportamiento
temporal determinista del bus CAN le hace muy apropiado para sistemas
distribuidos con requisitos temporales. Además, es posible calcular el
comportamiento temporal de peor caso de todos los mensajes de una red CAN
(Tindell y Burns 1994). Este estudio ha sido utilizado por GCIS (Grupo de
Control e Integración de Sistemas) como fundamento teórico de la
herramienta BERTA
(Basic Environment for Real Time Analysis), que permite calcular el
comportamiento temporal de peor caso del conjunto de tareas y mensajes que
forman un sistema distribuido (Marcos y Portillo 2000). Dicha herramienta
realiza el estudio suponiendo que la aplicación genera y recibe tramas de nivel
2. Este análisis forma parte de un entorno denominado Real Time Framework (RTF)
que integra herramientas de control continuo y el comportamiento a eventos
discretos en entorno Matlab (Mathworks).
De forma que, mediante el diseño de nuevas librerías de bloques Simulink,
permite especificar la arquitectura de nodos presentes en la red CAN del
sistema distribuido en cuanto a tareas concurrentes y mensajes que
intercambian, simular su comportamiento temporal y generar el código de la
aplicación (Marcos et al 2000, Portillo y Marcos 2001).
En esta línea de
trabajo, se plantea el objetivo de introducir un protocolo CAN de alto nivel
cuyo comportamiento temporal sea determinista. Esta característica es difícil
de llevar a cabo con implementaciones comerciales ya que, por lo general,
únicamente se dispone de código objeto. Por otro lado, los tiempos de ejecución
de peor caso (WCET) deben ser calculados con precisión y esto cuando menos
resulta dificultoso si no se tiene un completo acceso a la arquitectura de
comunicaciones.
Los nodos rtfCANopen están diseñados alrededor de un microcontrolador
16F873 de Microchip
que utiliza el interfaz SPI (Serial Port Interface) para comunicarse con un
controlador CAN MCP2510, también de Microchip.
Este controlador CAN accede a la red CAN por medio de un transceiver
82C251 de Philips.
Además del conector para el bus CAN, los nodos disponen de conectores para los
dispositivos que debe controlar. La configuración de los parámetros básicos de
los nodos (velocidad de la red CAN, nodeID del nodo en CANopen y velocidad del
microcontrolador) se realiza a través de interruptores. Por ultimo, el nodo
dispone de un LED que indica el estado en el que se encuentra (dentro de los
estados recogidos en los servicios NMT de CANopen).
Las caraterísticas principales del microcontrolador empleado son las siguientes:
- 4 Kword FLASH de memoria de programa
- 192 bytes de RAM
- 5 MIPS a 20 MHz
- Periféricos:
- tres contadores
- interfaz SPI
- USART
- conversor analógico / digital
Aquí
hay más información acerca del hardware de los nodos.
rtfCANopen se compone del
software que se ejecuta en los microcontroladores de los nodos.
Este software esta
codificado en ensamblador optimizando así, los recursos de memoria que consume.
Esta diseñado siguiendo una estructura modular lo que permite que se pueda
actualizar y modificar de una manera sencilla. Este diseño permite a su vez,
generar el software en un formato de librería.
Actualmente hay dos
versiones de rtfCANopen, las dos son una implementación del protocolo CANopen
para los nodos de comunicaciones rtfCANopen. Ambas versiones cumplen con el
estándar CANopen y ofrecen servicios de comunicación PDO y SDO.
La versión 2.0 además de
incluir todas las funcionalidades y características CANopen que ofrece la
primera versión, aprovecha el carácter abierto de CANopen para incorporar la
capacidad de actualizar su software a través de la red CAN. Con dicha
capacidad, se permite modificar y adecuar el software que controla cada nodo a
sus necesidades.
CAN (1991). Bosch CAN
specification, V 2.0 PartA. R. Bosch Gmbh, Germany.
CiA (CAN in Automation)
(1996). CANopen Communication profile for Industrial Systems. CiA Draft
Standard 301. CiA, Germany.
Marcos, M. M., Portillo,
J. (2000). Basic Environment for Real Time Systems Analysis using CAN bus.
Proceeding of the Workshop on Real Time Programming. Palma de Mallorca (Spain),
May 2000.
Marcos, M. M., Portillo, J.,
Bass J.M. (2000). Matlab-based real-time framework for distributed control
systems. Proceeding of the Workshop on Algorithms and Architectures for
Real-Time Control. Palma de Mallorca (Spain), May 2000.
Portillo, J., Marcos, M. (2001). Contributions to the design of real time distributed control systems. Proceedings of the European Control Conference, September, 2001. Porto, Portugal.
Tindell, K. and A. Burns
(1994). Guaranteeing Message Latencies on Controller Area Network (CAN).
Proceedings 1st International CAN Conference, Mainz (Germany), September 1994.
Varios de estos nodos rtfCANopen han sido utilizados exitosamente en
el desarrollo de un robot
móvil autónomo. Todos los sensores y actuadores de dicho robot móvil están
conectados a los diferentes nodos rtfCANopen de modo que el controlador
del robot (un PC de sobremesa o una CPU PC-104) puede acceder a ellos por medio
de una tarjeta CAN.
|
|
Nodo rtfCANopen que
realiza la lectura de |
Entre los dispositivos conectados a los nodos rtfCANopen del robot podemos
encontrar:
- sensores IR SHARP GP2D02
- sonar ultrasónico POLAROID 6500
- servo de RC
- sensores IR FAIRCHILD QRB1134
- módulo de potencia para el gobierno de motores de DC
- sensores de efecto HALL
- teclado y LCD
Aquí se amplía la información sobre el robot móvil autónomo.