Universidade de Aveiro Departamento de Engenharia Mecânica 2013

José Luís de Jesus Bettencourt Viana E-Stop e consola de controlo e monitorização do AtlasCar José Luís de Jesus Bettencourt Viana E-Stop e consola de controlo e monitorização do AtlasCar

Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestrado em Engenharia Mecânica, realizada sob orientação científica de Vítor Manuel Ferreira dos Santos, Professor Associado do Departamento de Engenharia Mecânica da Universidade de Aveiro.

O júri / The jury

Presidente / President Prof. Doutor Jorge Augusto Fernandes Ferreira

Professor Auxiliar da Universidade de Aveiro

Vogais / Committee Prof. Doutor António Manuel Ferreira Mendes Lopes

Professor Auxiliar da Faculdade de Engenharia da Universidade do Porto

Prof. Doutor Vítor Manuel Ferreira dos Santos

Professor Associado da Universidade de Aveiro (orientador)

Palavras-chave  Segurança, Arduíno, Xbee, CRC16, E-stop, monitorization, ROS, SQL, PHP.

Resumo O veículo AtlasCar é um robô desenvolvido no Laboratório de Automação e Robótica do Departamento de Engenharia Mecânica da Universidade de Aveiro, para o estudo de sistemas de segurança ativos e passivos para auxilio à condução e soluções de condução autónoma.

Este trabalho tem como objetivo a criação de um sistema de emergência remota E-Stop, e uma consola de controlo e a criação de um sistema de monitorização para o veículo, complementando-se mutuamente com dois temas em torno da segurança.

O E-Stop e a consola de controlo consiste na criação de um sistema de atuação remota capaz de gerir 3 sistemas diferentes de atuação por ordem do utilizador: RUN, PAUSE e DISABLE, sendo um elemento necessário à participação no concurso internacional ELROB. Para isso algum hardware e software foram desenvolvidos para o cumprimento de todas as diretivas impostas pelo mesmo.

O Sistema de monitorização funciona sobre uma base de dados SQL, de onde são extraídos os dados para introdução numa página web. A atualização da base de dados é efetuada através do sistema ROS implementado no AtlasCar, tendo este de ter uma ligação à Internet, podendo ser através de rede wifi como por 3G.

Todo o sistema foi testado e validado em operação real.

Keywords  Security, Arduíno, Xbee, CRC16, E-stop, monitorization, ROS, SQL, PHP.

Abstract The AtlasCar vehicle is a robot developed at the Automation and Robotics laboratoru in Department of Mechanical Engeneering at the University of Aveiro. The main objective of this project is to develop both active and passive advanced security systems, for implementation in driver assistance system and autonomous vehicles.

The main goal of this work is the development of a remote emergency E-stop, with a control console, also the criation of a vehicle monitoring system. These two complient each other in the security.

The E-Stop and the control console are part of a remote atuation system that manages three diferent states of atuation by user order: The three states are RUN, PAUSE and DISABLE. This system is mandatory to be eligle to participate in the international ELROB competion. Both software and hardware were developed with this goal in mind, acording to the competition directives.

The monitoring system consists in a SQL database whose fields are published in a webpage. The refresh of the database is in charge of a ROS software module running on the atlascar using either a wifi or a 3g internet connection.

Both systems were tested and validated in real operation.

Conteúdo

Conteúdo  i
Lista de Tabelas  iii
Lista de Figuras  v
1 E-Stop e consola de controlo  1
1.1 Estudo do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Soluções encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Escolha de um módulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Sistema a implementar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Funcionamento do E-Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Configuração do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Rotinas de segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Estrutura das mensagens . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.3 Configuração dos Módulos Xbee . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Implementação do E-Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Comando do E-Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2 E-Stop no Atlascar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Bibliografia  11

ii

Lista de Tabelas

1.1 Comparação dos vários sistemas encontrados para implementação do E-Stop … 2
1.2 Tabela dos campos usados para configuração dos Xbee’s . . . . . . . . . . . . . . 6

iv

Lista de Figuras

