Arquitectura software y hardware para la automatización de una carretilla industrial
Autora: Raquel Sánchez Díaz
En la actualidad, la automatización de los sistemas logísticos del almacenaje constituye un desafío fundamental que busca optimizar aún más el proceso productivo. Este trabajo se enmarca dentro de un proyecto de investigación más general cuyo principal objetivo es la automatización de una carretilla industrial (Figura 1), con el fin de obtener un sistema autónomo de transporte para realizar tareas de logística y almacenaje. La carretilla ha sido recientemente adquirida por el Departamento de Informática y Automática, y servirá como plataforma tanto para la prueba de resultados teóricos obtenidos previamente por el grupo de investigación del departamento, como para el desarrollo de posteriores labores de investigación sobre vehículos autónomos y la automatización de una gestión óptima del almacenaje.
Figura 1: Carretilla adquirida por el departamento
El proceso de automatización de la carretilla es necesario plantearlo desde dos aspectos: la arquitectura hardware necesaria para la automatización de los movimientos y la arquitectura software que permita el control de los mismos.
Se deben integrar en la carretilla los elementos físicos necesarios para su movimiento controlado por ordenador, junto con los demás elementos de percepción del entorno por el que se mueve. Además se integrará un ordenador que recogerá las medidas de los sensores y ordenará las acciones a ejecutar. Para esta tarea se desarrollará una arquitectura que permita la interconexión de los diferentes elementos de tal modo que sea fácilmente escalable según aparezcan necesidades futuras referentes al sistema sensorial y de actuación.
Este proyecto se centra fundamentalmente en la parte relativa a los sensores y actuadores del sistema: recoger los datos sensoriales y controlar los actuadores. Para ello se ha diseñado una arquitectura en capas para que se pueda utilizar cualquier tipo de sensores y actuadores, sin tener que realizar cambios relevantes. El protocolo de comportamiento del sistema no se verá en absoluto modificado, ya que las interfaces para acceder a los servicios de cada capa están bien definidas y son independientes de los dispositivos.
Los sensores y actuadores están controlados por microcontroladores PIC, que se comunican con ellos mediante el bus I2C. A su vez los microcontroladores están comunicados entre sí mediante el bus de campo CAN.
Debido a que el bus CAN sólo define las capas física y de enlace, es necesario utilizar algún protocolo que implemente las capas superiores y especifique cómo se va a realizar la comunicación entre los distintos elementos conectados al bus. Para este fin se utiliza el protocolo CANopen, por estar ampliamente extendido y haber sido adoptado como un estándar internacional.
CANopen se ajusta perfectamente a nuestras necesidades ya que nos proporciona un conjunto de protocolos de comunicación y servicios necesarios para implementar un sistema de control distribuido. Se pueden diferenciar dos papeles principales: el de maestro y el de esclavo. En cada sistema habrá un único maestro y uno o más esclavos.
El maestro tiene un comportamiento diferente porque es el que se encarga de toda la gestión y el único que conoce a todos los nodos que están conectados al sistema. En nuestro caso este papel lo realiza la aplicación de control que se ejecuta en el PC.
Los esclavos (representados por los PICs) no se conocen entre ellos, ya que siempre se van a comunicar con el maestro. Podemos distinguir dos grandes grupos que son los que van a marcar la principal diferencia en el comportamiento: los esclavos que controlen sensores y los que controlen actuadores. Todos los nodos esclavos van a actuar de una manera similar dependiendo de a cuál de estos dos grupos pertenezcan.
Todo el sistema se controla desde un PC, por lo que es necesario que de alguna manera éste tenga acceso al bus CAN. Para ello hay que introducir un elemento intermedio entre el bus y el ordenador, que se encargue de realizar las transformaciones necesarias. Aunque en la arquitectura final se incluirá un adaptador de USB a CAN que realice estas tareas, provisionalmente se ha optado por resolver el problema de la siguiente manera. Hay un PIC adicional conectado al bus CAN cuya única finalidad es la de enviar por el puerto serie, en un formato determinado, los mensajes que le lleguen por el bus CAN, y al revés, es decir, transformar en mensajes CAN la información que le llegue por el puerto serie desde el PC. De esta forma se introduce una capa de abstracción para que el programa de control que se está ejecutando en el PC, y que actúa como maestro CANopen, pueda comportarse como un elemento más conectado al bus, cuando en realidad su comunicación se realiza por el puerto serie.
A continuación podemos ver una foto del sistema en funcionamiento:
Figura 2: Sistema en funcionamiento
Documentación:
Enlaces de interés: