Anais do XXVI Congresso da SBC 14 a 20 de julho de 2006

EnRI l III Encontro de Robótica Inteligente Campo Grande, MS

Arquitetura Distribuída de Hardware e Software Aplicada

a uma Plataforma Robótica Autônoma
Samaherni M. Dias1, Francisco P. A. de Medeiros1,2, Pablo J. Alsina1, Adelardo A.
D. Medeiros1
1
Laboratório de Sistemas Inteligentes, Departamento de Controle e Automação,
Universidade Federal do Rio Grande do Norte (UFRN)
Campus Universitário, CEP 59072-970, Natal, RN, Brasil
2
Centro Federal de Educação Tecnológica da Paraíba (CEFET-PB)
Rua José Antônio da Silva, 300 CEP: 58.900-000 – Cajazeiras, PB, Brasil
{sama, petronio, pablo, adelardo}@dca.ufrn.br

Abstract. This article presents a distributed architecture of hardware and

software capable to deal with a great number of sensors and actuators,
allowing modularization of the applications. The sensors and actuators are
controlled independently through microcontrolled modules, which
communicate with the embedded computer, responsible for the tasks of high
level and IO mechanisms, through a net CAN. This proposal instance partially
a distributed component-based architecture of the hardware and software, that
the designer will allow to use components previously specified for the
construction of robotic systems.

Resumo. Este artigo propôe uma arquitetura de hardware e software

distribuída capaz de lidar com um grande número de sensores e atuadores,
permitindo modularização das aplicações. Os sensores e atuadores são
controlados de forma independente através de módulos microcontrolados, os
quais se comunicam com o computador embarcado, responsável pelas tarefas
de alto nível e mecanismos de entrada e saída, através de uma rede CAN. Essa
proposta instancia parcialmente uma arquitetura baseada em componentes de
hardware e software distribuídos, que permitirá ao projetista utilizar
componentes previamente especificados para a construção de sistemas
robóticos.

1. Introdução
Um robô autônomo é comumente visto como um sistema que integra percepção e ação
num ambiente dinâmico com a mínima supervisão humana (Py, F. e Ingrand, F., 2004).
Para interagir com o ambiente ao qual está inserido, é essencial no robô a presença de
diversos tipos de sensores e atuadores que possibilite a aquisição de informações sobre o
seu estado, sua localização, detectar e evitar obstáculos, monitorar interações com o
ambiente, medir e corrigir erros de modelagem, monitorar mudanças no ambiente e
obter parâmetros necessários para o controle do robô (Mutambara, A. G. O., 1998).
Para integrar sensores e atuadores há a necessidade de uma arquitetura que seja
responsável pelo controle das ações realizadas pelo robô, definindo a estrutura física do

46
sistema. Uma arquitetura é um sistema de componentes cuja estrutura e integração
permite a ele realizar funções que os componentes individualmente não poderiam
efetivamente realizar (Klein, A. A., 2005).
A arquitetura é composta pelo arranjo, pela comunicação e pelo fluxo de dados
entre as partes componentes (Bedworth, M. e Brien, J., 2000). Uma arquitetura deve
facilitar o desenvolvimento de sistemas robóticos provendo restrições benéficas no
projeto e na implementação da aplicação desejada, servindo inclusive para a integração
de módulos que sejam desenvolvidos independentemente (Coste-Maniére, E. e
Simmons, R., 2000).
As arquiteturas podem ser classificadas de acordo com a organização dos
módulos interconectados e pela forma de processamento desses módulos em
centralizadas e distribuídas. No caso da arquitetura centralizada, um processador central
único executa todo o processamento, agregando, portanto, um melhor custo benefício
que a arquitetura distribuída, por utilizar um único processador ao invés de vários. Por
outro lado, a arquitetura centralizada oferece uma confiabilidade menor que a
arquitetura distribuída, uma vez que uma falha no processador central compromete todo
o sistema.
A arquitetura distribuída é baseada em sistemas sensoriais e controladores
distribuídos simples, interligados em uma rede de sensores e atuadores, na qual nenhum
sistema individual está em nível hierárquico superior a qualquer outro. Desta forma, o
sistema se torna robusto, confiável, flexível, extensível e mais tolerante a falhas do que
na abordagem centralizada. A falha de um subsistema não implica necessariamente na
falha do sistema global (Mutambara, A. G. O., 1998).
Embora arquiteturas distribuídas tenham a vantagem da distribuição da carga
computacional e não sofra das limitações impostas às arquiteturas centralizadas quando
ao processamento, há ainda limitações associadas, como: fluxo de comunicação maior e
problemas de sincronização.
Algumas características da maioria das aplicações robóticas tais como alta taxa
de amostragem, grande número de sensores e atuadores de natureza diversa e
necessidade de alta taxa de comunicação de dados levam a necessidade de distribuir o
processamento, justificando portanto a utilização de uma arquitetura distribuída
(Medeiros, F. P. A., 2005).
Nesse sentido, é proposta uma arquitetura de hardware e software distribuída que
possua as seguintes características: (i) ser capaz de lidar com um grande número de
sensores e atuadores diversos distribuídos; (ii) ser implementada numa plataforma de
baixo custo; (iii) permitir modularização, padronização e reuso das aplicações e (iv)
possuir um alto nível de sincronização entre as trocas de mensagens entre os nodos da
arquitetura distribuída.
Será apresentada na seção 2 a plataforma robótica de baixo custo dotada de
braço manipulador, sensores diversos (odometria, sonares, etc.), atuadores, sistema de
visão estéreo e capacidade de processamento embarcado que implementa a arquitetura
proposta. Na seção 3 e seção 4 serão abordadas as arquiteturas de hardware e de
software respectivamente e na seção 5 serão discutidos os resultados e os trabalhos em
andamento sobre a arquitetura e sobre a plataforma robótica desenvolvida.