1.1 Imagens do Sistema a ser implementado no comando E-Stop. . . . . . . . . . . . 3
1.2 Imagens do Sistema a ser implementado no AtlasCar para o E-Stop. . . . . . . . 3
1.3 Esquema de funcionamento do E-Stop . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Comando usado no controlo remoto do Atlascar . . . . . . . . . . . . . . . . . . . 7
1.5 Comando Xbox com o chatpad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Protótipo inicial do comando E-Stop para integração no AtlasCar . . . . . . . . . 7
1.7 Primeiro teste para organização dos elementos . . . . . . . . . . . . . . . . . . . . 7
1.8 Comando remoto final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.9 Esquema eléctrico do comando remoto . . . . . . . . . . . . . . . . . . . . . . . . 8
1.10 Comando E-Stop implementado no AtlasCar com o cabo de alimentação . . . . . 8
1.11 Imagens de diferentes prespetivas do comando remoto . . . . . . . . . . . . . . . 8
1.12 Esquema elétrico do sistema de atuação . . . . . . . . . . . . . . . . . . . . . . . 10
1.13 Placa de implementação do sistema de atuação . . . . . . . . . . . . . . . . . . . 10
1.14 Shield do sistema E-Stop instalado no carro . . . . . . . . . . . . . . . . . . . . . 10

vi

Capítulo 1

E-Stop e consola de controlo

Neste capitulo será apresentada a metodologia para criação e implementação do sistema E-STOP no veículo Atlascar.

1.1 Estudo do problema

Uma das imposições do ELROB é a existência, nos veículos participantes, de um sistema de atuação remota que possibilite a imobilização dos mesmos, se durante uma demonstração algo de errado aconteça, para evitar danos tanto nos veículos como nos espetadores. Assim a existência de um comando para atuação remota dos modos do E-Stop seja obrigatório. Os modos de operação do sistema e as ações a tomar quando cada modo está ativo são imposições por parte da organização do evento. O sistema é constituído pelos seguintes modos:[Schneider, 2006]

• RUN

• PAUSE

• DISABLE

O modo RUN, é o modo normal de operação do sistema, ou seja, o modo de normal funcionamento do carro. O modo PAUSE, quando ativo tem de ser capaz de imobilizar totalmente o veiculo, mas o veiculo pode voltar novamente ao modo autónomo remotamente, ou seja, a comutação para o modo de RUN, tem de ser possível remotamente. O modo DISABLE, sendo ativado o carro tem de ser imobilizado e a fonte de propulsão tem de ser desligada. Este modo não pode ser revertido remotamente, para o veiculo poder voltar ao modo automático o carro tem de ter intervenção humana. É um modo de emergência e a sua ativação deve ser o ultimo recurso.

1.1.1 Soluções encontradas

Depois de alguma pesquisa, foram encontradas duas soluções, que se adaptavam ao sistema a implementar. Uma delas um sistema de comando e servo recetor de modelismo, pois modelos mais recentes incluem telemetria, a outra solução passaria pela implementação de toda a rede sem fios, sobre Arduinos com módulos de Xbee.[Arduino][Digi]

O sistema de radio modelismo com telemetria, é extremamente fiável e com alcance aceitável para o problema proposto. A telemetria seria para controlo de algumas variáveis de sistema do carro, pois o utilizador, estando o comando na mão e afastado um pouco do veículo continuaria a ter acesso a alguma informação relevante do mesmo. Mas sendo um sistema muito fiável, também é muito fechado, ou seja, tem protocolos de comunicação com os elementos e codificação de mensagens, logo a sua aplicação e adaptação para o problema proposto não seria trivial e de difícil expansão futura. Em relação ao sistema sobre micro-controladores(μC) com módulos Xbee para comunicação sem fios, existe a vantagem de ser totalmente configurável e de comunicação bidirecional, o que permite a monitorização do sistema; na tabela 1.1 estão representados os sistemas tidos em conta para implementação do E-Stop.

Modo de Comunicação  Rx/Tx  Imagens  Alcance

Modulo de Rádio Modelismo Sistema de comunicação totalmente fechado Desconhecimento dos modos de comunicação entre o emissor e os sensores

500m (em campo aberto)

XBee-PRO® S2B Totalmente configurável. Comunicação digital

90m (Indoor) 1500m (em campo aberto)

XBee-PRO® 868 Totalmente configurável. Comunicação digital.

550m (Indoor) 40km (em campo aberto c/ dipole antena)

Tabela 1.1: Comparação dos vários sistemas encontrados para implementação do E-Stop

1.1.2 Escolha de um módulo

Depois de uma análise cuidada da tabela 1.1, e tendo em linha de conta a aplicação, a escolha recai sobre os módulos Xbee Pro S2B. São módulos de fácil futura expansão e em comparação com o Xbee Pro 868 a diferença mais significativa, além do preço, é o alcance, que para o problema em questão não é muito significativo, e o sistema escolhido tem alcance suficiente para a aplicação.

