Robotização de uma cadeira de rodas elétrica

Escola Superior de Tecnologia de Tomar

Jorge Anécio Dias Rodrigues

Robotização de uma

cadeira de rodas elétrica

Projeto

Orientado por:

Doutor Gabriel Pereira Pires – Instituto Politécnico de Tomar Doutora Ana Cristina Lopes – Instituto Politécnico de Tomar

Projeto apresentado ao Instituto Politécnico de Tomar para cumprimento dos requisitos necessários à obtenção do

DEDICATÓRIA

Dedico este projeto a todos os que me apoiaram neste percurso, particularmente à minha família, que se privou de muitos momentos em conjunto para que este objetivo fosse alcançado.

Dedico-o também a todos que têm um sonho a concretizar e não se deixam desvanecer com as “intempéries” do percurso.

RESUMO

Este projeto consiste na robotização de uma cadeira de rodas elétrica comercial Salsa R2 existente no laboratório VITA.IPT, dotando-a de um sistema de navegação assistida que lhe confere um nível de segurança anti-colisão. A robotização da cadeira de rodas foi realizada mantendo funcional o sistema original da cadeira de rodas Salsa R2. Foi concebida uma nova arquitetura de hardware e software, tendo sido integrados os seguintes módulos: 1) sistema de potência baseado no controlador Roboteq MDC2230; 2) joystick para interface do utilizador; 3) unidade de processamento/controlo de baixo nível baseado numa Raspberry

Pi (RPi); 4) módulo sensorial de perceção baseado num laser Hokuyo UTM-30LX; 5)

módulo de odometria; e 6) unidade de processamento de alto nível com plataforma ROS (Robotic Operating System) para implementação de algoritmos de navegação.

O sistema permite ao utilizador selecionar entre modo manual e modo assistido, através de um comutador acessível no braço da cadeira. No modo de navegação assistida, o módulo de navegação/perceção evita a colisão com possíveis obstáculos que se encontrem no percurso de circulação, filtrando comandos inapropriados do utilizador. O método implementado baseia-se na análise de ocupação de sectores predefinidos numa região frontal à cadeira de rodas, e tem em consideração o comando de direção e velocidade do utilizador e as definições físicas e dinâmicas da cadeira robótica.

O sistema foi testado e validado experimentalmente com sucesso em ambiente real (ambiente interior de laboratório e corredores, com obstáculos estáticos e dinâmicos).

ABSTRACT

This project describes the modification of a commercial powered wheelchair Salsa R2, available in the laboratory VITA.IPT, into a robotic wheelchair, endowing it with an assisted navigation system which provides an anti-collision safety level. The modification performed on the original powered wheelchair Salsa R2 kept the original system functional. New hardware and software architectures were designed and the following modules were implemented: 1) Power system based on the MDC2230 Roboteq controller; 2) joystick as user interface; 3) low-level processing/control unit based on a Raspberry Pi (RPi); 4) sensory perception module based on a Hokuyo UTM-30LX laser; 5) odometry module; e 6) high level processing unit based on the ROS platform for the implementation of the navigation algorithm.

The system offers the user the possibility of switching between the navigation mode and the manual mode, through switch-button on the wheelchair arm. In the assisted navigation mode, the navigation/perception module avoids the collision with possible obstacles located on the navigation track, by filtering unsuitable commands from the user. The implemented method is based on the analysis of the occupation of a predefined grid in the frontal area of the wheelchair, and considers the velocity and direction commands given by the user and the physical and dynamic definitions of the wheelchair.

The system was tested and validated experimentally in real environment with success (indoor environments, namely VITA.IPT laboratory and halls, considering static and dynamic obstacles).

AGRADECIMENTOS

A realização deste projeto de mestrado contou com importantes apoios e incentivos sem os quais não teria sido possível e aos quais estarei eternamente grato.

Aos meus orientadores, a professora Doutora Ana Lopes e o professor Doutor Gabriel Pires, pela liberdade e confiança que depositaram em mim, cedendo-me toda a autonomia necessário para a gestão do tempo e disponibilidade para evoluir neste trabalho.

Aos colegas e professores de curso pelo conhecimento e motivação que me transmitiram ao longo de todo o percurso académico. Ao Eng.º Pedro Neves pela disponibilidade e apoio às questões e dúvidas apresentadas no decorrer deste projeto.

Um agradecimento em especial para a minha família que sempre esteve a meu lado com palavras de motivação e encorajamento desde o início à conclusão desta jornada.

Não podia deixar de agradecer também os recursos e condições oferecidas pelo Lab. VITA.IPT – Vida Assistida por Ambientes Inteligentes.

Este projeto foi parcialmente financiado pelo Projeto QREN: ICT_2013_05_010_5334 ID:64763: Reforço das competências científicas e tecnológicas do Instituto Politécnico de Tomar (fonte de financiamento 415).

ÍNDICE

1. Introdução ... 1

1.1. Motivação e Contexto ... 1

1.2. Objetivos ... 1

1.3. Contribuições e trabalho realizado ... 2

1.4. Organização da dissertação ... 3

2. Estado da Arte e Fundamentos ... 5

2.1. Cadeiras de Rodas Robotizadas ... 5

2.1.1. Projetos de cadeiras de rodas inteligentes ... 6

2.1.2. Interfaces de condução ... 7

2.2. Perceção e planeamento de caminhos ... 10

2.3. ROS – Robotic Operating Systems ... 14

3. Arquitetura de Hardware e Software ... 19

3.1. Plataforma base – Salsa R2 ... 19

3.2. Robotização da cadeira de rodas elétrica ... 21

3.2.1. Raspberry Pi 1 Model B... 23

3.2.2. Joystick ... 25

3.2.3. Roboteq MDC2230 ... 26

3.2.4. Motores e Encoders ... 28

3.2.5. Hokuyo UTM-30LX Laser Rangefinder ... 30

3.2.6. Placa de alimentação e interligação de periféricos ... 31

3.2.7. Notebook Asus F200M ... 32

3.3. Arquitetura de software ... 32

3.4. Fluxograma de software do controlador RPi... 35

4.1.1. Modelo dinâmico... 37

4.1.2. Equações cinemáticas ... 38

4.1.3. Odometria ... 39

4.2. Procedimento de verificação e calibração UMBmark ... 40

4.2.1. Procedimento de verificação ... 40

4.2.2. A calibração da odometria... 43

4.2.3. Procedimento de calibração conjunta ... 44

4.3. Navegação ... 44

4.3.1. Navegação Livre ... 45

4.3.2. Navegação com Sistema de Anti-Colisão ... 45

4.3.3. Projeção do Scanner ... 47

4.3.4. Segurança Ativa baseada na análise de risco ... 48

4.3.5. Dinâmica de navegação ... 50

5. Integração do sistema na plataforma ROS ... 53

5.1. Arquitetura do software na plataforma ROS ... 53

5.2. Análise de Risco ... 55

5.3. Fluxograma da Análise de Risco ... 57

6. Ensaios e resultados experimentais ... 59

6.1. Ensaios sistema de comando e tração ... 59

6.2. Ensaios dinâmicos de tração ... 60

6.3. Ensaios do sistema de navegação ... 63

7. Conclusões e trabalho futuro ... 69

ANEXOS ... 71

I. Cálculo dos parâmetros para controlo PID ... 71

a. Função de transferência ... 71

b. Cálculo de Kp, Ki, Kd ... 72

II. Colocação ao serviço do Sistema ... 75

III. Processo de comutação entre sistemas ... 77

ÍNDICE DE FIGURAS

Figura 1- Dispositivos de controlo para cadeiras de rodas elétricas... 8

Figura 2- Projeção bidimensional de campo de visão e resposta probabilística considerando leituras obtidas por sonar [18] ... 10

Figura 3- Exemplo de campos potenciais aplicados num robô [18] ... 12

Figura 4- Exemplo de Janela Dinâmica [17] ... 13

Figura 5- Estrutura de Nós e Tópicos - ROS ... 16

Figura 6- Softbanks Robotics - Varrimentos 3D e pegadas em rviz.[19]... 16

Figura 8- Arquitetura do sistema ... 19

Figura 9- Cadeira de rodas elétrica Salsa R2 [20] ... 19

Figura 10- Diagrama principal de ligações VR2 and RNET[20] ... 20

Figura 11- Microprocessadores do módulo de potência e do módulo de Joystick ... 21

Figura 12- Estrutura de implementação da cadeira de rodas robótica ... 22

Figura 13- Raspberry Pi 1 Modelo B [22] ... 23

Figura 14- GPIO Pinout do RPi ... 24

Figura 15- Joystick Keyes_SJoys ... 25

Figura 16- Sincronismo série MCP3002 [23] ... 26

Figura 17- Roboteq MDC2230 [24] ... 27

Figura 18- Alimentação do controlador com destaque para a implementação de paragem emergência [24] ... 27

Figura 20- Encoder AMT103-V [26] ... 29

Figura 21- Hokuyo UTM-30LX [27] ... 30

Figura 22- Suporte de montagem do LRF ... 30

Figura 24- Placa de circuito impresso ... 31

Figura 26- Estrutura do Software no RPi ... 33

Figura 27- Fluxograma de software do controlador RPi ... 35

Figura 28- Representação do robô no sistema coordenadas cartesianas [28]... 37

Figura 29- Posição e orientação do robô [28]... 38

Figura 30- Dados adquirido no processo de calibração [29] ... 41

Figura 31- a) Erro característico Tipo A (d); b) Erro característico Tipo B(diâmetro de rodas) [29] ... 42

Figura 34 - a) Projeção dos pontos obtidos em C para R. b) Pontos projetados em R em

coordenadas polares ... 47

Figura 35- Identificação das diferentes zonas de possível colisão ... 48

Figura 36- Grafo de nós e tópicos do ROS implementado ... 53

Figura 37- Definição de limites de zonas de risco... 56

Figura 39- Fluxograma da análise de risco ... 57

Figura 40- Configuração das saídas de potência Roboteq ... 60

Figura 41- Gráfico de dispersão dos resultados do método UMBmark ... 61

Figura 42- Planta do Bloco I do IPT com percursos de ensaios de odometrias ... 63

Figura 43- Visualização de dados do Scanner com Software RVIZ e sua imagem ... 63

Figura 44- Gráficos com representação das distâncias referenciadas ao laser e ao centro de rotação ... 64

Figura 45- Ensaios dinâmicos de deteção de obstáculos com indicação de velocidade pretendida e permitida ... 65

Figura 46- Posição inicial e final de ensaios experimentais por utilizadores voluntários ... 66

Figura 48- Diagrama do sistema em malha fechada... 72

Figura 49- Identificação dos interruptores na PCI... 75

Figura 50- Identificação das fichas dos motores e bateria... 77

Figura 51- Ligação de alimentação e motores do sistema NAAC ... 78

Figura 52 - Carregamento das baterias da cadeira de rodas ... 78

ÍNDICE DE TABELAS

Tabela 1- Cadeiras de rodas inteligentes ... 7

Tabela 2- Recentes distribuições de ROS... 15

Tabela 3- Parâmetros para a configuração de zonas de risco ... 55

Tabela 4- Resultados práticos método UMBmark ... 61

Tabela 5- Resultados práticos método UMBmark após fator correção ... 62

LISTA DE ACRÓNIMOS

CR - Cadeira robótica

DWA - Dynamic Window Approach GPIO - General purpose input/output

HDMI - High-Definition Multimedia Interface IP - Internet Protocol

LIDAR – Light Detection And Ranging LRF - Laser Rangefinder

NAAC – Navegação Assistida Anti-Colisão PC – Personal Computer

PID - Proporcional Integral Derivativo RAM - Random Access Memory ROS - Robotic Operating System RPi - Raspberry Pi

SD - Secure Digital Card

SLAM - Simultaneous Localization and Mapping SPI - Serial Peripheral Interface

SSH - Secure Shell

TTL - Transistor–Transistor Logic UDP - User Datagram Protocol USB - Universal Serial Port VFF - Virtual Force Field

1. Introdução

1.1. Motivação e Contexto

A falta de mobilidade numa pessoa pode causar grandes dificuldades na realização das mais simples ações do nosso quotidiano. Estas limitações motoras tornam a pessoa muitas vezes dependente da intervenção de terceiros para ajudar na sua deslocação.

No caso de limitações motoras graves nos membros inferiores, as cadeiras de rodas são uma das formas mais utilizadas de auxílio na deslocação. Os modelos motorizados podem ser usados sem muito esforço, sendo particularmente relevantes para pessoas com limitações também nos membros superiores. Ainda assim, os indivíduos com limitações mais severas nos membros superiores podem não conseguir controlar um joystick com a destreza desejada, levando a ineficiência e insegurança na condução. A robotização das cadeiras de rodas pode ajudar a aumentar a segurança da sua utilização ou mesmo possibilitar uma navegação semi-autónoma ou autónoma através de métodos de perceção do ambiente envolvente e do planeamento automático de trajetórias. Existem utilizadores para os quais a robotização das cadeiras de rodas poderá contribuir para uma melhoria da sua independência e consequente aumento da sua qualidade de vida e melhor inclusão na sociedade.

1.2. Objetivos

Pretende-se com este projeto robotizar uma cadeira de rodas elétrica modelo Salsa R2 existente no laboratório VITA.IPT, preservando o seu funcionamento original, nomeadamente o seu sistema de tração e as interfaces de condução (joystick e comando de cabeça). A cadeira de rodas ficará deste modo com dois sistemas a funcionar em paralelo, o original e o implementado neste trabalho de projeto, sendo possível comutar entre eles de forma relativamente simples. A robotização da cadeira de rodas consistiu na implementação de um sistema de segurança integrando um módulo de localização baseado em odometria e um módulo de perceção baseado num sensor Laser Rangefinder (LRF). Estes módulos de

localização e perceção permitem a deteção e mapeamento dos obstáculos envolventes, sendo assim possível a implementação de funções de assistência à navegação da cadeira.

Desta forma os principais objetivos do projeto são:

 Análise dos componentes da cadeira de rodas Salsa R2 a fim de verificar possível integração dos mesmos no projeto de robotização da cadeira

 Desenvolvimento de uma base robótica constituída por interface de condução, controlador de tração e estimação de posição (odometria);

 Desenvolvimento de um sistema de perceção para implementação de um método de navegação reativa.

1.3. Contribuições e trabalho realizado

A principal contribuição desta dissertação é a adaptação de uma cadeira de rodas, dotando-a de um sistema de perceção que possibilita a sua navegação com um sistema reativo de anti-colisão.

A adaptação e robotização da cadeira de rodas Salsa R2 passou por várias fases de desenvolvimento. Após análise do sistema originalmente implementado na cadeira de rodas Salsa R2, verificou-se que o esforço necessário para o reaproveitamento de alguns módulos através de engenharia inversa não seria vantajoso devido à dificuldade em adquirir e processar os dados que circulavam entre os seus periféricos. Esta dificuldade deveu-se ao sistema ser fechado e não serem conhecidos os protocolos de comunicação. Desta forma foi necessário desenvolver e implementar uma solução de raiz para alcançar os objetivos traçados. Fizeram parte desta solução:

 A Implementação de um controlador num microcomputador RPi para a integração da interface de navegação e respetiva comunicação com outros periféricos;

 A integração de encoders para implementação de controlo de velocidade e odometria do sistema;

 A integração de um sensor LRF para perceção local do ambiente;

 A integração de módulos na plataforma ROS (Robotic Operating System) para processamento da informação sensorial e de controlo recorrendo a algumas bibliotecas existentes;

 Implementação de um módulo de navegação reativa anti-colisão.

1.4. Organização da dissertação

O documento encontra-se dividido nos seguintes capítulos:

 Introdução

Este capítulo apresenta uma descrição sucinta do projeto desenvolvido, do seu enquadramento, objetivos e contribuições.

 Estado da Arte e Fundamentos

Apresentação do estado da arte respeitante às temáticas abordadas nesta tese, nomeadamente cadeiras de rodas robotizadas e sistemas baseados na plataforma ROS, assim como alguns fundamentos de sistemas de navegação.

 Arquitetura de Hardware e Software

Neste capítulo são descritas as principais características e funcionalidades dos diversos componentes integrados no desenvolvimento da cadeira robotizada.

 Localização e Navegação

Descrição e desenvolvimento dos métodos aplicados na perceção e análise do meio ambiente circundante que serão utilizados no algoritmo de navegação reativa proposto.

 Integração do sistema na plataforma ROS