47
2. Robô KAPECK
Trata-se de uma plataforma móvel de baixo custo desenvolvida com tecnologia
nacional. Este protótipo faz parte de um projeto onde serão investigados técnicas, teorias
e métodos que permitam integrar eficientemente esquemas de fusão sensorial,
mecanismos de controle de atenção e técnicas de redução de informação.
Essa plataforma robótica servirá como ambiente de desenvolvimento e teste de
aplicações que envolvem monitoração, navegação e manipulação de forma autônoma. A
figura 1 apresenta o robô KAPECK.

Figura 1. Especificação mecânica do robô.

A plataforma robótica foi projetada sobre uma base móvel contendo uma cabeça de
visão estéreo e dois braços com garras:
Base móvel:
• Duas rodas com acionamento diferencial e duas rodas livres.
• Carga útil 40 kg.
• Velocidade máxima 0.5 m/s.
• Aceleração máxima 0.1 m/s2.
• Alimentação elétrica embarcada (baterias).
• Autonomia de 30 minutos de operação.
Cabeça com Visão Estéreo:
• Processamento de visão estéreo em tempo real (30 quadros por segundo).
• 5 Graus de Liberdade.
• Controle de vergência, mas possibilidade também de funcionamento
independente das câmeras.
• Resolução angular de 1 minuto de arco para cada eixo da cabeça.
Dois braços com garras:
• Cada braço com cinco juntas.

48
 • Garra abre-fecha
• Capacidade de carga de cada braço = 0,5 kg.

2.1. Especificação do conjunto de sensores e atuadores do robô

A arquitetura tem a capacidade para suportar múltiplos sensores e atuadores (acima de
20) a uma taxa de amostragem de 200 Hz (intervalo de 5 ms). Os sensores e atuadores
são controlados independentemente por microcontroladores dedicados distribuídos. Os
sensores e atuadores presentes no robô foram especificados da seguinte forma:
Base do robô:
• Dois motores CC com dois encoders (1024 pulsos por revolução).
• Um Colar de seis sonares com alcance máximo de 8 metros.
Braço (direito e esquerdo):
• Cinco motores CC, (cinco juntas), com quatro sensores de posição resistivos
(potenciômetros) e um encoder (1024 pulsos por revolução: junta do ombro). (*)
• Um motor CC sem realimentação para acionamento da garra. (*)
(*) Duplicado.
Cabeça:
• Cinco motores CC com cinco encoders (1024 pulsos por revolução).
• Duas câmeras CCD 640x480 pixels, 30 quadros por segundo.
O período de amostragem proposto para medição dos encoders e potenciômetros e
acionamento dos motores foi de 5 ms (taxa de amostragem de 200 Hz). O período de
amostragem e acionamento dos sonares foi escolhido como 80 ms.

3. Arquitetura de Hardware
Devido ao robô ser autônomo, foi especificado um computador embarcado composto
por três placas de processadores Pentium 1GHz. Uma das placas é dedicada e associada
a uma placa de aquisição de imagem, exclusivamente para processar visão estéreo,
tarefa conhecidamente consumidora de esforço computacional. Uma outra foi atribuída
à tarefa de supervisionar sensores e atuadores (processamento de baixo nível de entradas
e saídas para sensores e atuadores). A terceira placa é responsável pela tarefa de
processamento de alto nível (navegação, manipulação, monitoração). A comunicação
entre as três placas foi concebida para ser realizada através de uma rede Ethernet.
Devido ao elevado número de sensores e atuadores a serem integrados ao robô e
à taxa de amostragem escolhida, verificou-se que a banda passante, maior do que 100
kbps, necessária para envio de comandos e leitura das medições digitalizadas por parte
do computador embarcado, poderia comprometer o sistema. Assim, optou-se por
especificar uma arquitetura de hardware distribuída.
De acordo com esta proposta, os sensores e atuadores são controlados de forma
independente através de microcontroladores dedicados. Sendo assim, cada motor e seu
sensor de posição associado possuem uma placa microcontrolada dedicada que realizam
a amostragem do sensor e o acionamento do motor.
Foi especificada uma arquitetura mestre-escravo, onde o PC embarcado
supervisiona todos os módulos controladores de sensores e atuadores, comunicando-se