1.2 Sistema a implementar

Com a escolha efetuada no anteriormente, apenas ficou definido o modo de transmissão de dados sem fios; a organização de mensagem, envio e processamento fica a cargo de μC. Selecionando para o efeito sistemas de μC Arduino, usando para o comando remoto um Arduino FIO e para unidade do veículo um Arduino Mega.

(a) Arduino Fio  (b) Xbee Pro S2B

Figura 1.1: Imagens do Sistema a ser implementado no comando E-Stop.

O sistema a implementar na unidade do veículo baseia-se no do comando remoto, apenas substituindo as placas de μC; esta escolha deve-se ao poder computacional do μC do comando remoto não ser suficiente para processamento das mensagens enviadas, mas esse tema será mais aprofundado adiante.

(a) Arduino Mega  (b) Xbee Pro S2B rpsma

Figura 1.2: Imagens do Sistema a ser implementado no AtlasCar para o E-Stop.

1.2.1 Funcionamento do E-Stop

O funcionamento do sistema a implementar com os componentes escolhidos anteriormente, é o seguinte:

• O comando com três modos de atuação RUN, PAUSE e DISABLE, cuja ativação tem de ser traduzida de alguma forma para o comando remoto, ou seja, através de botões que estão ligados a entradas digitais μC.

• Depois de interpretada a entrada digital que se encontra ativa, é construída uma mensagem, para ser enviada para a unidade do veículo.

• A mensagem chega à unidade e aí é interpretada, ativando ou desativando as saídas correspondentes ao comando que é recebido.

• Em seguida a unidade do carro faz uma verificação das portas que se encontram ativas, e constrói uma mensagem para ser devolvida ao comando remoto.

• A mensagem que chega ao comando remoto é interpretada e é ativado um led correspondente ao estado E-Stop, isto para ser possível informar o utilizador do estado do E-Stop.

Sendo a figura 1.3, o esquema do funcionamento do E-Stop

Figura 1.3: Esquema de funcionamento do E-Stop

1.3 Configuração do sistema

Nesta seção serão explicados todos os procedimentos e rotinas implementadas para a configuração do sistema.

1.3.1 Rotinas de segurança

Um sistema de segurança tem de ser fiável, não podendo falhar ou dar instruções erradas, para isso não acontecer neste caso em concreto foram introduzidas no sistema algumas rotinas de segurança, procurando dar ronutex ao sistema de E-Stop.

E-Stop independente de software Uma das medidas tidas em linha de conta para implementação deste sistema, foi de alguma forma conseguir que este fosse o mais independente possível do controlo já existente no AtlasCar, tentando que não dependesse, ao máximo, de rotinas de processamento internas do veículo. A única rotina que se depende para a ativação do E-Stop é a de emergência do PLC,[Rocha, 2011], que quando ativada imobiliza o veículo.

Envio de CRC cyclic redundancy check Cada mensagem enviada tem um código de verificação para garantir que esta chega ao destino sem erros de informação, e que todos os bits são enviados.

Falha na comunicação Em caso de perda de comunicação o modo de PAUSE é ativado na unidade do veículo, enquanto no comado remoto todos os leds são acesos, alertando o utilizador para o problema. Entende-se como perda de comunicação entre módulos, a não confirmação de um CRC durante dois segundos de atividade (sendo este tempo configurável).

Taxa de transmissão de mensagens As mensagens são trocadas entre os elementos do sistema a uma taxa de 5 Hz, foi escolhido este valor pois é o ponto de equilibrio para o tempo de atuação no carro, que se quer o mais rápido possível, e o tempo de interpretação de mensagens por parte dos μC.

Mensagens Dinâmicas As mensagens enviadas do comando para o carro e vice-versa são cadeias de carateres, que contêm a informação necessária para serem tomadas ações. Mesmo que a informação a ser transmitida entre dispositivos seja repetida, a string enviada nunca é igual; tornando o CRC diferente em cada mensagem evitando falhas, a descrição das mensagens trocadas pode ser consultada 1.3.2

Ações a tomar As ações a tomar por parte do elemento recetor de uma mensagem, só são efetuadas depois da verificação CRC.

1.3.2 Estrutura das mensagens