Descrição dos vários módulos integrados na plataforma ROS responsáveis pela perceção e navegação do sistema, sua interligação e representação de nós e tópicos associados.

 Ensaios e resultados experimentais

Descrição e apresentação dos ensaios experimentais realizados, permitindo assim documentar e validar os conceitos apresentados no desenvolvimento desta tese.

 Conclusões e trabalho futuro

Apresentação das conclusões obtidas no desenvolvimento da tese, assim como propostas de trabalhos a desenvolver para melhorar o desenvolvimento realizado.

2. Estado da Arte e Fundamentos

2.1. Cadeiras de Rodas Robotizadas

A evolução tecnológica a que temos vindo a assistir tem proporcionado a generalização de sensores e atuadores, tornando economicamente mais viável a sua utilização em aplicações de carácter de assistência na mobilidade a pessoas com limitações motoras ou cognitivas, podendo assim acrescentar grande valor na qualidade de vida dessas pessoas. No caso especifico das cadeiras de rodas, existe já uma grande oferta de cadeiras de rodas motorizadas, dotadas dos mais versáteis interfaces de navegação, específicos ou aconselhados para cada tipo de limitação do utilizador, conseguindo assim estender este tipo de ajuda a outro amplo leque de possíveis utentes.

A evolução da robótica tem permitido o desenvolvimento de vários projetos e aplicações para a assistência do ser humano, nomeadamente o desenvolvimento de sistemas de ajuda na navegação ou mesmo a navegação autónoma de cadeiras de rodas. Apresentamos alguns desses protótipos na secção 2.1.1. Estes projetos, apesar de muito evoluídos e testados experimentalmente carecem ainda de alguma robustez e encontram-se ainda em fases de prototipagem e experimentação laboratorial, não estando assim ainda disponíveis no mercado para comercialização particular. Em 2016 a Singapore-MIT Alliance for Research

and Technology (SMART) implementou com sucesso uma cadeira de rodas inteligente no

“Singapore’s Changi General Hospital” [1], a qual consegue percorrer com sucesso os corredores do hospital. Esta cadeira realiza mapeamento através de três sensores lidar e possui um algoritmo para estimar a sua localização. Possui também seis rodas que lhe fornecem estabilidade e manobrabilidade para realizar navegação através de portas de normal dimensão. Recentemente implementou mais uma cadeira de rodas inteligente no Aeroporto Haneda, em Tóquio [2], tendo incorporado no seu sistema funções de paragem automática no caso de proximidade com obstáculos, navegação autónoma através da seleção de destinos e a possibilidade de deslocação em linha, evitando a esforço do pessoal do aeroporto para a recolha das cadeiras de rodas.

Tem-se verificado também alguns desenvolvimentos de cadeiras de rodas inteligentes baseados em módulos independentes para integração em cadeiras de rodas elétricas, provendo-as assim de funcionalidades suplementares para navegação assistida, como o caso do Smart Wheelchair Component System [3], tendo este protótipo sido já avaliado em quatro cadeiras de rodas de diferentes fabricantes e o Hephatestus Smart

Wheelchair [4] foi desenvolvido a pensar na possibilidade de integração de vários

componente por parte de fabricantes e clínicos para a conversão de cadeiras de rodas elétricas em cadeiras de rodas inteligentes, estando o protótipo montado numa cadeira Everest and

Jennings Lancer 2000.

2.1.1. Projetos de cadeiras de rodas inteligentes

A robotização de cadeiras de rodas tem sido um tema proeminente nos últimos anos, onde se têm verificado vários estudos e desenvolvimento de protótipos, baseados nos mais diversos interfaces, sensores e técnicas de navegação.

Alguns desses projetos e suas principais características encontram-se na Tabela 1, sendo as suas características adequadas a um ou mais grupos de utilizadores atendendo às suas limitações físicas e/ou cognitivas.

Nome e Institução

Sensores Técnologia e metodos Modo de utilização Interface com utilizador RobChair - instituto de sistemas e robótica universidade de Coimbra [33, 5]

LRF, odometria Uso de Mapas de custos métrico, HECTOR SLAM, Planeamento híbrido baseado no A* e planeamento local com desvio de obstáculos, D-DWA (Double-Dynamic Window Approach).

Duas camadas de controlo cooperativo através de navegação com BCI.

BCI síncrono com deteção de estado de não controlo, Joystick, Teclado, SHARIOTO - Katholieke Universiteit Leuven [6] LIDAR (Light Detection And Ranging), Sensores Ultrasons, Giroscópio, Sensores infra-vermelhos

DWA (Dynamic Window Approach) para desvio de obstáculos.

Controlo partilhado com predição de intenção do utilizador baseada em redes bayesianas.

LURCH - Politecnico di Milano [7] Sonar; Sensores infravermelhos, LRF, Odometria Planeamento SPIKE em ambiente conhecido. Comportamento semi-autónomo fornece a solução para tarefas específicas, como entrar numa casa de banho. Em modo automático navega até o objetivo determinado pelo utilizador.

Joystick, Ecrã táctil, interface electromiográfi co, BCI Rolland - Universität Bremen[8] Visão, Sonar, Sensores infravermelhos, Sensor de toque, Odometria Navegação baseada em reconhecimento ótico de marcas. Monitoriza e aprende as características do ambiente enquanto navega, para planeamento trajetórias, Aprende o desvio a obstáculos através de repetições. Joystick VAHM . University Paul Verlaine – Metz [9] Sonar, Sensores Infravermelhos, Odometria .

Filtro de partículas para reconhecimento de caminhos mais frequentes através de mapa topológico existente.

Navegação autónoma através de mapas internos e

navegação semi-autónoma no qual a VAHM desvia de obstáculos e segue paredes.

Joystick

Tabela 1- Cadeiras de rodas inteligentes

2.1.2. Interfaces de condução

A interface de condução é uma componente essencial da cadeira de rodas, pois, tal como o nome indica, faz a interface entre o utilizador e o sistema a controlar. Tem de estar adaptada às necessidades do utilizador, para que este consiga de forma efetiva fornecer comandos de condução. Apresentam-se de seguida as principais interfaces de condução usadas em cadeiras de rodas.

2.1.2.1. Joystick

O Joystick é o interface mais comum neste tipo de veículos robotizados (Figura 1 A.). Este interface não é dispendioso e é bastante fiável, podendo o utilizador selecionar diretamente a direção e quantificar a velocidade pretendida. Existem também joysticks com “force feedback” (Retorno de força) [10], podendo estes dificultar a aproximação a obstáculos através da aplicação de uma resistência ao movimento do manípulo do joystick na direção dos obstáculos, sendo esta força inversamente proporcional à distância a que se encontra o obstáculo. Para limitar algumas possíveis vibrações transmitidas ao interface pelo

utilizador, devido a limitações físicas ou cognitivas, pode ser aplicado um filtro Kalman aos sinais a serem transmitidos do interface [35].

2.1.2.2. Joystick de queixo, controlo de cabeça proporcional e

botoneira

Algumas pessoas possuem limitações físicas que as impossibilita da utilização do

joystick comum, pelo que existem outros tipos de atuadores, tais como os joysticks de queixo

(Figura 1 B.), os atuadores de cabeça ou a botoneira (Figura 1 C.), que são concebidos para lhes fornecer um controlo efetivo sobre o equipamento a manusear.

Podemos descrever os Joysticks de queixo basicamente como adaptadores de interligação entre o queixo do utilizador e um joystick, sendo aplicável a utilizadores que possuam deficiência nos membros superiores que os impossibilitam de manipulação de um

joystick. Para utilizadores que não possuam coordenação motora fina pode ser instalado

como interface uma botoneira, que pela simples disposição de botões com funções específicas ou um simples botão com atuação codificada, isto é, com código Morse ou uma codificação mais simples, são selecionados os comandos a enviar à cadeira. No caso do controlador de cabeça proporcional, é através da proximidade ou contacto com sensores situados no encosto da zona posterior da cabeça e nas abas laterais do suporte, que são enviadas as ordens de acionamento, sendo também possível inverter o sentido de marcha através da atuação do sensor posterior.

Figura 1- Dispositivos de controlo para cadeiras de rodas elétricas.A) Joystick de operação manual. B) Joystick adaptado de queixo. C) Botoneira. D)Tubo de sopro e sucção[11]

2.1.2.3. Tubo sopro e sucção

