III. APPROCHES SOCIALES ET APPROCHES BIOLOGIQUES DES RELATIONS ENTRE HUMAINS ET ANIMAUX
2. Les limites du paradigme dualiste et sa remise en cause
Nome do caso de uso: • Detectar Intruso. Actores:
• Camada de Sensores. Condic¸˜ao para iniciac¸˜ao:
• Execuc¸˜ao peri´odica. Pr´e-condic¸˜oes:
• A camada de sensores est´a num estado operacional e o robˆo recebeu informac¸˜ao num dos sensores dispon´ıveis que se encontra um objecto nas imediac¸˜oes do robˆo. P´os-condic¸˜oes:
• O payload obt´em informac¸˜ao dos obst´aculos nas imediac¸˜oes do robˆo. Caso esperado:
1. O componente camada de sensores obt´em o valor de distˆancia do sensor.
2. O componente camada de sensores calcula a posic¸˜ao no mapa do objecto atrav´es da posic¸˜ao actual do robˆo e orientac¸˜ao.
3. O componente camada de sensores aguarda o valor da posic¸˜ao do obst´aculo no mapa e aguarda que o componente wormhole solicite este valor.
4. O componente wormhole efectua o pedido para obter os obst´aculos entretanto de- tectados.
6. O componente wormhole encaminha a informac¸˜ao dos obst´aculos directamente para o payload.
7. O payload recebe a informac¸˜ao dos obst´aculos e processa-a. 8. O caso de uso termina.
4.4
Metodologia de desenvolvimento
A metodologia utilizada para o desenvolvimento deste projecto foi o modelo incremental. Este m´etodo permite o desenvolvimento do projecto em fases em que cada fase ´e testada antes de passar para a pr´oxima. A cada iterac¸˜ao ´e adicionada novas funcionalidades con- firme a indicac¸˜ao do cliente e corrigidos erros encontrados nas fases anteriores. Neste caso o cliente ´e o orientador e este define a progress˜ao do projecto. Este projecto foi com- posto por trˆes fases em que a primeira foi uma fase de estudo e preparac¸˜ao do projecto e cada uma das fases seguintes foi constru´ıda sobre a anterior. Conforme o projecto vai avanc¸ando novo objectivos secund´arios tornam-se evidentes e este modelo tem flexibili- dade suficiente para permitir alcanc¸´a-los.
Na imagem 4.2 podemos observar os v´arios processos que s˜ao necess´arios para este modelo. O processo “requisitos” ´e um processo em que o planeamento ´e feito. Nesta fase os requisitos do projecto s˜ao levantados. O processo “desenho” ´e o processo onde a arquitectura do sistema vai ser definida e todos os artefactos em relac¸˜ao ao projecto s˜ao criados. O processo “implementac¸˜ao” ´e o processo onde a escrita de c´odigo ´e feita. O processo “verificac¸˜ao” ´e o processo onde a depurac¸˜ao do c´odigo ´e feita, assim como correcc¸˜ao de erros e testes. O processo ”manutenc¸˜ao”´e um processo em que ser recebe o feedback do cliente efectua-se pequenas correcc¸˜oes se necess´ario.
Como podemos verificar os processos podem ser repetidos at´e obter a soluc¸˜ao preten- dida.
Na primeira iterac¸˜ao deste projecto os objectivos eram passar o middleware para o hard-
waredispon´ıvel, efectuando as melhorias necess´arias e implementar uma interface entre
o middleware existente e os sensores f´ısicos no robˆo. Para que isso fosse poss´ıvel ´e ne- cess´ario encontrar os requisitos para essa implementac¸˜ao. Um dos requisitos ´e que o
hardwaredispon´ıvel tem que ser analisado para verificar como o mesmo funciona e pon-
derar o mapeamento deste novo componente no hardware. Ap´os este passo foi necess´ario desenhar m´odulos que permitissem a comunicac¸˜ao entre o middleware e sensores e defi- nir as mensagens que os mesmos necessitam para comunicar. Apenas depois de definir m´odulos e mensagens necess´arias ´e que foi poss´ıvel implementar os m´odulos. Quando a implementac¸˜ao estiver conclu´ıda ´e necess´ario testar os m´odulos de forma a encontrar
erros. No processo de avaliac¸˜ao ´e avaliado se os objectivos s˜ao cumpridos. Com esta iterac¸˜ao foi criada o componente camada de sensores (Sensor Layer) e as respectivas interfaces necess´arias para que o middleware pudesse comunicar com este novo compo- nente.
Na segunda iterac¸˜ao o objectivo era portar um dos componentes do middleware para um hardware separado. Para que isso fosse poss´ıvel um levantamento da mem´oria e espac¸o utilizado pelo c´odigo era necess´ario. Ap´os este passo foi necess´ario analisar os m´odulos a serem portados de forma a verificar alterac¸˜oes necess´arias para que os mesmos pudessem funcionar correctamente no novo hardware, inclu´ıdo alterac¸˜oes as mensagens trocadas pelos m´odulos. Na implementac¸˜ao foi portado todo o c´odigo do componente para o novo hardware. Ap´os esta fase ´e necess´ario testar os m´odulos de forma a verifi- car se o funcionamento do middleware n˜ao tinha sido comprometido com esta alterac¸˜ao. Nesta iterac¸˜ao avaliamos o comportamento da soluc¸˜ao fase a soluc¸˜ao criada na primeira iterac¸˜ao. Com esta iterac¸˜ao foi portado o componente wormhole para o hardware Atom pro 28 e criado um novo componente de ligac¸˜ao wormhole bridge que permite a trans- parˆencia na comunicac¸˜ao entre os componente wormhole e payload em hardwares dife- rentes.
Na terceira iterac¸˜ao o objectivo era portar um dos m´odulos do wormhole para um
hardwareseparado. Para que isso fosse poss´ıvel um levantamento da mem´oria e espac¸o
utilizado pelo c´odigo era necess´ario. Ap´os este passo foi necess´ario analisar o m´odulo a ser portado e as alterac¸˜oes necess´arias nos m´odulos dependentes deste. Adicionalmente as mensagens passadas entre os m´odulos foram revistas. A implementac¸˜ao foi efectuada no hardware como planeado. Na fase de testes foi testada a precis˜ao do temporizador, assim como erros no c´odigo. Na fase de avaliac¸˜ao foi verificado o tempo que o wormhole demora a iterar. Com esta iterac¸˜ao foi portado o m´odulo TTFD Task do wormhole para o
hardwareFPGA Spartan dispon´ıvel e foram criadas novas mensagens para possibilitar a
Arquitectura do Sistema
A figura 5.1 apresenta a arquitectura final do sistema. Este sistema ´e composto pelo
middlewareadaptado para um robˆo m´ovel f´ısico.
Como ´e poss´ıvel observar, o middleware est´a dividido em trˆes componentes principais: o payload, o wormhole bridge e o wormhole. Estes trˆes componentes est˜ao mapeados em
hardwaresdiferentes: o ARMv6 e o Atom pro 28. Adicionalmente existe um m´odulo que
se destaca, TTFD task, que est´a instalado numa FPGA Spartan 3E.
Esta figura tamb´em apresenta os tipos de interface utilizados entre os v´arios compo- nentes e m´odulos. Como ´e poss´ıvel verificar, o payload e o wormhole bridge comunicam entre si atrav´es de interface socket, enquanto o wormhole bridge e wormhole comuni- cam atrav´es de interface s´erie. O m´odulo TTFD Task comunica com o wormhole bridge atrav´es de mem´oria partilhada e com o wormhole atrav´es de pinos (ligac¸˜ao directa).
Os componentes e respectivos m´odulos criados ou alterados no contexto do projecto s˜ao apresentados nas pr´oximas secc¸˜oes.
5.1
Payload
O payload tem como objectivo principal o controlo do robˆo e pode comunicar com outros robˆos de forma a obter informac¸˜ao sobre a posic¸˜ao e poss´ıveis intrusos.
Este componente ´e executado pelo wormhole bridge e recebe o mapa da localizac¸˜ao e respectivos parˆametros, os enderec¸os de todos os outros robˆos m´oveis. Os parˆametros do mapa s˜ao tamanho das c´elulas e tamanho do mapa. Assim que o payload inicia comec¸a a tentar controlar o robˆo.
O hardware em que este componente est´a instalado, Armv6, ´e o hardware existente mais poderoso ao dispor deste projecto, logo o componente que requer mais poder de
processamento e mem´oria deve ser alocado a este hardware. Para utilizar este hardware foi necess´ario instalar um sistema operativo. O sistema operativo permite a facilidade de execuc¸˜ao paralela o que permite a execuc¸˜ao de v´arias aplicac¸˜oes em simultˆaneo embora devido a esse facto qualquer processo, incluindo o componente payload, pode ser inter- rompido assincronamente n˜ao sendo poss´ıvel dar garantias temporais fidedignas.
Este componente n˜ao ser´a melhorado neste projecto visto os algoritmos do qual ´e composto desempenharem as respectivas func¸˜oes a um n´ıvel satisfat´orio.
Na pr´oxima subsecc¸˜ao s˜ao apresentadas as mensagens que este componente gera e que s˜ao utilizadas no contexto deste projecto.
5.1.1
Mensagens
Este componente ´e respons´avel pelo envio de mensagens do tipo “promessa”. Esta men- sagem, como indicado anteriormente, ´e utilizada para comunicar ao wormhole a nova velocidade, orientac¸˜ao e destino do robˆo. Adicionalmente a mensagem cont´em um prazo para entrega da pr´oxima mensagem do tipo “promessa”. Esse prazo ´e gerado pelo pay-
loade deve ter em considerac¸˜ao o tempo que o mesmo demora a gerar uma resposta.
Este componente pode a qualquer altura tentar controlar o robˆo enviando uma men- sagem do tipo promessa para o wormhole. Regularmente este componente recebe do wormhole, mensagens que indicam qual a posic¸˜ao, orientac¸˜ao e velocidade actual do robˆo. Atrav´es destes dados o payload constr´oi a pr´oxima mensagem do tipo promessa.
5.2
Wormhole Bridge
O wormhole bridge tem como objectivo principal encaminhar mensagens que vˆem de
hardwares diferentes e permitir que o wormhole continue a controlar o payload apesar
que estar num hardware diferente. O controlo do payload por parte do wormhole resume- se `a aplicac¸˜ao de penalidades quando o payload n˜ao cumpre a promessa, o que inclui o reiniciar do componente payload. Essa func¸˜ao deixa de ser poss´ıvel directamente com a alterac¸˜ao do hardware pelo wormhole, logo o componente wormhole bridge passa a rei- niciar o payload quando o wormhole pedir (via mensagem).
Este componente foi criado aquando o porte do wormhole para um hardware dife- rente do componente payload de forma a permitir que os dois componentes continuassem a comunicar e que as func¸˜oes do componente wormhole n˜ao fossem comprometidas pela
Figura 5.2: Arquitectura do componente wormhole bridge.
alterac¸˜ao de hardware. Todas as mensagens enviadas pelo wormhole s˜ao recebidas pelo
wormhole bridgeque as encaminha para o payload e todas as mensagens enviadas pelo
payloads˜ao recebidas pelo wormhole bridge e encaminhadas para o wormhole.
O wormhole bridge ´e o primeiro componente do sistema a ser executado recebendo o mapa da localizac¸˜ao e respectivos parˆametros, os enderec¸os de todos os outros robˆos m´oveis. Ap´os estar iniciado, este componente inicia o wormhole, enviando uma c´opia do mapa e dos seus parˆametros (tamanho, tamanho das c´elulas), a posic¸˜ao e orientac¸˜ao inicial. Depois de iniciar o wormhole este componente inicia o payload enviando uma c´opia do mapa e dos seus parˆametros. No fim dos dois componentes (wormhole e pay- load) estarem iniciados, o wormhole fica `a espera de mensagens.
O wormhole bridge foi instalado no hardware “H6042” de forma a permitir a continuac¸˜ao do controlo do componente payload pelo componente wormhole e permitir que a transic¸˜ao de mensagens entre as diferentes interfaces seja transparente tanto para o wormhole como para o payload.
Nas pr´oximas subsecc¸˜oes s˜ao apresentados os m´odulos que comp˜oem este compo- nente e as mensagens trocadas pelo mesmo.
5.2.1
M´odulos
A figura 5.2 apresenta a arquitectura do componente wormhole bridge. Como ´e poss´ıvel observar, os m´odulos que integram este componente s˜ao:
envia-las para o wormhole e tem a responsabilidade de reiniciar o componente pay-
loadquando o mesmo ´e pedido pelo wormhole;
• Wormhole Listener, que tem como objectivo receber as mensagens do wormhole e envia-las para o payload e encaminhar o prazo da promessa para o m´odulo TTFD Task.
O m´odulo payload listener ´e um m´odulo existente que apenas recebe a mensagem do tipo promessa. Este m´odulo sofreu pequenas alterac¸˜oes para permitir o encaminhamento de mensagens, vindas de interface socket, para interface s´erie e para permitir comunicac¸˜ao com o m´odulo TTFD task no hardware H6042.
O m´odulo wormhole listener ´e um m´odulo criado que encaminha todas as mensagens enviadas pelo wormhole.
5.2.2
Mensagens
Este m´odulo utiliza as todas mensagens apresentadas no payload e wormhole com adic¸˜ao de uma outra que ´e utilizada para comunicar com o m´odulo TTFD task o novo prazo na promessa enviada pelo payload.
5.3
Wormhole
O wormhole tem como objectivo principal o controlo do cumprimento de promessas por parte do payload e pode controlar o robˆo quando necess´ario. Adicionalmente o wormhole gere a posic¸˜ao do robˆo e detecta intrusos utilizando sensores locais (sensores de distˆancia, aceler´ometro e girosc´opio).
Devido ao componente inicialmente ser constru´ıdo em linguagem C, o mesmo foi inicialmente instalado no hardware H6042. Devido ao requisito que indicava a necessi- dade dos componentes principais, wormhole e payload, terem que passar para hardwares diferentes, o wormhole passou para o hardware ”Atom pro 28”. Com este porte foi ne- cess´ario criar o componente wormhole bridge para existir continuac¸˜ao de comunicac¸˜ao entre as duas componentes, wormhole e payload, apesar de estarem em hardwares dife- rentes.
O wormhole ´e executado pelo wormhole bridge recebendo o mapa e respectivos parˆametros (tamanho do mapa e das c´elulas que o comp˜oem), a posic¸˜ao e orientac¸˜ao inicial. Ap´os iniciar, este componente aguarda por uma mensagem do tipo promessa para dar in´ıcio ao
Figura 5.3: Ciclo de controlo do componente wormhole.
ciclo de controlo que permitir´a o controlo do tempo do componente payload, gest˜ao de posic¸˜ao e detecc¸˜ao de intrusos utilizando sensores locais.
Nas pr´oximas subsecc¸˜oes s˜ao apresentados componentes, m´odulos e mensagens que foram criadas no porte deste componente para o novo hardware.
5.3.1
M´odulos
Ap´os a migrac¸˜ao do wormhole para o microcontrolador, um novo ciclo de controlo foi criado. A imagem 5.3 apresenta o ciclo de controlo final criado ap´os a junc¸˜ao do compo- nente wormhole com a camada de sensores.
Como ´e poss´ıvel observar, o ciclo de controlo ´e constitu´ıdo por v´arios m´odulos, cada um com uma func¸˜ao necess´aria para o robˆo. Os m´odulos s˜ao os seguintes:
• m´odulo sensor calibration, que ´e apenas executado quando o sistema ´e iniciado e depois de executado o ciclo de controlo comec¸a;
• m´odulo payload listener, que recebe as mensagens do payload e processa-as se necess´ario. O m´odulo position updater actualiza a posic¸˜ao, velocidade e orientac¸˜ao actual utilizando os sensores locais.
• m´odulo obstacle updater, que verifica se existe algum obst´aculo nas proximidades do robˆo e se existir reporta esse facto ao payload.
• m´odulo TTFD task listener, recebe mensagens do m´odulo TTFD task de forma a verificar se o payload est´a a cumprir as promessas.
• m´odulo status sender, envia o estado do robˆo para o payload. Esse estado ´e com- posto por posic¸˜ao, velocidade e orientac¸˜ao.
• m´odulo safety task controla o robˆo caso o payload n˜ao cumpra com a promessa. • m´odulos velocity observer e orientation observer monitorizam a velocidade e orientac¸˜ao
para verificar se o robˆo est´a a deslocar-se `a velocidade correcta e se a orientac¸˜ao ´e a correcta. Estes m´odulos efectuam tamb´em pequenos ajustes para garantir que o robˆo esta a movimentar-se correctamente.
Como o wormhole passou para o microcontrolador, ele perdeu a capacidade de reini- ciar o componente payload que ficou num hardware diferente. Para ser poss´ıvel manter esta funcionalidade foi necess´ario criar um novo componente no mesmo hardware em que est´a o componente payload. Esse novo componente, wormhole bridge, tem como objectivo permitir ao componente wormhole o rein´ıcio do componente payload e tratar de todo o trabalho de adaptac¸˜ao das mensagens de um hardware para outro.
Adicionalmente para ser poss´ıvel passar o m´odulo TTFD task para a FPGA, algumas alterac¸˜oes tiveram que ser feitas ao wormhole. O wormhole deixou de ter o componente de controlo de tempo da TTFD task e passa a ter apenas a aplicac¸˜ao de penalidades ao payload por incumprimento de prazos. O m´odulo TTFD task na FPGA deve ser capaz de indicar ao wormhole quem tem, num determinado momento, controlo sobre o robˆo.
Safety Task
Anteriormente foi identificado que seriam necess´arios melhoramentos para aumentar a eficiˆencia do robˆo no ambiente f´ısico. O algoritmo a ser melhorado ´e o algoritmo do m´odulo safety task, que ´e um m´odulo do componente wormhole.
O m´odulo safety task ´e respons´avel pelo controlo do robˆo quando o payload demora demasiado tempo a cumprir a promessa. Este m´odulo tem que ser simples, r´apido e de- termin´ıstico por causa dos requisitos temporais do wormhole. Esses requisitos temporais determinam que o wormhole deve ter um tempo m´aximo conhecido de iterac¸˜ao para que seja poss´ıvel garantir que dentro desse valor de tempo, o wormhole garantir´a o controlo do robˆo. O m´odulo safety task requer um mapa de forma a aplicar o algoritmo de procura de caminho. O mapa utilizado ´e um array bidimensional composto por c´elulas. Cada c´elula pode representar uma parede ou um poss´ıvel caminho. A implementac¸˜ao original definia que o robˆo se deslocaria na direcc¸˜ao que permitisse ficar mais perto do destino. Com esta definic¸˜ao ´e poss´ıvel resolver mapas simples mas mapas mais complexos que cont´em caminhos sem sa´ıda podem fazer com que o robˆo n˜ao consiga chegar ao destino. Para melhorar este algoritmo tivemos que adicionar mem´oria do caminho utilizado pelo robˆo para que em caso de encontrar um beco sem sa´ıda o robˆo possa retroceder pelo caminho que utilizou e escolher outro. Para isso foi necess´ario criar um novo tipo de c´elula, que ´e
Figura 5.4: Fluxograma do processo de decis˜ao do novo passo do m´odulo “safety task”.
a c´elula explorada, para evitar que o robˆo visite as c´elulas que j´a explorou.
A figura 5.4 apresenta o processo de procura de caminhos ap´os a introduc¸˜ao da mem´oria dos caminhos utilizados.
Este fluxograma apresenta os passos efectuados pelo algoritmo quando ´e necess´ario calcular um novo passo. Um passo ´e uma localizac¸˜ao interm´edia no mapa que leva o robˆo para mais perto do destino. O algoritmo comec¸a por localizar o robˆo no mapa, calculando a posic¸˜ao no mapa atrav´es da posic¸˜ao no mundo e das dimens˜oes da c´elula. Ap´os obter a localizac¸˜ao no mapa, essa posic¸˜ao ´e marcada como explorada. A partir deste ´ultimo passo ´e poss´ıvel comec¸ar `a procura da melhor direcc¸˜ao para continuar. A melhor direcc¸˜ao
´e calculada simulando o movimento de uma unidade no mapa para cada uma das posic¸˜oes principais (cima, esquerda, direita, baixo) e verificando qual destes movimentos ´e o que leva o robˆo mais perto do destino. Adicionalmente ´e preciso que a posic¸˜ao testada n˜ao tenha sido explorada. Caso n˜ao seja encontrada a melhor direcc¸˜ao, o robˆo chegou a um beco sem sa´ıda. Caso seja encontrada a melhor direcc¸˜ao ´e calculada a distˆancia at´e ao destino e se o robˆo estiver perto do mesmo, o robˆo p´ara. Caso o robˆo n˜ao esteja perto do destino, as novas ordem s˜ao enviadas para os motores.
TTFD Task
O m´odulo TTFD task tem como principal func¸˜ao o controlo do cumprimento dos prazos por parte do payload. Se o payload continuadamente cumprir os prazos, o mesmo po- der´a efectuar o controlo do robˆo mas se n˜ao for esse o caso o robˆo passa a ser controlado pelo wormhole enquanto o payload n˜ao conseguir cumprir promessas podendo ocorrer situac¸˜oes em que o wormhole reinicie o componente wormhole por um n´umero de falhas elevadas ou por n˜ao comunicar durante um espac¸o predefinido de tempo.
Este m´odulo faz parte do wormhole e est´a instalado na FPGA. O hardware ”FPGA Spartan 3e”foi escolhido para suportar este m´odulo devido ao facto de o mesmo ser dedi- cado, ou seja, apenas executa a configurac¸˜ao criada e n˜ao tem outras aplicac¸˜oes/servic¸os a serem executados concorrentemente. Adicionalmente este hardware tem um poder de processamento superior e permite uma unidade de tempo menos significante do que a per- mitida pelo Atom pro 28.
5.3.2
Mensagens
Para que o componente wormhole possa comunicar com os v´arios componentes e m´odulos dispon´ıveis, s˜ao necess´arias mensagens para envio de valores que o wormhole gera ou adquire e para recepc¸˜ao de valores necess´arios para o funcionamento do wormhole. O
wormhole´e capaz de funcionar correctamente sem o payload mas apenas garante servic¸os
b´asicos de navegac¸˜ao sendo necess´ario receber informac¸˜oes do payload para que ter um navegac¸˜ao eficiente.
A lista seguinte apresenta todas as mensagens necess´arias ao sistema:
• Uma mensagem enviada pelo payload para o wormhole com destino, velocidade, orientac¸˜ao e prazo para pr´oxima entrega (tipo promessa);
• Uma mensagem enviada pelo wormhole para o payload com localizac¸˜ao de um obst´aculo (tipo obst´aculo);
Figura 5.5: Cen´ario t´ıpico de comunicac¸˜ao aquando o envio da mensagem do tipo pro- messa pelo componente payload.