Para ser trocada entre sistemas a informação tem de ser organizada de forma a poder ser transmitida numa string, para quando interpretada uma mensagem a ação certa seja tomada. Assim a mensagem enviada do comando para o carro é uma string com o seguinte formato

0x02 STR1 COUNT STR1 ESTOP-STAT STR3 BAT-VAL CRC16 0x03

0x02

Caratere com o qual se dá início à string para se poder marcar o início de uma string e o fim.

STR1

String: "Hello "Elemento presente para separação da mensagem a enviar.

COUNT

Esta é uma variável muito importante na string a construir; trata-se de um contador que a cada ciclo de código no comando remoto é incrementado. Implementando assim um sistema de segurança, pois o string a enviar é alterada a cada ciclo.

STR2

String: "e-stop " presente para separação da mensagem a enviar.

ESTOP-STAT

Variável em que é inserido o estado do E-stop para ser transmitido para o carro

– 15 - corresponde ao estado RUN do E-stop

– 25 - corresponde ao estado PAUSE do E-stop

– 35 - corresponde ao estado DISABLE do E-stop Assim quando a mensagem é tratada a ação é tomada consoante o estado que é enviado para o carro.

STR3

String: "bat " presente para separação da mensagem a enviar.

BAT

Variável com o valor medido na entrada analógica referente ao divisor resistivo colocado no μC do comando remoto para saber o estado da bateria1.4.1.

CRC16

Onde se encontra o Cyclic redundancy check(verificação cíclica redundante), que é um código de deteção de erros nas mensagens, é calculado com base nos carateres da string gerando uma string em HEX que quando a mensagem é recebida, é calculado novamente para verificar se algum caratere da mensagem foi perdido durante a transmissão da mesma. 0x03

Caratere com o qual se termina a string a enviar.

À semelhança do das mensagens trocadas entre o comando remoto e unidade do veiculo, também a unidade do veículo envia mensagens de estado para o comando remoto tendo a mensagem trocada a seguinte forma:

0x02 COUNT E-STOP VAR1 VAR2 VAR3 CRC16 0x03

0x02

Caratere com o qual se dá início à string para se poder marcar o início de uma string.

COUNT

Esta é uma variável muito importante na string a construir; trata-se de um contador que a cada ciclo de código no comando remoto é incrementado. Implementando assim um sistema de segurança, pois o string a enviar é alterada a cada ciclo.

E-STOP

String com o estado do e-stop, para ser enviado para o comando

– resume - corresponde ao estado RUN do E-stop

– pause - corresponde ao estado PAUSE do E-stop

– stop - corresponde ao estado DISABLE do E-stop

VAR1 VAR2 VAR3

Espaço disponibilizado para futura monitorização de variáveis do Atlascar, não estando neste momento implementadas. Sendo uma das ideias iniciais a introdução de um lcd para monitorização do estado da maquina.

CRC16

Onde se encontra o Cyclic redundancy check(verificação cíclica redundante), que é um código de deteção de erros nas mensagens, é calculado com base nos carateres da string gerando uma string em HEX que quando a mensagem é recebida, é calculado novamente para verificar se algum caráter da mensagem foi perdido durante a transmissão da mesma.

0x03

Caráter com o qual se termina a string a enviar.

1.3.3 Configuração dos Módulos Xbee

Os módulos Xbee são dispositivos de comunicação sem fios com diversas possibilidades de configuração. Neste projeto os dois módulos foram configurados para comunicarem entre si, evitando assim tentativas de conexão a outros elementos o que poderia originar interferências. Foram configurados usando o software X-CTU, disponibilizado pela DIGI [Digi], o qual permite configurar todos os campos necessários para a comunicação entre os módulos. Todos os passos de configuração podem ser reproduzidos recorrendo ao tutorial que se encontra em anexo ??. As configurações possíveis de implementar com estes sistemas são inúmeras, e esse também foi um dos fatores que originou a escolha. As configurações usadas estão descritas na tabela 1.2.

Campo Comando Remoto Unidade do Atlascar
Modo  Coordinator AT  End Device AT
ID  1234  1234
SC  FFFF  FFFF
SD  3  3
ZS  0  0
NI  COMANDO  ATLASCAR
DH  13A200  13A200
DL  408CBFFB  40918B44
BD  4(19200 bit/s)  4(19200 bit/s)
NB  0(sem paridade)  0(sem paridade)

Tabela 1.2: Tabela dos campos usados para configuração dos Xbee’s

1.4 Implementação do E-Stop