Para utilizadores que possuam incapacidade física de manipulação existem interfaces como o tubo de sopro e sucção (Figura 1 D.), que através de pressão ou depressão registada envia comandos para o movimento da cadeira. Estes equipamentos podem ser calibrados para cada utilizador específico através do ajuste de alguns parâmetros de pressão no controlador [12].

2.1.2.4. Ecrã táctil

Em certas situações pode não ser possível o uso de Joystick pelo utilizador, podendo existir um interface (gráfico por exemplo) através de um ecrã táctil com sectores de direção definida, permitindo a sua fácil seleção [13], ou até noutros casos, com mapas implementados, devendo o utilizador escolher destinos previamente selecionados, localizações em mapas estáticos ou mesmo dinâmicos, permitindo assim a seleção do destino pretendido através de um toque na zona da posição desejada [14].

2.1.2.5. Interfaces cérebro-computador

Este interface tem como potencial alvos pessoas com severas limitações motoras, sendo os comandos obtidos através da deteção de sinais elétricos no cérebro do utilizador. De momento este tipo de interfaces ainda se encontra em investigação, sendo normalmente a sua aplicação feita com algum tipo de controlo partilhado ou colaborativo para permitir uma navegação segura e com um nível aceitável de eficiência mesmo quando os comandos são esparsos e até pouco fiáveis [15, 33].

2.2. Perceção e planeamento de caminhos

A integração de perceção e localização nas cadeiras de rodas permite a estas aumentarem o seu nível de autonomia na navegação (entre semi-autónoma a completamente autónoma), o que pode representar grande relevância para utilizadores com níveis severos de incapacidade motora. A perceção pode ser realizada através de vários tipos de sensores, passivos ou ativos, que permitem a recolha de dados do ambiente envolvente, podendo-se assim tomar as respetivas ações necessárias ou desejadas. Os sensores usualmente mais utilizados são os LRF, LIDAR, sonar ou mesmo de visão, os quais permitem uma área de perceção abrangente com informação suficiente para tomada de decisões sobre ações de navegação a realizar. Esta perceção permite a aplicação de métodos de navegação local como o VFF (Virtual Force Field) [16] e o DWA (Dynamic Window Approach) [17]. Por serem dois métodos relacionados com a abordagem de navegação anti-colisão implementada neste trabalho, iremos descrevê-los de seguida.

O método VFF usa uma grelha bidimensional de tamanho fixo para representar o mundo, desta forma a mesma encontra-se centrada no robô, sendo atualizados os valores das suas células de acordo com o deslocamento da base robótica. Cada célula armazena um valor de certeza de ocupação C(i,j) por um objeto o qual é atualizado por cada varrimento do sensor, sendo o valor de certeza C(i,j) incrementado se a célula se mantiver ocupada no mesmo eixo acústico e na mesma distância a que se encontrava anteriormente.

Figura 2- Projeção bidimensional de campo de visão e resposta probabilística considerando leituras obtidas por sonar [18]

Para cada célula, é calculada uma força repulsiva, F(i,j), sendo esta diretamente proporcional ao valor de certeza e inversamente proporcional à distância ao robô. O O somatório destas forças resultam numa força de repulsão, Fr, causada pelos obstáculos existentes. É também calculada uma força de atração, Fa, de acordo com a distância ao objetivo selecionado. As constante Fcr e Fct são parâmetro de ponderação das forças de repulsão e atração. 𝐹(𝑖, 𝑗) = 𝐹𝑐𝑟 𝐶(𝑖, 𝑗) 𝑑2_{(𝑖, 𝑗)} ( 𝑥_𝑖 − 𝑥₀ 𝑑(𝑖, 𝑗) , 𝑦_𝑖 − 𝑦₀ 𝑑(𝑖, 𝑗) ) ( 1 ) Onde

C(i,j) – valor de certeza de ocupação da célula (i,j) d(i,j) – distância entre a célula (i,j) e o robô

xi, yi – posição da célula (i,j)

x0, y0 – posição do robô 𝐹𝑟 = ∑ 𝐹(𝑖, 𝑗) 𝑖,𝑗 ( 2 ) 𝐹𝑎 = 𝐹𝑐𝑡 ( 𝑥_𝑡− 𝑥₀ 𝑑 , 𝑦_𝑡− 𝑦₀ 𝑑 ) ( 3 )

Através da soma destas duas forças obtemos a força resultante que indicará a direção a ser aplicada ao robô conforme exemplificado pela Figura 3

Figura 3- Exemplo de campos potenciais aplicados num robô [18]

O método DWA [17] obtém as velocidades de controlo a enviar para o robô diretamente através da análise das possíveis velocidades no espaço envolvente. O campo de dados para análise é reduzido ao verificarmos apenas as velocidades possíveis de acordo com a dinâmica do robô. No primeiro passo desta análise são apenas consideradas velocidades seguras para as possíveis trajetórias, isto é, velocidades que realizem um deslocamento onde não seja possível a ocorrência de colisão, sendo no passo seguinte verificada qual a velocidade que maximiza a função para o objetivo pretendido.

Pela aplicação de uma velocidade (𝑣, 𝜔) ao robô, são realizados pequenos deslocamentos que descrevem uma trajetória circular, sendo que cada trajetória circular pode apenas ser definida por um único vetor de velocidade (𝑣, 𝜔). No caso de existência de obstáculos perto do robô, irão ocorrer restrições às velocidades lineares e angulares, sendo a velocidade máxima admissível do robô calculada através da distância ao obstáculo nesta trajetória circular.

Assim, sendo o termo dist(𝑣, 𝜔) representativo da distância correspondente ao obstáculo mais perto quando aplicada a velocidade (𝑣, 𝜔), tendo como valores de desaceleração/travagem 𝑣𝑡̇ e 𝜔̇𝑡 e podemos calcular as velocidades admissiveis Va, sabendo que apenas serão consideradas admissiveis se o robô se conseguir imobilizar antes de atingir o obstáculo:

V_a = { (𝑣, 𝜔) | 𝑣 ≤ √2. 𝑑𝑖𝑠𝑡(𝑣, 𝜔). 𝑣_𝑡̇ ∧ 𝜔 ≤ √2. 𝑑𝑖𝑠𝑡(𝑣, 𝜔). 𝜔̇ } _𝑡 ( 5 )

Tendo em conta os possíveis valores de aceleração dos motores, o espaço de análise pode ser reduzido apenas ao espaço atingível no próximo intervalo de tempo t. Sendo as acelerações 𝑣̇_𝑎𝑐 e 𝜔̇_𝑎𝑐 e sendo (𝑣_𝑎𝑡, 𝜔_𝑎𝑡) a velocidade atual podemos determinar as velocidades 𝑉𝑑 que pertencem à janela dinâmica como

𝑉𝑑= {(𝑣, 𝜔)|𝑣 ∈ [𝑣𝑎𝑡− 𝑣̇𝑎𝑐. 𝑡, 𝑣𝑎𝑡+ 𝑣̇𝑎𝑐. 𝑡] ∧ 𝜔 ∈ [𝜔𝑎𝑡− 𝜔̇𝑎𝑐. 𝑡, 𝜔𝑎𝑡+ 𝜔̇𝑎𝑐. 𝑡]} ( 6 )

Na Figura 4 podemos verificar um exemplo da janela dinâmica calculada com os pressupostos anteriormente referidos.

Através das restrições definidas e sabendo que Vs é o conjunto de velocidades que permitem percorrer o espaço de percepção para atingir o objetivo pretendido, podemos realizar a intersecção dos vários resultados, obtendo assim um conjunto de velocidades resultantes Vr, as quais realizam um deslocamento permitido sem colisão (área branca representada na Figura 4), para posterior análise de maximização de acordo com a localização do objectivo a alcançar.

Vr = Vs ∩ Va ∩ Vd ( 7 )

Para maximizar a função do objetivo serão incorporados nas velocidade resultantes Vr os critérios de direção, distância e velocidade com as respetivas ponderações 𝛼, β e 𝛾 ajustadas de acordo com as especificidades do projeto da seguinte forma:

𝐺(𝒗, 𝝎) = 𝜎(𝛼 . 𝑑𝑖𝑟𝑒çã𝑜(𝒗, 𝝎) + 𝛽. 𝑑𝑖𝑠𝑡â𝑛𝑐𝑖𝑎(𝒗, 𝝎) + 𝛾. 𝑣𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑𝑒(𝒗, 𝝎))