49
com os mesmos através de uma rede CAN BUS (Hubert, K. K., 2001), que atende aos
requisitos necessários de banda passante.
O CAN (Controller Area Network) é um protocolo de comunicação serial, tão
eficiente que suporta controle distribuído em tempo real com um alto nível de robustez.
O CAN obtém destaque em sistemas de automação por ter uma proposta de alta
velocidade (1Mbit/seg), baixo custo e por possuir um excelente conjunto de definições
em termos de protocolo (Richards, P., 2005).
A figura 2 mostra um esquema da arquitetura proposta.
Câmera
PC Proc. Imagem Frame-grabber
Câmera
Ether
net
PC Deliberação HD
6
PC E/S PCI-CAN sonares

PIC (1 -
sonares)
CAN

2 PIC 5 PIC 2 PIC 8 PIC 2 PIC

(rodas) (cabeça) (ombros) (braços) (garras)

Motor En Motor En Fim de Motor En Fim de Motor Potencio- Motor

CC co CC co curso CC co curso CC metro CC
der der der

Figura 2. Arquitetura de Hardware do Robô.

De acordo com a arquitetura proposta foram projetados módulos microcontrolados

embarcados para acionamento dos sonares e dos motores. Seguindo as especificações,
foi projetado um circuito eletrônico para medição e acionamento dos sonares baseado
em um microcontrolador de baixo custo.

3.1. Módulos microcontrolados embarcados

O projeto do sistema de acionamento dos motores decidiu embarcar a eletrônica
em placas próximas aos motores a serem acionados. Por exemplo, os controladores dos
motores de juntas ficam embutidos dentro da própria estrutura mecânica do braço. Desta
forma, foram projetados circuitos de acionamento miniaturizados, adequados a esta
especificação. Ao todo são acionados dezenove motores (dois da base, cinco da cabeça,
cinco para cada um dos dois braços e um para cada uma das duas garras).
Dependendo da função de operação, as características de acionamento do motor
e do sensor de posição disponível são diferentes. Nesse sentido, para baratear os custos
de confecção das placas de circuito com a fabricação da placa e a compra de
componentes, foi projetada uma placa modular multifuncional capaz de acionar

50
qualquer um dos dezenove motores, sendo a sua configuração alterada através de
jumpers.
A figura 3 mostra um esquema da placa multifuncional projetada.

Figura 3. Módulo multifuncional para acionamento dos motores.

Como mostra a figura 3, a placa principal (SMD_MULT_BOARD) tem como função

primordial interligar o motor ao barramento CAN, possibilitando o controle central
obter informações do mesmo, assim como alterar seus parâmetros de controle. Para o
acionamento e medição dos sonares foi projetado um módulo de circuito eletrônico
baseado em microcontrolador de baixo custo.
Os módulos de controle dos sonares e a placa multifuncional para acionamento
de motores foram montados em uma protoboard e foram realizados testes de
funcionamento destes sistemas projetados. Todos os sistemas foram aprovados nos
testes. O software básico dos sistemas eletrônicos embarcados foi desenvolvido e
testado nas montagens de teste (montagens em protoboard).

4. Arquitetura de Software
A arquitetura de software foi desenvolvida levando-se em consideração as definições,
características e os protocolos de comunicação empregados na arquitetura de hardware.
Há três formas de comunicação entre os módulos do sistema. A primeira trata da
comunicação mestre-escravo entre o PC embarcado e os módulos microcontrolados
através de uma rede CAN de transmissão de dados, a segunda trata da comunicação
entre os processadores do PC embarcado através de uma rede ethernet e a terceira
comunicação foca na comunicação entre o usuário e o PC embarcado.

51
 Devido à arquitetura ser distribuída, os processos que agem paralelamente