Nesta seção apresenta-se todo o trabalho desenvolvido para a implementação dos sistemas e procedimentos descritos nas seções anteriores. tanto na instalação do sistema no comando do E-Stop bem como no módulo instalado no AtlasCar.

1.4.1 Comando do E-Stop

O AtlasCar pode ser controlado à distância por um comando da Xbox fig:1.4. Assim depois

Figura 1.4: Comando usado no controlo remoto do Atlascar

de alguma pesquisa encontrou-se uma possível solução para o problema: o comando da Xbox tem um Chatpad fig:1.5, que pode ser adaptado para o sistema em causa.

Figura 1.5: Comando Xbox com o chatpad

Assim pensou-se numa possível integração de todos os componentes usando o ChatPad Xbox 360, e foi elaborado uma maqueta onde se integram todos os comandos e led’s. A solução inicial previa a inclusão de um LCD no comando para disponibilizar algumas variáveis ao utilizador.

Figura 1.6: Protótipo inicial do comando E-Stop para integração no AtlasCar

Como o Chatpad é um elemento com espaço reduzido para albergar os componentes necessários para implementação do E-Stop, então o espaço teve de ser aumentado, recorrendo-se para isso a uma peça feita à medida, encontrando-se o seu desenho técnico em anexo??.

A organização dos elementos que compõem o comando E-Stop foi inicialmente pensada da seguinte forma 1.7.

Figura 1.7: Primeiro teste para organização dos elementos

Tendo em conta que o sistema a desenvolver seria para utilização humana, além dos aspetos funcionais, teve-se em linha de conta a ergonomia do sistema, porque sendo um sistema de emergência os comandos teriam de ser posicionados num local de fácil acesso. Assim depois de criação do prototipo do comando, no laboratório foi dado o sistema a alguns colegas para testarem a disposição dos botões e dos leds. Sendo que depois de debatermos os pontos de vista de cada um e qual a melhor disposição dos controlos, sendo unanime que seria mais facil a monutação entre o modo de PAUSE e RESUME deveria ser com um movimento vertical. Chegando-se assim ao resultado final1.8.

Figura 1.8: Comando remoto final

Esquemas elétricos

O sistema implementado no comando é composto pelos seguintes elementos

• Botão de emergência - quando pressionado ativa o modo DISABLE

• Botão de 2 posições - para alternar entre o modo de RUN e PAUSE • LED’s; verde (RUN ); amarelo (PAUSE); vermelho (DISABLE)

• 3 Resistências de 120 Ohm - para polarizar os LED’s

• 2 Resistências de 430 Ohm - para fazer um divisor resistivo

A implementação de um divisor resistivo no comando remoto, prende-se com o fato da alimentação ser efetuada através de uma bateria, sendo necessária a monitorização do valor da tensão da bateria. Assim a única forma de o fazer é recorrendo a um divisor resistivo que se encontra conetado a uma entrada analógica do μC. Para o valor das resistencias foram tidos vários fatores em consideração o mais importante o consumo energético que isso implicaria para o sistema, mas também era necessário passar corrente suficiente para poder ser feita a leitura na porta analógica do μC.

O esquema elétrico dos elementos que constituem o comando do E-Stop podem ser consultados na figura seguinte 1.9.

Figura 1.9: Esquema eléctrico do comando remoto

Depois da verificação do esquema elétrico e teste em bancada do sistema, passou-se para a fase de execução do projeto final, com o elemento de ampliação do Chatpad, modelado e maquinado com os furos corretos para introdução dos elementos do comando

Figura 1.10: Comando E-Stop implementado no AtlasCar com o cabo de alimentação

Figura 1.11: Imagens de diferentes prespetivas do comando remoto

1.4.2 E-Stop no Atlascar

Para o módulo instalado no AtlasCar e como descrito na secção 1.2, usou-se um Arduino Mega com o módulo Xbee. O sistema no carro terá interromper algumas linhas já existentes no carro, descritas na secção ??, como a linha responsável pela ativação da emergência no PLC e a linha de corte de energia ao motor. A escolha destas duas linhas prende-se com o fato de serem a que melhor se adaptam às funcionalidades do E-Stop, pois como explicado na seção 1.1, o modo PAUSE terá apenas de imobilizar o veículo enquanto o STOP terá além de imobilizar desligar a fonte de propulsão do veículo. A linha de emergência será cortada quando o modo de PAUSE for ativado, fazendo com que o carro seja imobilizado e podendo novamente voltar à ação quando esta deixar de estar interrompida. Enquanto o modo STOP além de interromper a linha de emergência do modo PAUSE, também interrompe a linha de alimentação do motor do veículo.