( 8 )

Sendo a função 𝑑𝑖𝑟𝑒çã𝑜(𝒗, 𝝎) responsável pela medição da progressão do robô em direção ao objectivo a atingir, a função 𝑑𝑖𝑠𝑡â𝑛𝑐𝑖𝑎(𝒗, 𝝎) responsável por verificar a distância do arco da trajetória ao obstáculo mais perto, sendo que a menor distância ao objeto implica a maior intenção de se afastar do mesmo. A função 𝑣𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑𝑒(𝒗, 𝝎) representa a velocidade do robô. O termo σ é aplicado para suavizar a soma ponderada das três funções descritas

2.3. ROS – Robotic Operating Systems

O ROS [19] foi a camada middleware escolhida para a implementação do nosso projecto. A função desta camada é permitir o agrupamento de vários periféricos e funções sem a necessidade de desenvolvimento de software específico para os mesmos. A título de exemplo existem também os seguintes middleware: Player Project; RT – Middleware Projects; Urbi e Micro entre outros.

O ROS é um sistema operativo desenvolvido com base em Linux, especialmente dedicado a aplicações robóticas. Este é baseado numa plataforma de OpenSource disponibilizando várias interfaces e funções, amplamente ensaiadas e funcionais, que nos permitem uma fácil integração e interação entre os vários sensores, atuadores e manipulação de dados necessários, evitando assim todo o esforço de desenvolvimento de software já existente.

O ROS teve a sua primeira versão em 2010 com a distribuição Box Turtle, tendo lançado até á data 9 novas versões, estando identificadas as quatro últimas na Tabela 2, sendo a mais recente a ROS Kinetic Kame.

Distro Release date Poster Tuturtle, turtle in

tutorial EOL date

ROS Kinetic Kame

(Recommended) May 23rd, 2016 May, 2021

ROS Jade Turtle May 23rd, 2015 May, 2017

ROS Indigo Igloo July 22nd, 2014

April, 2019 (Trusty EOL) ROS Hydro Medusa September 4th, 2013 May, 2015

Tabela 2- Recentes distribuições de ROS

O ROS baseia-se no conceito da criação de pacotes de software dedicados a cada projeto ou aplicação. A partilha de informação entre os diversos participantes do projeto é feita através de nós que publicam e subscrevem a informação (mensagem) necessária organizadas por tópicos, conforme exemplificado na Figura 5, ficando esta acessível a outros participantes que necessitem ou queiram partilhar informação sobre os mesmos tópicos.

Figura 5- Estrutura de Nós e Tópicos - ROS

O desenvolvimento dos programas podem ser realizados em C++, Phyton ou Lisp. Devido à escalabilidade possível através do ROS, este é apropriado para o desenvolvimento de sistemas complexos e dimensão, sendo este software usado por grandes empresas como a DARPA e a Softbank Robotics.

Em 2010 a Softbanks Robotic utilizou o seu robô humanoide Osiris para permitir realizar o desenvolvimento da localização do robô em ambientes complexos Este robô tem 58cm e incorpora um LSR no topo da cabeça, tendo sido usado também para o desenvolvimento dos movimentos de subir escadas e a imitação de vários movimentos humanos exemplificados na Figura 6. Devido aos movimentos exercidos pelo corpo na sua deslocação torna-se bastante mais difícil a correta perceção da localização e mapeamento. Através da aplicação de novos métodos e de leituras dos dados recolhidos de vários sensores que o robô tem integrado, tais como do laser, da odometria, do IMU e dos dados propriocepção, foi possível obter a localização 6D do torso do Osiris, realizando assim o mapeamento do mesmo. Foi assim desenvolvida na Universidade de Freiburg uma plataforma de navegação para esta classe de robôs, a qual incluía uma biblioteca sobre os movimentos de caminhar.

Neste momento a Softbanks Banks possui o projeto Romeo, tratando-se de um robô humanoide de 1,40 m com perceção multissensorial permitindo a sua interação com o ambiente circundante, realizando interação física e cognitiva com humanos (Figura 7).

Figura 7- Romeo - Aldbaran e SoftBank Robotics [34]

Na última distribuição Kinetic Kame encontram-se já implementadas as primeiras versões de pacotes de software de piloto automático para drones desenvolvido em ROS nativo, os quais incluem pacotes de navegação, mapeamento, desvio de obstáculos e outros. Este pacote de software pode ser aplicado quer a drones para corridas, quer a drones para

transporte de carga, sendo que os diferentes blocos de software comunicam usando a arquitetura de publicação e subscrição de mensagens.

3. Arquitetura de Hardware e Software

Neste capítulo encontram-se descritos os principais elementos que compõe o sistema, estando os principais módulos identificados na Figura 8.

Figura 8- Arquitetura do sistema

3.1. Plataforma base – Salsa R2

Como plataforma base para o desenvolvimento deste projeto, foi utilizada uma cadeira de rodas elétrica modelo Salsa R2 (Figura 9), existente no laboratório VITA.IPT. Esta cadeira possui uma estrutura onde é possível incorporar vários tipos de assentos inclináveis, assim como configurar vários tipos de interfaces para o utilizador, conseguindo assim obter o melhor desempenho de acordo com as necessidades de cada utilizador.

Os vários módulos constituintes dos circuitos de comando e controlo da Salsa R2 encontram-se interligados de acordo com o esquema apresentado na Figura 10.

Figura 10- Diagrama principal de ligações VR2 and RNET[20]

Este sistema é constituído por duas baterias de 12 V ligadas em série para o fornecimento de 24 V ao módulo de potência VR2-90. Neste módulo estão incorporadas as ligações de potência aos motores e também um barramento Tyco que interliga vários dispositivos de controlo, como o joystick (VR2 Hand Control) e o interface de configuração do sistema (VR2 Attendant Hand Control). Encontra-se também neste sistema um controlador de cabeça, atuado por contacto/pressão de sensores localizados nas partes

laterais e traseira do mesmo. Integrado no sistema existe uma tomada para ligação de um carregador de baterias externo, permitindo assim o seu carregamento e a reposição da sua autonomia.

O barramento Tyco é composto por 1 par de linhas de alimentação de 24V e outro de comunicação, realizando assim a interligação de todos os seus módulos. Devido a este sistema ser um sistema comercial e não serem disponibilizadas pelo fabricante as especificações técnicas sobre o protocolo aplicado neste barramento, não foi possível a descodificação do mesmo para utilização dos módulos existentes (e.g., joystick) e integração dos mesmos no projeto. Pela análise destes módulos podemos constatar que os mesmos possuem processadores internos, conforme ilustrado na Figura 11, o que torna mais complexa a análise de dados existentes no barramento, devido ao vasto processamento interno realizado por cada equipamento, tendo inviabilizado o procedimento de engenharia inversa.

Figura 11- Microprocessadores do módulo de potência e do módulo de Joystick

3.2. Robotização da cadeira de rodas elétrica

Dados os constrangimentos referidos na secção anterior, optou-se por implementar uma arquitetura completamente nova, mantendo o sistema original montado na cadeira completamente funcional. A nova arquitetura de aquisição sensorial e comando da cadeira de rodas encontra-se na Figura 12.

Roboteq MDC2230 Raspberry Pi Bateria 12V Bateria 12V Motor Esquerda Motor Direita Joytick MCP3002 MAX3232 SPI Ethernet 0 192.168.137.0 Porta 575 TTL serial RS - 232 Enc. 1 Enc. 2

Interface Homem Máquina

Hokuyo LRF USB DC/DC 24V / 12V DC/DC 24V / 5V PC ROS 24 v

Figura 12- Estrutura de implementação da cadeira de rodas robótica

A alimentação do nosso sistema é assegurada pelas duas baterias da Cadeira Salsa R2 ligadas em série, fornecendo assim 24 V DC ao controlador de potência MDC2230, e aos dois conversores DC/DC de 5V e 12V que fornecem energia ao RPi e ao LRF, respetivamente,

O módulo Roboteq MDC2230 é o responsável pelo controlo de tração, comandando assim os dois motores da Sunrise Medical, onde foram mecanicamente incorporados os sensores taquimétricos. A alimentação e processamento dos sinais dos encoders também é responsabilidade do módulo Roboteq.

