CWS obtained information from health professionals

Como indicado anteriormente um dos objectivos deste projecto ´e portar um dos com- ponentes do middleware para um hardware diferente. Neste caso ´e o wormhole que ´e portado para outro hardware (Atom pro 28). Este porte permite uma melhoria significa- tiva nos tempos de resposta, pois o wormhole passa para o mesmo hardware que a camada de sensores. Com esta alterac¸˜ao ´e poss´ıvel garantir que uma resposta ´e dada dentro de um valor de tempo, o que antes n˜ao era poss´ıvel devido ao facto de o processo wormhole po- der ser interrompido assincronamente por outros processos que trabalham paralelamente e competem pelo tempo do CPU.

O desenho inicial do wormhole continha v´arias componentes que funcionavam para- lelamente para completar os objectivos. Visto a facilidade de execuc¸˜ao paralela n˜ao estar presente no microcontrolador, foi necess´ario serializar os componentes tendo sido remo- vido todo o c´odigo relativo ´a execuc¸˜ao em paralelo.

Com a transic¸˜ao do wormhole para o microcontrolador o valor dispon´ıvel no temporiza- dor tornou-se insuficiente porque este componente tem a necessidade de controlar tempos de outro componente, o payload, que lhe ir´a enviar seguramente intervalos de tempo superiores ao valor indicado anteriormente (131,072 milissegundos). Para resolver esta situac¸˜ao o valor do contador ´e somado a cada iterac¸˜ao a um contador com maior capaci- dade. Assim ´e poss´ıvel ao wormhole, controlar intervalos at´e 25,452 dias.

O microcontrolador Atom pro 28 como indicado anteriormente cont´em apenas 2048 bytes de mem´oria para vari´aveis, o que apenas permite carregar um mapa relativamente pequeno. Sabendo que as vari´aveis da camada de sensores e do wormhole sem contar com o mapa ocupam 386 bytes, o mapa apenas pode ter um tamanho de 40 por 40 c´elulas ou 1600 c´elulas totais, visto que uma c´elula ocupa 1 byte de mem´oria. Isto n˜ao ´e efi- ciente visto que no mapa estamos apenas a apresentar 3 estados na pior das hip´oteses. Por isso foi criado um mapa de bits em vez de um mapa de bytes em que cada c´elula ocupa apenas 1 bit. Isto permite apresentar dois estados (obst´aculo est´atico, caminho li- vre) sendo necess´ario um outro mapa para apresentar mais um estado (c´elula explorada). Mesmo com a existˆencia de dois mapas o consumo de mem´oria ´e 75% menor. Com este melhoramento ´e poss´ıvel carregar mapas de 80 por 80 c´elulas ou 6400 c´elulas. Com este melhoramento o tamanho do mapa continua a ser relativamente pequeno para permi- tir o detalhe de um grande edif´ıcio. Uma poss´ıvel soluc¸˜ao ´e permitir carregar um mapa mais pequeno mas detalhado da zona onde o robˆo est´a de forma a permitir uma melhor navegac¸˜ao. Esta aproximac¸˜ao traz depois outros problemas, como o problema de navegar num mapa global utilizando um mapa local e o problema de transferˆencia do mapa local para o microcontrolador sem atrasar o processo de controlo. Para este melhoramento ser poss´ıvel foi necess´ario alterar a forma como o wormhole bridge envia o mapa. Agora ´e necess´ario que o wormhole bridge passe o mapa para bits antes de o enviar. Para o enviar, cada byte do mapa original ´e convertido para 0s e 1s sendo 0 caminho livre e 1 obst´aculo. O segundo mapa ´e gerado pelo wormhole com base no primeiro.

Para portar o wormhole para o microcontrolador foi necess´ario juntar o c´odigo da ca- mada de sensores ao do wormhole. Com isso um novo ciclo de controlo foi criado que pode ser observado na figura 5.3 apresentada anteriormente.

Na placa H4090 foi criado um componente novo, o wormhole bridge. Este componente foi criado para permitir o controlo sobre o payload que continua instalado nesta placa pelo wormhole. Esse controlo traduz-se na possibilidade de terminar e voltar a iniciar o

payloadcaso o mesmo n˜ao cumpra v´arias promessas ou fique muito tempo sem respon-

der. Adicionalmente o c´odigo da interface com o wormhole teve que ser reescrita para permitir a passagem das novas mensagens. Este componente tem o objectivo secund´ario de ser transparente para o payload, ou seja, o payload continua a pensar que est´a a comu- nicar directamente com o wormhole.

A execuc¸˜ao do wormhole ´e iniciada recebendo um ficheiro de configurac¸˜ao que contˆem v´arios dados necess´ario como tamanho do mapa e c´elulas, o mapa, o interface s´erie que vai utilizar, a posic¸˜ao e orientac¸˜ao inicial a ser comunicada ao microcontrolador. O wormhole comec¸a por enviar estes dados para o microcontrolador, iniciando posteriormente o pay-

load. Depois de receber a mensagem o robˆo fica num estado pr´e-activo o qual passa para activo assim que o payload enviar a primeira promessa. No estado pr´e activo o robˆo ape- nas fica `a espera de mensagens via porta s´erie visto ainda n˜ao ter qualquer informac¸˜ao de onde se deve dirigir.

Para garantir que as func¸˜oes bloqueantes tivessem um tempo de resposta limitado, foi necess´ario criar um timeout para cada tipo de interacc¸˜ao. Para a primeira interacc¸˜ao por s´erie que faz activar o robˆo ´e necess´ario algum tempo pois existe a transferˆencia de muita informac¸˜ao entre a placa H6042 e o microcontrolador por isso o timeout definido para essa func¸˜ao ´e de 1 segundo. Para as restantes interacc¸˜oes por s´erie ´e utilizado um timeout de 20 milissegundos. Para interacc¸˜oes com os sensores de distˆancia o limite ´e 30 milissegundos, pois esse ´e o tempo m´aximo que o sensor pode demorar a responder. Para as restantes interacc¸˜oes n˜ao ´e necess´ario limite pois as mesmas s˜ao apenas de envio de informac¸˜oes e o tempo demorado ´e conhecido.