Circitos de atuação

Para o corte das linhas usou-se relés, outras alternativas foram pensadas, mas a que melhor se adequava ao problema em causa eram relés. Para a criação do sistema de atuação com relés foi necessário o seguinte material:

• acoplador ótico

• Relés NO(normaly open);

• Resistências

• Díodos de recirculação

Em seguida será feita uma descrição de todos os componentes, bem como o que motivou a sua escolha.

Opto acoplador Este componente eletrónico foi usado como interruptor. Sendo ativado pelo circuito digital de baixa tensão, 5V(Arduino Mega), e atuando sobre a linha de tensão mais elevada 12V(linhas de emergência do carro). Este componente é um isolador elétrico pois o acoplamento do circuito é efetuado por via ótica, existindo um led(emissor) do lado da linha de baixa tensão e um fototransistor que comuta o circuito de alta tensão. Para o dimensionamento do circuito onde este componente se encontra, foram tidos em conta vários fatores, sempre orientados pelo datasheet que se encontra em anexo. Para ser usado como interruptor o transístor deve transitar somente entre o regime de saturação e o de corte. Para isso teve de ser efetuado um cálculo para verificação do regime de atuação do transístor e da potencia dissipada no opto-acoplador. Assumindo que se deseja uma tensão de V_{CE(sat)} = 0.4V então a corrente de coletor, usando a resistência do relé que se encontra no datasheet de 1.2kΩ

V = R.I ⇒ I_{C} = \frac{12−0.4}{1.2} ⇒ I_{C} = 9.67mA

Com este valor de corrente no coletor do transístor e o V_{CE(sat)} desejado, recorre-se à figura 12 do datasheet, que se encontra em anexo anereferenciar anexo. Verificando que a corrente do diodo I_{F} deve ser superior a 12 mA.

R ≤ \frac{5−1.2}{12} ⇒ R ≤ 310Ω

Escolheu-se para isso uma resistência de 250 Ohm (R1 e R2)1.12, que garante o funcionamento do sistema para toda a gama de temperaturas desejadas e tendo em conta a tolerância dos componentes. Com este valores calculador anteriormente garante-se também que o valor da potencia dissipada é inferior ao limite presente na figura 6 do datasheet. Os diodos de re-circulação(D1 e D2 1.12) são usados para impedir que quando a bobine é comutada, evitar a sobre tensão de interrupção de circuito danifique o transístor.

Figura 1.12: Esquema elétrico do sistema de atuação

Figura 1.13: Placa de implementação do sistema de atuação

Shield para o Xbee

Por motivos alheios ao decorrer normal desta dissertação, não foi possível em tempo útil integrar um Shield para o Arduino Mega onde seria integrado o Xbee S2B, assim teve-se de desenvolver uma placa onde a comunicação do Arduino com o Xbee e vice-versa fosse possível. Assim depois de perceber quais os pinos necessários para a comunicação criou-se um em placa furada1.14.

Figura 1.14: Shield do sistema E-Stop instalado no carro

Sistema manual em caso de falha do E-Stop

Como as linhas em que o E-Stop vai atuar foram interrompidas e os relés de atuação são do tipo NO(Normaly Open normalmente aberto), ou seja se não forem alimentados os relés interrompem o circuito, fazendo com que tanto a linha de emergência como a linha de alimentação do motor fiquem interrompidas e consequentemente o carro pode não funcionar corretamente. Para evitar que em caso de falha do sistema E-Stop o carro não funcione foram colocados 2 interruptores, que em caso de falha do E-Stop podem ser comutados fechando as linhas que estavam interrompidas pelos relés. por aqui alguma fotos da caixa do carro com os botões

Bibliografia

Arduino. Arduino web page. http://http://www.arduino.cc/. [Online; Acedido a 18 de fevereiro de 2013].

Digi. Xbee RF Modules. http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/zigbee-mesh-module/.

[Online; Acedido a 18 de fevereiro de 2013].

Tiago Rocha. Piloto Automático para Controlo e Manobras de Navegação do AtlasCar. Tese de mestrado, Universidade de Aveiro, 2011.

Frank E. Schneider. The European robot trial. http://http://www.elrob.org/, 2006. [Online; Acedido a 24 de março de 2013].