Para a interface de condução foi integrado um joystick resistivo e um conversor Analógico/Digital para ler a informação do joystick uma vez que o RPi não possui entradas analógicas para ligação direta a este dispositivo. O módulo RPi é o responsável pela receção de comandos do módulo de interface e envio dos comandos para o controlador MDC3220, sendo esta comunicação realizada através de uma ligação série. Para a realização da ligação série foi necessário introduzir um conversor RS232- TTL MAX3232 [21] para

compatibilizar os sinais entre ambos os equipamentos. O RPi recebe os comandos diretamente do joystick, transmitindo-os ao controlador de tração no modo livre ou ao módulo de navegação anti-colisão, através de uma ligação Ethernet que encapsula os pacotes UDP, que se encontra a correr no PC.

O módulo de navegação anti-colisão está implementado no sistema ROS, sendo, responsável pelo tratamento e validação das velocidades aplicar ao sistema. Esta análise é realizada através dos dados recebidos do sensor LRF Hokuyo diretamente ligado ao PC.

3.2.1. Raspberry Pi 1 Model B

O Raspberry Pi (RPi) é um microcomputador baseado num processador 700 MHz ARM1176JZF-S core o qual integra 512 Mb de RAM. Possui duas portas USB, 1 porta Ethernet e uma saída HDMI entre outras. Possui também um slot para cartão SD onde se encontra instalado o sistema operativo Debian baseado em Linux.

Figura 13- Raspberry Pi 1 Modelo B [22]

A alimentação do RPi é feita através da ficha micro-usb presente na placa, não estando esta ligação preparada para a transferência de dados. O RPi possui também um conjunto de pinos de entrada/saída de designação GPIO (General purpose input/output) de uso geral, cuja funcionalidade se encontra identificada na Figura 14. Alguns destes pinos têm associado funções específicas as quais algumas foram implementadas no nosso sistema conforme será descrito de seguida.

Figura 14- GPIO Pinout do RPi

A comunicação realizada para o módulo de potência é realizada através dos pinos de comunicação série GPIO 15 e 16 do RPi. Devido ao níveis de tensão na porta série do RPi serem do tipo TTL (Transistor-Transistor Logic), isto é, o valor digital 0 e 1 são representados por valores de tensão de 0V e +5V respetivamente, é necessário converter estes sinais para o standard RS232 de -15V e + 15V (0 e 1 lógico respectivamente). Assim foi necessária a implementação de um conversor TTL – RS232 realizado com o integrado MAX3232 para estabelecer a comunicação com o módulo de potência. Os parâmetros da comunicação como baudrate, número de bits e paridade são programados através de

software.

Aos pinos GPIO 10, 12, 13 e 14 do RPi está associada a comunicação SPI cujas configurações de comunicação, tal como no caso anterior, são realizadas ao nível da programação do software.

Outra interface realizada pelo RPi é a comunicação com o computador que será responsável pelo processamento da odometria e assistência á navegação. Esta interface é realizada através da rede Ethernet, tendo sido parametrizado o IP do RPi definido de forma como estática (192.168.1.5) a fim de se ligar diretamente à rede do computador.

3.2.2. Joystick

Foi inicialmente proposto a utilização de um Pretorian Technologies n-ABLER

Joystick, tendo-se verificado após a implementação que o mesmo possui uma baixa

resolução nos valores de comando, não sendo assim aconselhável à nossa aplicação. Desta forma optamos pela integração de um Keyes-SJoys Joystick (Figura 15), mais acessível e económico, constituído apenas por dois potenciómetros e um interruptor de pressão. Podendo ser alimentado por 5 ou 3.3 V, tendo valores de saída entre Vcc e GND.

Figura 15- Joystick Keyes_SJoys

Devido ao RPi não possuir entradas analógicas, optámos por intercalar um integrado MCP3002 – Conversor A/D 10 bit de dois canais com ligação Serial Peripheral Interface (SPI). Na Figura 16 está exemplificada a troca de dados existentes no bus, sendo o DIN os dados de seleção de canal enviados pelo RPi e DOUT o sinal analógico codificado a 10 Bit. Através da comunicação SPI é possível interligar diretamente o integrado e as respetivos pinos de comunicação do RPi, tendo apenas sido desenvolvida uma nova biblioteca para correta leitura dos dados entre ambos os equipamentos.

Figura 16- Sincronismo série MCP3002 [23]

Para evitar tendências e pequenos desvios provocados por características próprias do

joystick, foi implementada, ao nível de programação, uma pequena calibração e mapeamento

dos valores obtidos do conversor MCP3002, de 0 a 1024 para -1000 a 1000, aplicando uma zona morta entre os valores -20 e 20.

3.2.3. Roboteq MDC2230

O Roboteq MDC2230 (Figura 17), é um controlador de motor desenvolvido para receber comandos através de várias interfaces de comunicação: Série, CAN, Radio,

wireless, etc. e ativar as saídas de potência para controlo de um ou dois motores de corrente

contínua. No nosso projeto optámos por usar a comunicação série RS232 como canal de comunicação com o RPi.

Este controlador para disponibiliza várias funções implementadas no seu hardware que permitem o utilizador configurar facilmente o controlador [25]. Através da ligação USB ao computador e com o programa Roborun+ foram configuradas e programadas ações de segurança como watchdogs, supervisão de tensão e correntes; parâmetros de configuração como velocidade máxima, aceleração máxima, impulsos por rotação; valores de controlo como velocidade dos motores, número de impulsos dos encoders, valores de tensão, etc.

Figura 17- Roboteq MDC2230 [24]

O comando das saídas de potência podem ser realizadas individualmente pelo canal 1 e Canal 2 como comandos independentes para cada motor ou podem ser comandadas, conforme optado por nós, em modo misto, sendo o canal 1 responsável pelo comando da velocidade linear e o canal dois responsável pelo comando da velocidade angular.

Para garantir a segurança do utilizador foi implementada uma botoneira de emergência conforme referido no manual do controlador e identificado na Figura 18. Caso esta emergência seja acionada deve ser reiniciado o controlador.

Outra funcionalidade também importante e disponível no Roboteq é a possibilidade de controlo em malha fechada PID, podendo esta função ser realizada em controlo de velocidade ou posição. Para o nosso projeto o controlador foi configurado para controlo de velocidade de malha fechada, tendo sido obtidos pelo método experimental os seguintes valores que se encontram desenvolvidos no Anexo I:

GDC = 0.85 τ= 0,69 s ( 9 )

Tendo sido obtidos os valores para o controlador de:

Proporcional : Kp=1.63 Integral : ki=2.61 Diferencial : Kd= 0.45 ( 10 )

Através da ligação USB disponível no controlador Roboteq e da aplicação Roborun+ é também possível simular e monitorizar o desempenho do controlador e dos motores com o computador.

3.2.4. Motores e Encoders

Os motores utilizados no projeto são os que já se encontravam na cadeira Salsa R2. São motores de 22.5V DC com uma caixa de engrenagem integrada de relação 1:26 e de 163 rpm. Verificámos que os motores em causa não possuíam encoders, pelo que foi necessário estudar a forma de aplicação destes sensores nos motores. Desta forma foi decidido remover os freios eletromagnéticos para ser possível aceder ao eixo de rotação do motor para acoplar o sensor (Figura 19). Verificámos que é necessário os freios eletromagnéticos permanecerem ligados ao sistema original para o mesmo continuar funcional sem falhas, tendo os freios sido ligados mas não acoplados aos motores.

Figura 19- Desmontagem de freio eletromagnético e aplicação de encoder no veio do motor

Devido ao tamanho disponível do veio para aplicação dos encoders e aos campos eletromagnéticos ali existentes, optamos pela aplicação de encoders capacitivos AMT103-V [26].

Figura 20- Encoder AMT103-V [26]

Estes encoders são bastante versáteis, pois são fornecidos com uma base de montagem e um kit de adaptadores conforme ilustrado na Figura 20, permitindo o correto ajuste ao veio para aplicação do encoder. É também possível configurar os impulsos por revolução através da configuração de um “dip switch” existente no encoder. No caso do nosso modelo estes valores são configuráveis de 48 a 2048 ppr, tendo sido configurado para 1024 ppr.

3.2.5. Hokuyo UTM-30LX Laser Rangefinder