disputam os mesmos recursos de hardware e sistemas operacionais, ao mesmo tempo
em que, pela própria definição de programa concorrente, cooperam para o êxito do
sistema como um todo. Os processos compartilham recursos e se comunicam entre si,
seja através do uso de variáveis (memórias) compartilhadas, seja através da troca de
mensagens (Silva. D. M., 1999). Em ambos os casos, é necessária a utilização de um
mecanismo de sincronização, que pode ser a primitiva de exclusão mútua ou semáforos,
por exemplo.
A comunicação entre o PC embarcado e os módulos microcontrolados através da
rede CAN é realizada através de uma arquitetura mestre-escravo, ou seja, os
controladores distribuídos, que desempenham a função de escravos, respondem as
requisições feitas pelo PC embarcado, que realiza a função de controlador mestre.
Localmente, os módulos microcontrolados, que estão distribuídos nas várias
partes do robô, possuem embarcados softwares específicos que lêem os sensores de
posição, controlam e acionam os motores CC, medem e acionam os sonares, recebem
referências de velocidade e posição etc, que são disponibilizados em áreas (memórias)
compartilhadas nos próprios controladores, de modo que quando solicitadas possam ser
enviadas ao controle mestre ou possam ser utilizadas no processamento local do
controlador.
Os quadros que trafegam na rede CAN entre o PC e os controladores possuem o
seguinte formato:

De Para Função Parâmetros variáveis

Figura 4. Quadros que trafegam na rede CAN.

Entre algumas funções disponíveis oriundas do controle mestre e que possui como
destino os controladores escravos podemos listar: requisição de referências (velocidade
ou posição), acionamento do sonar, configuração de um controlador, requisição de
medição, etc. Os controladores distribuídos sempre respondem a requisição solicitada
num quadro com este mesmo formato.
A comunicação entre as placas de processadores do PC embarcado
interconectadas através de uma rede ethernet se dá através de sockets, que são objetos
que representam o ponto de acesso a um canal de comunicação entre processos.

5. Conclusão
A arquitetura aqui apresentada se baseia em controladores distribuídos, interligados com
um computador embarcado através de uma rede CAN, possibilitando que o sistema
torne-se robusto, confiável, com menor sobrecarga computacional, baixo overhead de
comunicação e maior tolerância à falhas do que se fosse utilizada uma abordagem
centralizada. A falha de um subsistema não implica necessariamente na falha do sistema
global.

52
 A arquitetura desenvolvida, que foi aplicada no robô KAPECK, é capaz de lidar
com um grande número de sensores e atuadores distribuídos, permitindo que estes sejam
controlados de forma independente através de microcontroladores dedicados. O
hardware e o software foram especificados segundo uma arquitetura mestre-escravo,
onde um computador embarcado supervisiona todos os módulos controladores de
sensores e atuadores, comunicando-se com os mesmos através de uma rede CAN BUS.
Por ser modular e distribuída, a arquitetura proposta é expansível, o que permite
que novos módulos possam ser agregados ao projeto de um robô que utilize esta
arquitetura, sendo necessário que o novo módulo, sensor-motor ou sonar, seja
pendurado à rede CAN.
De forma que a expansibilidade seja conseguida de uma forma mais
generalizada, permitindo um leque maior de funcionalidades padronizadas, uma tese de
doutorado em andamento propõe uma arquitetura baseada em componentes de software
e hardware para suporte a aplicações robóticas distribuídas. O projeto prevê a
construção de uma ferramenta que permitirá ao projetista utilizar componentes
previamente especificados para a construção de sistemas robóticos.

Referências Bibliográficas
Coste-Maniére, E. e Simmons, R. (2000). Architecture, the backbone of robotic systems.
IEEE International Conference on Robotics and Automation.
Bedworth, M. e Brien, J. (2000) The Omnibus Model: A New Model of Data Fusion,
IEEE Aerospace and Electronic Systems Magazine.
Rosenblatt, J. (1997) DAMN: A distributed architecture for mobile navigation. Tese de
Doutorado, Carnegie Melon University, EUA.
Souza, R. S. e Medeiros, A. (2004). Uma metodologia de interconexão entre redes de
campo e de supervisão em ambiente industrial. Congresso Brasileiro de Automática.
Py, F. e Ingrand, F. (2004), Dependable execution control for autonomous robots, IROS
2004 IEEE/RSJ International Conference on Intelligent Robots and Systems, Sendai,
Japan.
Mutambara, A. G. O. (1998) Decentralized Estimation and Control for Multi-sensor
Systems. EUA: CRC Press.
Klein, L. A. (2004). Data and sensor fusion: a tool for information assessment and
decision making. SPIE – The International Society for Optical Engineering.
Richards, P. (2005). A can physical layer discussion. Microship Technology.
DS00228A.
Hubert, M. K. (2001). O protocolo CAN como solução para aplicações distribuídas,
baseadas em objetos, entre pcs e microcontroladores. Universidade Federal de
Pelotas.
Silva, D. M. (1999). Introdução à Programação Concorrente para a Internet. JAI -
Jornada de Atualização em Informática. pp. 209-262.
Medeiros, F. P. A. (2005). Uma arquitetura baseada em componentes de hardware e
software para suporte a aplicações robóticas distribuídas. Proposta de Qualificação de

53
Doutorado. Programa de Pós-Graduação em Engenharia Elétrica, Universidade
Federal do Rio Grande do Norte.

54