7.2 M ´odulo de comunicaci ´on por radio
7.3.1 Funci ´ons propias de Ethernet
Como todas as extensi ´ons de Arduino, esta tam ´en ten a s ´ua propia biblioteca de funci ´ons para manexar as variables necesarias na comunicaci ´on. A continuaci ´on unha breve descrici ´on das utilizadas no presente dese ˜no.
Inclusi ´on da biblioteca de funci ´ons e definici ´on de datos:
]include<Ethernet.h>
byte MAC[ ]={x, x, x, x, x, x}Direcci ´on MAC do m ´odulo
IPAddress IP, GATEWAY,SUBNET: Direcci ´on IP, porta de enlace e subm ´ascara de rede. Inicializaci ´on da conexi ´on:
Ethernet.begin(MAC, IP)
Arranca a conexi ´on da rede co m ´odulo. Os par ´ametros que utiliza son os definidos no router.
Creaci ´on de servidor e cliente.
Na arquitectura da conexi ´on Ethernet aparecen d ´uas figuras: o cliente e o servidor. O primeiro ´e o que realiza as petici ´ons de datos e o servidor o que as procesa e as responde en caso de ser posible.
• EthernetServer<nome do servidor>(porto de conexi ´on)
Deste xeito cr ´ease un servidor que estar ´a escoitando as posibles petici ´ons no porto de conexi ´on. Este acostuma ser por defecto o 80.
• <nome do servidor>.begin():
• EthernetClient<nome do cliente>
Crea o cliente que se conectar ´a a unha IP espec´ıfica e porto. • <nome do cliente>=<nome do servidor>.available()
Conecta o cliente co servidor de xeito que podan comezar a comunicarse. • <nome do cliente>.connected()
Comproba se o cliente est ´a conectado. En caso de que xa estea desconectado e existan petici ´ons sen ler considerarase que o cliente segue conectado.
• <nome do cliente>.available()
Devolve o n ´umero de bytes dispo ˜nibles para a lectura. • <nome do cliente>.read()
Fai a lectura do seguinte byte dispo ˜nible. • <nome do cliente>.print()
Serve para imprimir datos sobre o servidor ao que est ´a conectado en formato ASCII. • <nome do cliente>.println()
Ao igual que o anterior pero facendo que se comece nunha nova li ˜na. Mediante esta sentenza enviarase o c ´odigo HTML para ser visualizado no navegador.
• <nome do cliente>.stop()
Paraliza a conexi ´on entre o cliente e o servidor. Exemplo de c ´odigo
C ´odigo 7.5:Exemplo de ethernet
1 i f ( c l i e n t ) { 2 boolean l i n e a A c t u a l E s t a V a c i a = t r u e ; 3 while ( c l i e n t . connected ( ) ) { 4 i f ( c l i e n t . a v a i l a b l e ( ) > 0 ) { 5 char c = c l i e n t . read ( ) ; 6 i f ( p e t i c i o n . l e n g t h ( ) < 15) { 7 p e t i c i o n . c o n c a t ( c ) ; 8 } 9 i f ( c == '\n ' && l i n e a A c t u a l E s t a V a c i a ) { 10 c l i e n t . p r i n t l n (”HTTP / 1 . 1 200 OK”) ; 11 c l i e n t . p r i n t l n (” Content−Type : t e x t / h t m l ”) ; 12 c l i e n t . p r i n t l n ( ) ; 13 c l i e n t . p r i n t l n (”<!DOCTYPE HTML>”) ; 14 c l i e n t . p r i n t l n (”<html>”) ;
Neste extracto de c ´odigo com ´ezase unha p ´axina HTML. En primeiro lugar compr ´obase se o cliente est ´a conectado. En caso de que o estea e te ˜na datos dispo ˜nibles comeza a lerse a s ´ua petici ´on. Unha petici ´on finaliza co caracter ’\n’ , que ´e un cambio de li ˜na, e unha li ˜na en branco. Cando se detecta esta condici ´on env´ıase a cabeceira HTML.
8
Resultados finais
En xeral o funcionamento ´e o seguinte: dende a p ´axina web m ´andase unha petici ´on de datos, que cruza o router wifi cara a Ethernet Shield. Nela obt ´e ˜nense os datos que se lle proporcionaran ao Arduino MEGA, o cal ser ´a encargado de procesalos e sacalos en forma de radio frecuencia a trav ´es do m ´odulo XBee coordinador. Esta mensaxe env´ıase ao dispositivo final XBee que se precise, o cal devolver ´a a informaci ´on cara o coordinador recorrendo o sentido inverso cara a p ´axina web.
Na configuraci ´on a trav ´es do software X-CTU dos m ´odulos XBee utilizaranse os seguintes par ´ametros: Unidade mestra • MY:1 • CE:1 • AP:2 Unidades escravas • DL:1 • MY:2 a 255 • CE:0 • AP:2
Os m ´odulos XBee estar ´an configurados no modo Sleep n ´umero 4, que consiste en que entrar ´an neste modo de baixo consumo ciclicamente. Os tempos que se definen para esta operaci ´on ter ´an que ser calculados empiricamente dependendo do uso que vaian ter e a velo- cidade de resposta que esperemos dos mesmos. Se deles se espera unha resposta inmediata, o ciclo de descanso ten que ser moi curto. Un valor entre os 500 milisegundos e un segundo ser´ıa m ´ais que suficiente. Deste xeito cada vez que se pase un tempo definido sen ning ´un tipo de interacci ´on entre m ´odulos o XBee entrar ´a no modo de descanso, do cal sair ´a ciclica- mente, segundo outro tempo definido; a comprobar se ten algunha petici ´on en espera, a cal procesar ´a.
Dado que estes m ´odulos soportan un cifrado da informaci ´on aproveitarase esta condici ´on para facer m ´ais segura a comunicaci ´on. A trav ´es da configuraci ´on dos m ´odulos establecerase
un n ´umero que actuar ´a como contrasinal na habilitaci ´on do modo de cifrado. ´E importante que este contrasinal se asocie a todos os elementos da rede implicados na comunicaci ´on.
Un dos requisitos de dese ˜no era que existise a posibilidade de comunicarse cos m ´odulos m ´ais afastados do mestre da rede que son incapaces de comunicarse de xeito directo con el. Para conseguilo intercalaranse cada certo metros (dependendo do modelo escollido) nodos coordinadores. Deste xeito cando o mestre env´ıe un paquete de datos cara un elemento remo- to e non reciba del o acuse de recibo (ACK), enviar ´a unha solicitude aos demais coordinadores da rede para que intenten establecer a comunicaci ´on con el. No caso de que estes coordina- dores intermedios tampouco sexan capaces de comunicarse co m ´odulo remoto xerarase unha alarma para indicar que existe un problema con ese m ´odulo en concreto.
Unha das causas que pode facer que o m ´odulo non responda ´e que se esgote a bater´ıa. Como outro dos requisitos m´ınimos do dese ˜no cont ´emplase o seguimento da fonte de enerx´ıa dos m ´odulos remotos. Esta funcionalidade farase a trav ´es dunha das entradas anal ´oxicas li- bres da plataforma. Dado que se alimentar ´an cunha tensi ´on por riba dos 5 voltios haber ´a que inclu´ır un divisor de tensi ´on cuxa sa´ıda equivalente oscile entre os 0 e os 5 voltios. Por norma xeral a fonte de enerx´ıa elixida para alimentar os m ´odulos ser ´an bater´ıas de 9 voltios, cun di- visor de tensi ´on de 1/2 ser ´a suficiente. A interpretaci ´on desta lectura farase mediante software e amosar ´a un porcentaxe aproximado de carga das bater´ıas e xerar ´a un aviso cando se atope por debaixo dos 7 voltios (78 %).
Os m ´odulos XBee funcionan con unha tensi ´on de 3,3 voltios de alimentaci ´on e te ˜nen uns consumos que poden chegar aos 250 mA. A´ında que as placas de Arduino proporcionan unha sa´ıda estable de 3,3 voltios ´e preferible alimentalos dende unha fonte externa ou dende un regulador sobre a fonte de 5 voltios regulada da placa, xa que a corrente de sa´ıda da fonte de 3,3 voltios pode resultar insuficiente e facer que non cheguen a establecerse as comunica- ci ´ons. Por outro lado debe poder independizarse a conexi ´on dos contactos de comunicaci ´on da plataforma Arduino (RX0 e TX1) das do m ´odulo XBee (DIN e DOUT), xa que cos dous m ´odulos conectados e alimentados non ´e posible a carga dun sketch na memoria da placa de desenrolo, xa que os contactos do porto serie pensados para a conexi ´on USB nese momento est ´an ocupados polo porto serie do m ´odulo de radio, polo tanto ou ben se desconectan ou ben se conectan ´a inversa (RX0 con DIN e TX1 con DOUT).
Existen produtos no mercado para facilitar estas tarefas. O seu nome comercial ´e XBee shield e est ´an dispo ˜nibles en varios fabricantes. Incorporan un regulador de tensi ´on de 3,3 vol- tios que aporta intensidade suficiente para as operaci ´ons do m ´odulo de radio e un conmutador dos terminais de comunicaci ´on para permitir que o porto serie se ocupe polo XBee ou polo USB.
Todo o que involucra ´a plataforma Arduino como ´e a propia placa, as s ´uas extensi ´ons, sensores, actuadores e demais est ´an baseados na filosof´ıa do hardware libre. O que significa que os fabricantes aportan toda a documentaci ´on necesaria (follas de caracter´ısticas, layouts
das placas, modelos de fabricaci ´on) para a creaci ´on duns modelos propios e funcionais deste hardware.
Aproveitando esta condici ´on e coa finalidade de crear m ´odulos completamente indepen- dentes e funcionais, des ´e ˜nase unha placa de circu´ıto impreso que aporte unha soluci ´on ´util para os m ´odulos escravos. Nela incl ´uese un soporte para a placa Arduino NANO, un z ´ocalo para o m ´odulo XBee, o regulador de tensi ´on de 3,3 voltios xunto cos condensadores de filtro, un diodo LED para a visualizaci ´on do estado de asociaci ´on dos m ´odulos de radio, un conmuta- dor entre o modo de programaci ´on USB e a operaci ´on XBee e unha serie de conectores para conectar sensores anal ´oxicos, dixitais e elementos de actuaci ´on. O esquem ´atico desta placa aparece nos planos.
Cabe destacar que os c ´odigos de programaci ´on, tanto para a placa que act ´ua como escrava como a que act ´ua como mestra, unicamente son a orientaci ´on e a base do c ´odigo final. Neles unicamente se contempla a funcionalidade para facer a lectura de unha entrada anal ´oxica e ser visualizada na p ´axina HTML.
A finalidade destes c ´odigos e amosar as funci ´ons b ´asicas de control da rede de xeito que as variaci ´ons que se precisen facer neles tan so consistan en engadir instruci ´ons simples e unicamente referidas a placa Arduino, sen modificar o c ´odigo de XBee e da parte de ethernet. Basicamente as futuras modificaci ´ons consistir ´an en engadir novos c ´odigos de instruci ´on para facer m ´ais dunha lectura e actuar sobre alg ´un elemento externo.
ANEXOS
PETICIONARIO: ESCOLA UNIVERSITARIA POLIT ´ECNICA
AVDA. 19 DE FEBREIRO, S/N
15405 - FERROL
DATA: FEBREIRO DE 2016
AUTOR: O ALUMNO
´Indice do documento ANEXOS
9 Documentaci ´on de partida 77
9.1 Asignaci ´on do TFG . . . 77