Para implementação do Sistema de perceção foi usado um laser Rangefinder Hokuyo UTM-30LX [27] (Figura 21). Este LRF tem uma alimentação de 12V DC e realiza um varrimento de 270º com alcance de 30 m em 25 ms, sendo um modelo leve e compacto, com uma resolução angular de 0,25º, tendo uma precisão de ± 30mm de 0,1 a 10m e ± 50mm de 10 a 30m de distância.

Figura 21- Hokuyo UTM-30LX [27]

Para adaptar o LRF à cadeira de rodas foi analisado qual o melhor local para montagem do mesmo, evitando possíveis impactos e vibrações. Desta forma optamos por colocar o LRF nas barras de suporte dos apoios de pés existentes na cadeira, conforme Figura 22, permitindo desta forma realizar um varrimento superior a 180 º sem obstáculos provenientes do utilizador.

3.2.6. Placa de alimentação e interligação de periféricos

Para melhor acondicionamento e integração dos componentes periféricos foi construída uma placa para montagem dos conversores DC/DC que servem de fonte de alimentação aos módulos de Laser (12 V) e ao RPi (5 V), assim como a placa de circuito impresso onde se encontram as fichas de ligação ao controlador Roboteq e os vários interruptores para isolamento das respetivas alimentações envolvidas. Na placa de circuito impresso foram também implementados dois led´s sinalizadores: sistema em funcionamento (Vermelho intermitente) e Sistema de navegação assistida ativo (Azul). A placa e respetivo esquemático encontram-se respetivamente nas Figura 23 e Figura 24.

Figura 23- Esquema elétrico da placa circuito impresso

3.2.7. Notebook Asus F200M

Foi definido que o processamento de dados relacionados com a navegação iriam ser realizados através de sistema ROS, pelo que se tornou necessário o uso de um notebook, optando-se por um Asus F200M, Figura 25, já existente no Laboratório VITA.IPT com sistema operativo Ubuntu 12.4 de 64bits, onde foi instalada a versão Hydro do ROS.

Este notebook de 11,6’’ possui um processador Intel Celeron N2830 de 2.4GHz, estando equipado com 2 GB de RAM e um disco de 500 GB. Tem duas portas USB 2.0 e uma USB 3.0, sendo uma usada para ligar o nosso LRF, uma porta Ethernet, usada para realizar a ligação ao RPi. Possui ainda portas HDMI e VGA, assim como ligação Bluetooth e Wifi.

Figura 25- Asus F200M

3.3. Arquitetura de software

A fim de tornar este projeto num sistema modular, ao qual seja possível interligar outros módulos ou funcionalidades, foi desenvolvido no RPi o software responsável pela leitura do joystick, envio de comandos de velocidade para o controlador de potência Roboteq, obtenção de dados do mesmo controlador e processamento de dados para envio à aplicação externa através da porta Ethernet, no nosso caso, para o ROS, conforme ilustrado na Figura 26.

Foi implementada a seguinte estrutura a fim de otimizar a programação necessária:

Raspberry

Main()

Joytick

MPC3002 adc; Vector <int> values Joystick(); Int x(); Int y(); Normalize(); Read_norm(); MDC2230 String USBport; Int baudrate; SerialPort serial; MDC2230(port,baudrate); Open(watchdog); Close(); IssueQuery(Query); IssueCommand(command); SetEncoders(Motor1,Motor2); ReadEncoderCountRelative(); Salsa Pose Odometry; double PPRevolution; double b; double R; double Vx; double W; Wheelchair(); double getVx(); double getW(); Update(); MCP3002 Char mode; Char bitsPerWord; Int speed; Int spifd; MCP3002(devspi,…) spiOpen(devspi); spiClose(); spiWriteRead(); SerialPort Int fd; Int baudrate; String port SerialPort(); Open(port,baudrate); Close(); Int Write(data); Int Read(max_length); Int flush(); Pose double X; double Y; double Teta Pose(); → Mensagem dados ← Comandos Velocidade Ethernet 0

Figura 26- Estrutura do Software no RPi

O desenvolvimento do módulo Joystick permite-nos a substituição do joystick por outro controlador analógico, cujo ponto de repouso seja o valor central do mesmo, sendo o seu valor lido e enviado pelo módulo “MCP3002”. O módulo software “MPC3002” foi desenvolvido para realizar a leitura analógica do dos dois canais do joystick e enviar os seus valores através de comunicação SPI para o RPi. A seleção do canal a ser lido é codificada no comando de leitura enviado pelo RPi para o conversor, sendo realizada a transferência de 2 bytes por leitura de canal, sendo o sinal analógico codificado em 10 bits.

A classe “SerialPort” foi implementada para comunicação com o controlador de potência, podendo assim enviar comandos e receber estados, permitindo o controlo da tração do nosso objeto “Salsa”, sendo alguns dados recebidos do controlador de potência partilhados com a classe “Pose” para cálculo da posição e deslocamento da base robótica. A porta série atribuída para esta comunicação foi "/dev/ttyACM0" com a seguinte configuração: • 115200 bits/s • 8-bit data • 1 Start bit • 1 Stop bit • Sem Parity

Neste módulo foi também implementado um canal de comunicação Ethernet, com configuração de IP estático 192.168.1.2 porta:5171, para comunicação com o PC Asus e respetivo software ROS

Foram também configuradas as entradas e saídas do módulo GPIO (general purpose

input/output) com as seguintes funcionalidades

 PIN GPIO 2 – Input – Este pino foi configurado como a entrada do seletor de modo de navegação Livre / Sistema de Anti Colisão. Este seletor está á disposição do utilizador para realização de manobras sem perceção do ambiente pelo sistema.

 PIN GPIO 0 – Output – Neste pino foi implementado um led azul para sinalização da navegação assistida ativa.

 PIN GPIO 7 – Output - Devido ao RPi não possuir nenhum elemento de interface de visualização de funcionamento, foi implementado um led nesta saída que nos permite verificar se o código se encontra em correto funcionamento através da sua presença intermitente a uma baixa frequência. Caso não se verifique esta comutação de estado do led, indica que o software dedicado se encontra inativo.

3.4.

Fluxograma de software do controlador RPi

4. Localização e Navegação

4.1. Odometria para robôs diferenciais

A odometria é um dos métodos mais utilizados para estimar a posição de um robô, o qual se baseia na integração incremental do movimento do robô ao longo do tempo, causando por este facto uma inevitável acumulação de erros, sendo de qualquer forma considerada uma parte muito importante na navegação do robô [28].

4.1.1. Modelo dinâmico

Os robôs diferenciais são robôs que possuem controlo independente sobre cada uma das duas rodas motrizes. Com a aplicação de igual velocidade de rotação a ambas as rodas o robô desloca-se para a frente, enquanto a mudança de direção é realizada por aplicação de velocidade de rotação superior à roda contrária da direção a tomar.

Devido a estas caraterísticas, é mais eficaz o envio de comandos ao controlo de tração por velocidades angulares das rodas esquerda e direita, 𝜔e e 𝜔d, do que comandos de velocidade linear e angular.

Através da velocidade de rotação das rodas (𝜔e ou 𝜔d) e do seu raio (r) podemos obter a sua velocidade linear, Ve/d = r 𝜔e/d. No caso de apenas a roda esquerda ter rotação, encontrando-se a roda direita parada, e devido ao ponto P se encontrar a meio do eixo das duas rodas, conforme ilustrado pela Figura 28, podemos verificar que o contributo da roda esquerda no deslocamento linear Vx do robô é Vx = (1/2).Ve. Devido a não existir deslocamento lateral nas rodas o valor de velocidade na direção Vy é sempre nulo. Assim, sendo d a distância entre rodas e R o raio de curvatura do robô temos:

𝑉𝑒 = 𝜔𝑒 (𝑅 − 𝑑 2 ) 𝑉𝑑 = 𝜔𝑑 (𝑅 + 𝑑 2 ) ( 11 ) 𝜔𝑒 = 𝑉𝑒 𝑅 − 𝑑 2 𝜔𝑑 = 𝑉𝑑 𝑅+ 𝑑 2 ( 12 )

No caso de robôs diferenciais estas contribuições de cada roda para o deslocamento podem ser somadas.

𝜔 = 𝑉𝑑 − 𝑉𝑒

𝑑 𝑉 =

𝑉𝑑 + 𝑉𝑒

2 _{( 13 )}

4.1.2. Equações cinemáticas

Considere que o robô se encontra na posição arbitrária P (qc) [xc yc θc] encontrando-se o encontrando-seu objetivo na posição R (qd) [xd yd θd]. O seu sistema de coordenadas é gerido pela ação conjunta da velocidade linear v e da velocidade angular ω, podendo desta forma representá-las de forma cartesiana em relação à origem por

ẋ = v . cos Ө ( 14 )

ẏ = v . sen Ө ( 15 )

𝜃̇ = 𝜔 ( 16 )

Onde ẋ e ẏ são as componentes de v ao longo dos respetivos eixos e θ o seu ângulo.

4.1.3. Odometria

A localização é um dos aspetos mais importantes de um robô. É através do conhecimento da posição que o robô pode facilmente deslocar-se para o seu destino. Existem vários métodos para realizar a medição de deslocamento realizado pelo robô mas iremos descrever o método baseado na aquisição de impulsos dos encoders dos motores, que nos fornecem a rotação das rodas. A posição do robô é calculada com integração da rotação das rodas pela aproximação do seu modelo cinemático no intervalo [𝑡_𝑘, 𝑡_𝑘+1].

Assumindo o robô na posição q_𝑘 [𝑥_𝑘 𝑦_𝑘 θ_𝑘] e as velocidades constantes de 𝑣_𝑘 e 𝑤_𝑘 são conhecidas em 𝑡𝑘, e sendo 𝑇𝑠 o tempo de amostragem, então pela integração de Euler

𝑥_𝑘+1 = 𝑥_𝑘 + 𝑣_𝑘 𝑇_𝑠 cos θk ( 17) 𝑦_𝑘+1= 𝑦_𝑘 + 𝑣_𝑘 𝑇_𝑠 sen θk ( 18) θ𝑘+1= θ𝑘 + 𝑤𝑘𝑇𝑠 ( 19 ) onde 𝑣_𝑘 𝑇_𝑠 = Δs e 𝑤_𝑘𝑇_𝑠 = Δθ ( 20 ) 𝑇_𝑠 = 𝑡_𝑘+1 - 𝑡_𝑘 ( 21 )

Sendo Δφ_𝑒 e Δφ_𝑑 o número de rotações das rodas esquerda e direita medidas num intervalo de tempo 𝑇_𝑠, r o raio das rodas e d a distância axial entre rodas, obtemos assim o deslocamento linear e angular

𝛥𝑠 =𝑟

2 ( Δφ𝑑+ Δφ𝑒 ) 𝛥𝜃 = 𝑟

𝑑 ( Δφ𝑑− Δφ𝑒 ) ( 22 )

A posição de um robô diferencial pode ser estimada através da integração do seu movimento, podendo ser calculada para o tempo 𝑡_𝑘

[ x_k y_k 𝜃_𝑘 ] = [ x_k−1 y_k−1 𝜃_𝑘−1 ] + [ cos 𝜃 0 𝑠𝑒𝑛 𝜃 0 0 1 ] [𝛥𝑠 𝛥𝜃] ( 23 )

4.2. Procedimento de verificação e calibração UMBmark

Devido a erros existentes no modelo do robô, tais como diferença de diâmetro de rodas, desalinhamento de eixo ou mesmo capacidade de medição limitada, podem ser introduzidos erros no cálculo da odometria e respetiva pose do robô. Desta forma foi desenvolvido o método de verificação e calibração designado por UMBmark [29].

4.2.1. Procedimento de verificação

Este procedimento é realizado através de repetidos ensaios de execução de um percurso padrão previamente conhecido e aferido, por exemplo um quadrado de 4x4 m de comprimento, percorrendo-o nos dois sentidos de rotação possíveis (cw e ccw), a fim de verificar a ocorrência de desvios e respetiva quantificação.

Definindo os valores Xabs e Yabs como as posições finais do ensaio com referência a X e Y, e definindo como Xcalc e Ycalc os valores calculados na odometria, podemos deduzir os erros ex e ey existentes por:

ey = Yabs − Ycalc ( 25 )

Utiliza-se a média dos valores obtidos através de vários ensaios, 𝑚𝑋𝑐𝑤/𝑐𝑐𝑤 e

𝑚𝑌𝑐𝑤/𝑐𝑐𝑤, a fim de diminuir a dispersão de desvios provenientes de erros não-sistemáticos.

𝑚𝑋_{𝑐𝑤/𝑐𝑐𝑤} = 1 𝑛 × ∑ 𝑒𝑥 (𝑖) 𝑛 𝑖=1 ( 26 ) 𝑚𝑌𝑐𝑤/𝑐𝑐𝑤 = 1 𝑛 × ∑ 𝑒𝑦(𝑖) 𝑛 𝑖=1 ( 27 )

O resultado é obtido pelo cálculo da distância euclidiana euccw/ccw dos pontos X e Y médios (mXcw/ccw, mYcw/ccw) conforme demonstrado na Figura 30.

𝑒𝑢𝑐_𝑐𝑤 = √(𝑚𝑋_𝑐𝑤)2_{+ (𝑚𝑌}

𝑐𝑤)2 ( 28 )

𝑒𝑢𝑐_𝑐𝑐𝑤 = √(𝑚𝑋_𝑐𝑐𝑤)2_{+ (𝑚𝑌}

𝑐𝑐𝑤)2 ( 29 )

Sendo o maior erro 𝑒_𝑀𝑎𝑥 selecionado para avaliação

𝑒_𝑀𝑎𝑥 = 𝑚𝑎𝑥(𝑒𝑢𝑐_𝑐𝑤, 𝑒𝑢𝑐_𝑐𝑐𝑤) ( 30 )

O erro obtido pode ter origem em dois tipos diferentes que passamos a descrever.

 Erro tipo A

Quando o valor de distância entre rodas é diferente do configurado para os cálculos de odometria, obtemos um erro de tipo A (ver Figura 31 a)). Este é o valor calculado para calcular os movimentos angulares do robô. Caso deste valor estar incorreto temos o robô não realiza a rotação desejada, causando assim um desvio na rotação sobre o seu eixo.

 Erro tipo B

Este tipo de erro é causado por diferenças nos diâmetros das rodas de tração, tal como pode ser observado na Figura 31 b). Este erro provoca um movimento não linear no robô causando um desvio à posição final desejada.

4.2.2. A calibração da odometria

Segundo o procedimento UMBmark, o cálculo de erros tipo A ou tipo B é feita separadamente, não existindo ordem para o cálculo dos mesmos.

 Erro tipo A

Através da relação que a distância entre rodas, d, é inversamente proporcional à quantidade de rotação realizada, apresentada por Borenstein e Feng [30], e sendo α o erro de rotação real da base temos:

𝛼 = (𝑚𝑋𝑐𝑤+ 𝑚𝑋𝑐𝑐𝑤)

−4𝐿 ( 31 )

Sendo 𝐸_𝑏 o valor percentual de erro do valor d que deve ser corrigido para eliminar o erro verificado na Figura 31.

𝐸𝑏 = 90

90 – 𝛼 ( 32 )

 Erro tipo B

Definimos β como ângulo de rotação devido à trajetória não linear (Figura 32). Podemos então calcular o termo corretivo para o erro tipo B como

𝛽 = (𝑚𝑋𝑐𝑤− 𝑚𝑋𝑐𝑐𝑤)

−4𝐿 ( 33 )

O erro de diâmetro entre rodas vai causar transformar uma trajetória supostamente linear numa trajetória curvilínea de raio r

𝑟 = 𝐿/2

𝑠𝑖𝑛( 𝛽/2) ( 34 )

Podemos desta forma calcular também a relação do desvio, Ed, associado ao erro Tipo B 𝐸𝑑 = 𝑟_𝑒 𝑟𝑑 × 𝑟 − d/2 𝑟 + d/2 ( 35 )

4.2.3. Procedimento de calibração conjunta

Existe também o procedimento de calibração conjunta, que, de acordo com o estudo realizado por [31], os erros devem ser analisados conjuntamente, obtendo assim os fatores de correção para os erros sistemáticos.

4.3. Navegação

Para maior versatilidade e possibilitando a navegação em vários tipos de ambiente, foi desenvolvido um sistema de comutação entre dois tipos de navegação da cadeira de rodas elétrica através de um interruptor acessível ao utilizador: “Navegação Livre” e “Navegação Assistida Anti-Colisão”.