<Status > <Home> <Fim da Página>

 

< 20.02.2002>           

Início da concepção.

Reuni tudo que eu já tinha e escolhi o que seria interessante usar em Um Pippo:

  1. Uma estação de desenvolvimento BasicX-01 (Netmedia) com microcontrolador AT90S8515 (Atmel).

  2. Um módulo RamSandwich de expansão de memória (128KB) para o BasicX-01 (Netmedia).

  3. Um display LCD 4X20 plugavel no módulo RamSandwich (Netmedia).

  4. Um controlador para 8 servos R/C (Netmedia).

  5. Três servos Futaba S3003.

  6. Um sensor IR Ranger GP2D02 (Sharp).

  7. Um sensor piroelétrico 442-3 (Eltec).

  8. Um sensor Sonar Ranging 6500 (Polaroid).

  9. Um sensor de campo magnético digital 1490 (Dinsmore).

  10. Uma base motorizada Max 99 (Zagros).

A idéia é usar este material já existente e eventualmente acrescentar novos itens ou eliminar algum, em função das necessidades conseqüentes ao Nível de Competência do Robô (NCR) e da Arquitetura escolhida para Um Pippo.

<21.02.2002>

    A.  Início dos testes.

Teste dos equipamentos já existentes, começando com a montagem do ambiente de teste do BasicX-01. Em termos de hardware o ambiente se resume à estação de desenvolvimento BasicX-01 e suas conexões  à paralela e à serial do meu PC (Pentium III 1Ghz 256MB rodando Windows XP), um protoboard, uma bateria selada de 12VDC 7.2Ah e uma fonte regulada de 5VDC 1A de alta eficiência (LM2675-5.0). Para o software (sistema operacional, compilador e editor) entrei no site do BasicX e baixei a última versão do software BasicX. A instalação e os testes padrão do software foram simples e funcionaram bem.

    B.  Testes para multi-tasking.

Testes para comprovar a capacidade de multi-tasking do BasicX-01 e o número de tasks possíveis em função da RAM interna disponível (cada task exige uma pilha em RAM).

<04.03.2002>

    A.  Início dos estudos para estabelecimento do NCR0.

NCR0 será o conjunto de comportamentos básicos de Um Pippo.

    B.  Resultado dos testes de multi-tasking.

Os testes tiveram resultados altamente positivos quanto à funcionalidade e timing, porém verificamos que é inviável termos mais que 3 a 4 tasks em função da capacidade interna  da RAM que restringe a quantidade de pilhas necessárias. Isto nos leva a termos que utilizar o módulo RamSandwich que nos permite expandir a memória com 64KB de RAM + 64KB de XRAM. Esta expansão tem um preço alto em termos de pinos de I/O disponíveis. Originalmente o BasicX-01 tem 32 pinos de I/O, mas com o uso do RamSandwich esse número cai para 6. Isto inviabiliza a interligação dos sensores que serão necessários.

    C.  Avaliação das alternativas.

Em função do problema exposto em B, teremos que avaliar alternativas que basicamente são:

  1. Trocar o microcontrolador.

  2. Usar vários microcontroladores em paralelo.

  3. Usar o BasicX-01 em conjunto com co-processadores.

<19.04.2002>

    A.  Arquitetura de hardware.

Escolhemos a alternativa 2 (vários microcontroladores BasicX-01 rodando em paralelo e interligados via uma rede RS485. Com isso preservamos o microcontrolador já existente (queremos manter a linha Atmel) e o ambiente de desenvolvimento em BasicX ( subset do Visual Basic Microsoft). A troca de microcontrolador (alternativa 1) faria com que perdêssemos esse ambiente de desenvolvimento, passando para Assembler ou na melhor das hipóteses para C. A alternativa 3 pouco ganho nos traria, já que os próprios co-processadores consomem pinos de I/O.

    B.  Controle de movimento.

A movimentação de Um Pippo se fará através de um sistema de direção diferencial onde as duas rodas tratoras são movidas por motores DC através de geradores PWM de potência (LMD18200T). O controle é feito através de sinais obtidos pelos encoders incrementais (H5S-250-I) e realimentados para os integrados de controle do movimento (LM629N-6).

    C.  Próximo passo.

Vamos montar e programar a função de movimentação, constando de 1 BasicX-01, 2 LM629N-6, 2 LMD18200T, 2 H5S-250-I e a base Max 99. Isto vai demorar algum tempo, em função da complexidade do LM629 e do tempo de entrega dos componentes. Enquanto isso estarei atualizando as páginas de arquitetura, mecânica, cinemática, eletrônica, sensores e software.

<20.06.2002>

    A.  Último período.

Entre a compra (Digikey, US Digital) e o recebimento dos componentes passou aproximadamente um mês, que aproveitei para estudar o LM629N-6 através de documentação baixada do site da National. Quando da chegada dos componentes, todas as rotinas para uso do processador de movimento estavam prontas e com a sintaxe verificada. Este último mês foi utilizado para:

  1. Montagem física dos encoders incrementais na base motorizada.

  2. Montagem em protoboard do BasicX-01, LM629N-6, LMD18200T, clock e outros componentes necessários.

  3. Teste e depuração do conjunto de rotinas básicas para o movimento.

  4. Ajuste e sintonia do filtro integral diferencial (PID) para controle do laço de realimentação dos motores.

Vamos falar um pouco sobre cada um desses itens, especialmente sobre as dificuldades que encontrei pelo caminho:

  1. Neste item a dificuldade foi montar os encoders no espaço restrito entre as duas caixas de redução. Fizemos uma extensão posterior do eixo das rodas nas caixas de redução que foi interligado ao eixo dos encoders via uma junção flexível de silicone.

  2. Neste item não houve maiores dificuldades. Tomamos o cuidado de trabalhar sempre sobre manta anti-eletrostática, com pulseira e aterramento.

  3. Este item foi muito trabalhoso por ser o LM629 um componente extremamente complexo e com algumas sutilezas não bem explicadas no manual. Algumas coisas tiveram que ser testadas muitas vezes.

  4. Esta é a parte mais crítica de todo o processo. Sem o ajuste e sintonia adequado do PID, todo o trabalho anterior se perde pois a resposta física aos comandos é mascarada por atenuações ou oscilações exageradas. O manual não é muito claro sobre como determinar corretamente o valor das constantes do PID. Tivemos então que desenvolver uma série de experimentos até adquirir um conhecimento prático da influência de cada parâmetro do filtro sobre o desempenho do sistema. Com isso conseguimos chegar a uma resposta crítica de atenuação, adequada ao nosso conjunto motor-redutor. Esta sintonia é específica para cada caso, não se aplicando a outros conjuntos motor-redutor. Por outro lado, é impossível simplesmente ignorá-la pois não sendo feita ou sendo malfeita, ela falseia completamente os resultados.

    B.  Próximo passo.

Desenvolvimento, depuração e teste das rotinas para execução da movimentação final de Um Pippo. A movimentação de Um Pippo será a composta através de três primitivas:

  1. Movimento retilíneo.

  2. Giro sobre o eixo vertical central.

  3. Estado de parada.

Através dessas primitivas, Um Pippo poderá atingir e manter-se em qualquer ponto de uma superfície plana. O movimento em curva genérica, do qual o giro sobre o eixo vertical central é um caso particular (em que o raio da circunferência de giro é zero) será deixado para um próximo NCR.

<01.07.2002>

    A.  Rotinas para execução da movimentação final.

As rotinas (20) foram desenvolvidas, testadas e depuradas. Com isso estamos com o NCR0 de Um Pippo pronto e funcionando.

    B.  Estabelecimento do NCR1.

Neste ponto, decidimos dotar Um Pippo de uma camada também ligada a movimento e orientação, mas agora considerando o campo magnético terrestre. Nesta mesma camada, também será implementado um sensor de reconhecimento de voz com a finalidade de passar comandos via voz a Um Pippo. Serão desenvolvidas as rotinas de software necessárias aos novos comandos. Os comandos de voz nos ajudarão já nos testes autônomos de Um Pippo.

<15.10.2002>

Após três meses em que aconteceram muitos imprevistos de ordem pessoal, retomei o desenvolvimento de Um Pippo, agora já com o Voice Extreme Toolkit mas ainda sem o Vector 2X Compass Module. Nos testes o Voice demonstrou ser uma ferramenta extremamente poderosa e de uso bastante simples. Desenvolvi os comandos de voz, as rotinas de interfaceamento do voice com o BasicX-01 e a interface física entre os dois.

<02.12.2002>

O desenvolvimento de  Um Pippo está em compasso de espera em função da demora da chegada do Vector 2X e especialmente do integrado MAX3377E que decidi utilizar para o interfaceamento físico entre o Voice Extreme e o BasicX-01. Trata-se de um Translator da Maxim com quatro canais bidirecionais, necessário à compatibilização dos níveis elétricos do Voice Extreme (3V) e do BasicX-01 (5V).

<15.12.2002>

Com a chegada do MAX3377E e do Vector 2X, poderei dar continuidade aos testes de interfaceamento BasicX-01, Voice Extreme e Vector 2X. Ainda tenho que resolver um problema que é a utilização do MAX3377E em proto-board para testes. Isto porque o MAX3377E tem um encapsulamento TSSOP 14. Para resolver este problema, utilizarei um adaptador AK14D-TSOP da Accutek para DIP 14.

<08.01.2003>

Enquanto espero o adaptador AK14D-TSOP, resolvi adiantar a parte de interconexão dos BX-01 via rede RS485 e ao mesmo tempo iniciar o desenvolvimento do coordenador de subsumption.

<13.01.2003>

Vou iniciar a consolidação da parte de movimentação básica numa placa que incluirá o BX-01 de controle, os LM629 e os LMD18200. Futuramente esta placa estará disponível como um kit (hardware e software) para movimentação genérica de motores DC. Estarei também projetando os novos passos para o NCR. O esquema estará mostrando as variações no processo de integração das diversas partes de Um Pippo.

<22.01.2003>

Finalmente chegou o adaptador AK14D-TSOP, com isso poderei testar a interligação do Voice Extreme com o BX-01. Enquanto não chegava o adaptador, testei essa interligação via RS232 e tudo funcionou perfeitamente mas tive que usar um MAX233 para transformar o RS232 nível TTL invertido do BX-01 (0V / +5V) em RS232 verdadeiro (especificação EIA/TIA-232E).

Estudando a interligação via SPI do BX-01 que controla os LM629 com o BX-01 (N=1, G=1), acabei descobrindo que o sistema operacional do BX-01 não permite definir um BX-01 como escravo (apesar de o hardware do microcontrolador permitir). Em função dessa limitação, vou tentar utilizar o barramento SPI do AT90S8515 diretamente através dos seus registradores internos.

<24.01.2003>

Não será possível interfacear os dois BX-01 via SPI mesmo através dos registradores, isso porque o BX-01 já é master SPI para utilizar a EEPROM. Com o Vector 2X não há problemas porque, neste caso, o Vector 2X atua como escravo. Como o BX-01 tem duas seriais (Com1 e Com2), sendo que uma (Com1) é utilizada na rede RS485, faremos a interface com o Voice Extreme via pinos e utilizaremos a outra serial (Com2) para interfacear o módulo de movimento. Com isso, o módulo de movimento (futuro kit) ganha uma interface mais universal, podendo ser utilizado também via PC.

<26.01.2003>

Em função da problemática acima, será desenvolvida uma interface entre o Voice Extreme e o BX01 (N=1, G=1) constando de um Translator (MAX3377E) e um Shift-and-Store Bus Register (CD4094B). Com isso, utilizaremos três pinos no Voice Extreme (P0.2, P0.3, P0.4) para transferir serialmente um byte de código do comando de voz detectado. No BX-01 usaremos a porta A para interligar com a saída paralela do Shift-and-Store Bus Register e o pino de interrupção externa para interligar diretamente com o pino P0.7 do Voice Extreme através do qual ele fará a sinalização de existência de comando de voz.

<27.01.2003>

Para usar o translator em proto-board, soldei o MAX3377E no adaptador AK14D-TSOP usando uma técnica simples para solda SMD. Estou mencionando este assunto, porque, para muitos, executar uma solda SMD é ainda uma espécie de tabu. Na realidade, com alguns cuidados, é até bastante simples.

<06.03.2003> ! ! !

Após um mês problemático em que praticamente tive que parar o desenvolvimento, reiniciei durante o carnaval  a programação e os testes da interface entre o Voice Extreme e o BX01 (N=1, G=1) e consegui sucesso ! Esses pontos de exclamação são devidos à dificuldade inerente a essa interface, tanto em hardware quanto em software. Para ter uma idéia, aqui estão os programas de teste da interface. Do lado do BX01 a programação é em Basic e do lado do Voice extreme a programação é em C.

O próximo passo será interligar o Vector 2X ao BX01(N=1,G=1).

<10.03.2003>

Fiz os testes para interligação do Vector 2X ao BX01 de duas formas (o Vector 2X se comunica via uma interface SPI padrão Motorola). Primeiramente tentei utilizar o barramento SPI do BX01 via comandos SPI específicos do BasicX. Nesse caso os pinos SDO e SCLK do Vector 2X são interligados respectivamente aos pinos MISO e SCK do BX01. Nessa interligação, o BX01 funciona como "master" e o Vector 2X como "slave". Infelizmente, depois de muitas tentativas, cheguei à conclusão que o "timing" interno da implementação SPI no BX01 não se coaduna às necessidades de tempos do SPI do Vector 2X. Em seguida, para comprovar essa hipótese, programei uma interface SPI para o BX01 totalmente em software via pinos genéricos do BX01, utilizando o "timing" especificado no manual do Vector 2X. Com isso obtive sucesso !

O próximo passo será fazer a integração funcional de todos os blocos interligados ao BX01 (N=1, G=1), ainda sem a rede RS485.

<30.03.2003>

Usando o EAGLE 4.09r2, desenvolvi os esquemas para as placas de movimento, Hbridge e BX01 (N=1, G=1) com Vector 2X e interface para Voice Extreme.

<10.05.2003>

Ao fazer a integração funcional dos vários blocos no BX01 (N=1, G=1), tive um problema com o LMD18200T da roda direita, o que atrapalhou bastante pois foi muito demorado achar onde estava o problema. O teste final dessa integração vai depender da chegada do novo LMD18200T (aproximadamente 15 dias). Enquanto isso, vou iniciar os testes para interligação dos BX01 em rede (RS485) através do uso dos comandos do BX01: OpenNetwork, GetNetwork, GetNetworkP, PutNetwork, PutNetworkP, PutNetworkPacket, PutNetworkQueue.

<11.05.2003>

Para fazer o teste da rede, utilizarei dois BX01 interligados como no esquema. Como tenho uma única estação de desenvolvimento BX01, primeiro vou programar a EEPROM do BX01-2 de modo a que ele teste continuamente um byte da sua RAM e conforme essa posição contenha 1 ou 0, ele acenda ou apague o Led1 conectado ao pino 16. Esse BX01, sua EEPROM e o chip de rede serão então montados em proto-board  e interligados com o BX01-1 montado na estação de desenvolvimento. O BX01-1 será programado de modo a aguardar um interrupt externo (pino 13) e quando este ocorrer, mudar o valor do byte de RAM do BX01-2 de 0 para 1 ou vice-versa. O efeito final deverá ser que a cada pressionada do pulsante S1 no BX01-1, o Led1 no BX01-2 deverá mudar de estado (aceso ou apagado).

<13.05.2003>

O teste da rede funcionou perfeitamente. O BX01-2 foi programado em multitasking, com uma task  para fazer piscar o Led2 e a outra para verificar a posição de memória RAM e acionar o Led1 em correspondência. Os programas dos testes estão aqui.

<16.05.2003>

Iniciei os testes com o sensor ultra-sônico de distância SRF08.  Este sensor se comunica com o BX01 através de um barramento I2C. O barramento I2C permite a interligação de vários sensores através de endereços próprios aos sensores. Em Um Pippo usaremos quatro sensores. Como o BX01 não tem barramento I2C nativo, desenvolvi rotinas de software para implementar interligações I2C master-slave. Para isso, me baseei nas rotinas escritas por Gerald Coe (Devantech Ltd) para o BX24 e nas de Peter H. Anderson para o BX01. Nos próximos dias estarei testando essa configuração.

<18.05.2003>

Os testes tiveram sucesso somente após uma boa estudada nas especificações do I2C (vide documento da Philips). O barramento I2C é muito interessante pois permite, no caso do SRF08 , interligar até 16 unidades, usando os mesmos pinos do BX01. O SRF08 responde ao endereço &H00 (General Broadcasting) o que nos permite acionar todos eles ao mesmo tempo. Porém, no caso da leitura das distâncias medidas, cada unidade tem que ser processada separadamente.

<31.05.2003>

Neste último período executei os testes do detector(IR) GP2D02 da Sharp e desenvolvi rotinas para o seu uso. O GP2D02 é um sensor interessante, mas com algumas características que tornam trabalhosa a sua calibração, calibração esta individual e absolutamente necessária para que ele trabalhe corretamente. Ele é utilizado através de dois pinos, um de clock e um de dados. No primeiro clock, ele inicia a medida, que após 70 ms está completa. Em seguida, o clock é acionado 8 vezes e em cada vez um bit (do Msb para o Lsb) é colocado no pino de dados. O sensor manda um byte (0 - 255) cujo valor corresponde à distância detectada até um objeto. O problema é que o valor que ele envia tem uma relação inversa com a distância real e pior, a leitura varia não linearmente em função da distância. Está armado o caos !!!. Para resolver estes problemas, primeiro desenvolvi as rotinas para acionar e ler o GP2D02, imprimindo o valor do byte lido continuamente em intervalos de 1 segundo. Isto feito, posicionado o sensor no início de uma régua e utilizando um anteparo móvel, fui fazendo leituras do byte enviado pelo sensor a cada posição do anteparo sobre a régua calibrada. Com isso obtive um conjunto de pares (Cm, byte lido) e pude observar que apesar das especificações do GP2D02 darem como intervalo utilizável de 10 a 80 Cm, na prática, para o caso específico do meu sensor, o intervalo utilizável se restringe a 8 a 28 Cm. Restava agora achar uma função que para uma determinada leitura (que agora, em função das medidas executadas não era mais de 0 - 255 e sim de 86 - 210) desse como resultado a distância ao objeto em centímetros. Para isso fiz uma série de regressões polinomiais sobre os pares obtidos, de modo a escolher aquela que em termos práticos melhor ajustasse os pontos levantados. O melhor ajuste foi obtido com um polinômio do nono grau, mas, comparando as diferenças resultantes dos vários polinômios ajustados e, em função de aspectos práticos e de timing da função programada, escolhi a solução obtida pela regressão polinomial de terceiro grau, que finalmente foi a programada na função.

Em seguida aos testes acima, programei uma série de rotinas para o controle de motores de passo unipolares usando uma interface UCN5804B. O motor de passo será utilizado para controle da varredura do sensor piroelétrico 442-3 (Eltec). Neste ínterim, chegou o LMD18200T substituto. Em função disso, o próximo passo será retomar os testes finais da integração funcional dos vários blocos no BX01 (N=1, G=1) (vide acima).

<15.06.2003>

Decidi disponibilizar de forma gratuita a biblioteca de rotinas para o controle de movimento. Peço aos interessados em utilizá-la que me dêem retorno sobre seu uso (sucessos ou fracassos) e que, em eventuais aplicações, citem a fonte.

<11.07.2003>

Existirá um link de RF (433MHz) entre Um Pippo e o meu PC. Inicialmente este link será unidirecional, do PC para Um Pippo. Futuramente esse link será alterado de forma a que Um Pippo possa enviar dados sobre os seus sensores e o ambiente em que ele estiver. No PC haverá um programa em VB6 para se comunicar com  Um Pippo via o nó (N=0, G=0). Este programa utilizará rotinas utilitárias e uma DLL para permitir o acesso direto aos pinos da porta paralela, através dos quais serão enviados comandos e informações a Um Pippo. À porta paralela estará conectado o codificador que por sua vez estará conectado ao transmissor (veja esquema). Em  Um Pippo teremos o inverso: O sinal de RF será recebido pelo receptor, demodulado e enviado ao decodificador que passará os dados ao nó (N=0, G=0).

Outra função que estou implementando é a possibilidade de gravar percursos (representados por vetores de posição relativa) na EEPROM, de modo a que Um Pippo possa executá-los, ou, ele mesmo gravá-los a partir de percursos executados autonomamente, para posterior análise, repetição ou reversão.

NOTA1 - Vários assuntos, desenvolvimentos e testes que tenho relatado podem estar parecendo fora de sincronia em relação à linha de desenvolvimento de Um Pippo. Essa sensação irá diminuindo à medida que formos estabelecendo novos níveis de competência (NCR) para Um Pippo. Os níveis de competência que estão consolidados até hoje são: NCR0 e NCR1. Brevemente, estaremos definindo o NCR2 que terá a ver com vários dos testes feitos.

<06.08.2003>

Após duas semanas de encrenca total (o Windows XP do meu PC ficou esquizofrênico e não houve maneira de recuperá-lo, a única saída foi reinstalar tudo do zero. A minha sorte foi que todos os meus dados estavam em uma partição separada do disco. Essa experiência traumática me convenceu a ter uma esquema de backup contra desastres. ) voltei a trabalhar no link de RF. Para isso, adotei o PortIODriver (Dll e NT Kernel Driver) da Scientific Software Tools, Inc e desenvolvi todas as rotinas e interfaces para VB. Este pacote todo (Dll, NT Kernel Driver, programa em forma executável para teste das portas paralelas e rotinas fonte em VB para manipulação direta dos pinos de portas paralelas EPP e ECP) em forma instalável via Setup para Windows 95, 98, Me, NT, 2000 e XP, está disponível em CD. Uma das vantagens deste software é que ele consegue endereçar portas paralelas em placas PCI que montam os registradores em endereços altos (por exemplo &HFF80) , além das antigas ISA (que usam os tradicionais endereços: &H278, &H378 e &H3BC).

<14.09.2003>

Neste último mês dei continuidade ao desenvolvimento do link de RF, através do desenvolvimento de um aplicativo em VB que identifica as portas paralelas do PC, permite a escolha de uma delas, edita meta-comandos e envia comandos executáveis ou seqüências deles através da porta escolhida para uma  interface de 8 ou 16 bits com controle de latch e protocolo de envio/recepção.

<06.10.2003>

O programa para enviar comandos via porta paralela  EnvComPar está disponível em CD.

<04.11.2003>

Com o término do desenvolvimento do link de RF, retomei os testes finais da integração funcional dos vários blocos no BX01 (N=1, G=1) (vide acima) que tinham sido interrompidos.

Veja em Novidades o menor Ethernet Web Server do mundo !

<30.01.2004>

Para a integração funcional dos blocos no BX01(N=1,G=1), foram revistas todas as rotinas para movimentação ( agora na sua versão 5.3)  e foi desenvolvida uma placa com interface serial incluindo :

1  BX01  -  programado com recepção de comandos de movimentação via serial.

2  LM629

2  LMD18200

A nova versão do software para esta placa : MMPIDLM629 (Versão 5.3), está disponível em CD. Futuramente estará disponível também a placa.

O próximo passo será desenvolver uma placa padrão para os nós da rede (veja esquema).

<03.04.2004>

Para melhorar a modularidade, a placa para movimentação foi dividida em duas: a MMLMD18200 que já está disponível e a MMPIDLM629 que estará disponível brevemente.

<28.04.2004>

Está disponível a placa MMPIDLM629, com isso a parte de movimentação do robô (placa MMLMD18200, placa MMPIDLM629 e software MMPIDLM629 V5.3) está completa. A placa BX01NODE (para os nós da rede RS485) estará disponível a partir de 15/05/2004.

<15.05.2004>

A placa BX01NODE está disponível. A ela é possível conectar um modem "wireless" da MaxStream tipo 9XCite de 900Mhz 38400baud (XC09-038WNC). Com isso e outro modem ligado ao PC, é possível enviar comandos remotamente a  Um Pippo e receber de volta informações sobre o status do robô e sua "Pose" em relação a um sistema de referência, via odometria. Posteriormente, as informações de odometria, do sensor de ultra-som (SRF08) e da bússula eletrônica (Vetor2X), serão integradas via filtro de Kalman.

<07.06.2004>

Veja novas fotos de Um Pippo com as placas montadas e o sensor de ultra-som para distância SRF08 montado sobre um servo Futaba S3003 o que lhe permite um heading variável para a esquerda e para a direita de até 45º para cada lado. Na plataforma superior é possível ver as placas MMLMD18200, MMPIDLM629, BX01NODE, o modem 9XCite, o servo S3003 e o sensor SRF08. Na plataforma inferior estão as duas baterias de 12VDC e um protoboard contendo um regulador LM2675-5.0 (5VDC, 1A) e um pequeno relé tipo reed switch.

<19.07.2004>

Após os testes de integração, desenvolvi e testei um programa para o comportamento básico (NCR0) de  Um Pippo, considerando somente os objetivos de vagar e evitar obstáculos. A primeira experiência foi com um único SRF08 montado num servo (vide acima). Os resultados foram razoáveis mas foi possível detectar dois pontos fracos nesta primeira tentativa:

  1. Pouca informação sobre o ambiente conseguida com um único SRF08.

  2. Medições com freqüência baixa em função do tempo necessário para posicionamento do servo, acarretando não detecção de informação importante para os objetivos de Um Pippo.

Numa segunda tentativa, passei a usar três SRF08 fixos: um na direção do heading do robô e os outros dois com o eixo a 60° do heading para a esquerda e para a direita. Os resultados foram muito melhores e Um Pippo conseguiu ficar muito tempo vagando e evitando obstáculos. Mesmo assim persistiu (mas em grau muito menor) o problema de necessidade de maior informação instantânea sobre o ambiente. Além disso, a quantidade de condições de status e ações a serem programadas, cresceu muito.

Com isso, o próximo passo será utilizar uma abordagem diferente:

  1. Utilizar oito SRF08 distribuídos simetricamente ao redor do deck superior de Um Pippo.

  2. Utilizar o conceito de Vetor Percepção como visão instantânea do entorno do Robô.

  3. Utilizar o método de seguir a parede ("wall following") para vagar e evitar obstáculos.

  4. Utilizar uma máquina de lógica Fuzzy para inferir a próxima ação em função do Vetor Percepção num determinado instante.

Chamo esta abordagem de SPAOFE  (Sonar Perception Avoiding Obstacle Fuzzy Engine). Ela será implementada fisicamente utilizando um microcontrolador Atmel ATmega128 programado em C com o CodeVisionAVR. O motivo para a mudança de microcontrolador é que o BasicX01 (AT90S8515)  não tem recursos suficientes para a implementação do SPAOFE. A mudança de linguagem deve-se a não existir BasicX para o ATmega128L.

Numa próxima atualização falarei sobre a teoria que embasa a máquina SPAOFE.

<15.08.2004>

A máquina SPAOFE está sendo projetada como um módulo físico (ao qual se acoplam os sensores SRF08) que interligará um nó da rede RS485 (placa BX01NODE) (via RS232 e 3 interrupções externas) com a placa MMPIDLM629 (via RS232 e uma interrupção externa). Este módulo vai implementar três grandes funções:

1. Um agente de "Subsumption".

2. Cálculo dinâmico do Vetor Percepção Geral.

3. Módulo de controle fuzzy para inferência dos comandos de movimentação mais adequados.

<12.09.2004>

As rotinas e funções para o cálculo dinâmico do Vetor Percepção Geral foram desenvolvidas e testadas. Para o desenvolvimento do módulo de controle fuzzy, decidi primeiro fazer um modelo completo usando a Fuzzy Toolbox do Mathlab para verificar o comportamento e ajustar  as funções de membership e a base de regras. Com o modelo funcionando corretamente, iniciei a programação em C para transferi-lo para o ATmega128L. 

 

<06.10.2004>

Para implementar a máquina SPAOFE, escolhi um módulo Crumb128 (que usa um ATmega128 com clock de 14,7456 MHz). O Crumb128 usa a capacidade de auto-programação do ATmega128 e já vem com um "BootLoader" gravado na área de boot da memória flash. Isso permite carregar o programa na área de programa da memória flash através de uma simples conexão RS232 a uma porta serial do PC  e diretamente do CodeVisionAVR. Completei a programação e testei o módulo de controle Fuzzy (lógica nebulosa) e o cálculo dinâmico do vetor percepção geral. O próximo passo é desenvolver o agente de "Subsumption" e os canais de entrada e saída da máquina SPAOFE.

<02.11.2004>

Para poder desenvolver o agente de "Subsumption" para o módulo Crumb128, voltei primeiro ao desenvolvimento do nó 0 (N=0 G=0) que implementa a coordenação geral via filas, prioridades e semáforos. Este desenvolvimento está muito interessante pois permite usar técnicas para processamento paralelo/assíncrono via rede de microcontroladores.

Estou testando um método muito simples para implementação e controle de uma base robótica para movimentação holonômica, através de servos R/C modificados para aceitar rotação contínua e controle de velocidade através de encoders de dois canais em quadratura. Despertei seu interesse? Então escreva-me.

<24.12.2004>

Infelizmente desde o início de Novembro o projeto está parado em função de vários problemas familiares de saúde. Estou retomando hoje o desenvolvimento (véspera de Natal ! - aliás, bom Natal e Ano Novo para todos !!!) . Toda vez que paro o projeto por um tempo mais longo, a retomada do ritmo normal é demorada e difícil. Mas, para não desanimar, aqui vão os programas com os quais estou trabalhando. Eles não estão terminados nem completamente testados mas servem para dar uma idéia do nível de complexidade de Um Pippo.

<07.01.2005>

Para entender melhor qual será o comportamento de Um Pippo, veja aqui o diagrama de comportamentos que está sendo implementado.  À medida que implementarmos os novos comportamentos, definiremos os novos Níveis de Competência do Robô (NCR).

<20.01.2005>

Veja aqui as fotos (11 a 15) dos "olhos" de Um Pippo. A visão é composta de uma câmara CMUcam, um sensor piroelétrico Eltec 442-3 e um servo Futaba S3003.

<31.03.2005>

Nestes últimos dois meses o desenvolvimento de Um Pippo andou devagar em função de problemas familiares continuados. Espero que finalmente essa fase tenha se encerrado. Consegui somente fazer os testes para controle do servo, os para detecção de pessoas com o Eltec 442-3 e os testes da CMUcam utilizando uma interface GUI em java, fornecida pelo The Robotics Institute da Carnegie Mellon University. Antes de poder fazer os testes acima, tive que implementar duas interfaces seriais RS232 adicionais para o ATmega128, já que o controlador de servos e a CMUcam tem interface serial. Implementei as interfaces seriais, utilizando o integrado MAX3110E da Maxim. Este integrado combina uma UART com uma interface RS232 totalmente integrada e tem conexão com o microcontrolador via uma interface SPI escrava. Isso significa que podemos ter quantos MAX3110E quisermos, utilizando somente os pinos de SPI. Aqui você encontra os programas para utilização do Max3110E, Eltec 442-3 e controlador de servos.

<20.04.2005>

Testei com sucesso o módulo IRCFL. Com isso, encerro a parte de sensoriamento de Um Pippo e fica definido então o seu NCR final. Veja aqui como ficou a arquitetura final de Um Pippo. Nesses diagramas você encontra os módulos de hardware e software, o esquema de "arbitration" e os comportamentos. Daqui para a frente, estarei falando sobre programação dos módulos, interfaces, particularidades dos microcontroladores usados, testes operacionais, montagem e interligação dos módulos, etc.

<02.08.2005>

Depois de bom tempo em que me dediquei a assuntos pendentes, estou de volta trazendo o desenvolvimento da placa que chamei de KERNEL. Esta placa, junto com as placas MMLMD18200, MMPIDLM629 e VECTOR2X_VOICE compõe o "ego" de Um Pippo. O próximo passo será a consolidação final do firmware  e do software de aplicação de cada uma dessas placas.

<10.09.2005>

Para a consolidação do firmware e do software aplicativo da placa KERNEL, vou usar:

firmware:                                                                                                

Como a placa é baseada num microcontrolador ATmega128 da Atmel que permite "self-programming", vou utilizar um "boot loader". Com ele farei a carga dos programas diretamente do CodeVisionAVR no PC via RS232, sem necessidade de utilizar o STK500 e STK501.

software:

Para o desenvolvimento do software de coordenação vou utilizar a linguagem C, o compilador CodeVisionAVR e o executivo de tempo real PR_RTX. O PR_RTX vai me permitir programar em "multitasking" de modo a atender todos os eventos assíncronos gerados pelos vários sensores e interfaces de Um Pippo.

<28.10.2005>

Chegaram os giroscópios CRS07-11 da Silicon Sensing e o acelerômetro ADXL202EB da Analog Devices que vou utilizar no Dois Pippo. Dois Pippo vai ser um robô cuja principal característica será implementar um pêndulo invertido se deslocando em movimento autônomo.

<26.01.2006>

Os testes com o PR_RTX não deram bons resultados. Ele funciona bem para tasks simples como acionamento de LEDs mas não consegui resultados quando tentei fazer multitasking com tasks complexas utilizando comunicação serial, I2C e SPI. O problema é que p PR_RTX não é preemptivo e aparentemente o seu esquema de prioridades e tempo de execução por task entra em conflito com o "timing" necessário aos protocolos I2C e SPI. Em função disso, estou aguardando (conforme prometido pela Atmel para meados de fevereiro) o release de um plugin (no Studio 4) para o uCOS-II. O uCOS-II é considerado o melhor RTOS do mercado. Com isso, será possível programar em multitasking preemptivo, de forma integrada, usando o Studio 4 e o WinAVR.

<07.02.2006>

Enquanto aguardo a publicação do plugin para o uCOS-II, resolvi fazer algumas experiências com Autômatos Finitos Determinísticos. Como resultado, desenvolvi uma Máquina para processar Autômatos Finitos Determinísticos (M_AFD). Para desenvolver esse software utilizei  o CodevisionAVR (C) e a técnica de pointer para função. Com software desse tipo, contando com microcontroladores velozes e conseguindo modelar o problema através de AFDs, poderíamos dispensar o uso de RTOS.

<21.03.2006>

Este é um exemplo de uso de Embedded Web Server no projeto CoMeVI (Controle de Mecanismos Via Internet). Neste caso estou usando um Siteplayer servindo uma página que recebe comandos e os envia ao robô para execução. Estou desenvolvendo uma nova página para exemplificar melhor o que ocorre. Nessa página será possível comandar um servo-motor com indicação visual de posição enquanto uma câmara em tempo real reportará a imagem do movimento.

<10.05.2006>

Nestes últimos dois meses aconteceram todas as encrencas possíveis. Realmente o Murphy era otimista. Primeiro pifou a placa ATI do meu notebook e tive que mandá-lo para os EUA pois estava na garantia. Em seguida pifou a máquina do laboratório onde faço todos os desenvolvimentos. Por último pifou a máquina do meu escritório. Conclusão, passei estes últimos dois meses basicamente recuperando máquinas. Finalmente estou conseguindo voltar aos meus planos. Neste fim de semana montei uma nova máquina com Windows XP e um servidor Apache. Essa máquina é o novo servidor deste site (www.robotica.eng.br) e dos outros que estou preparando para o projeto CoMeVI. Com esse servidor as coisas ficaram mais simples pois ele está fisicamente ao meu lado e eu me tornei meu próprio provedor.

No próximo fim de semana estará chegando a câmara IP que vou usar no projeto CoMeVI. Ela é uma D-Link DCS-6620G. Essa câmara tem controle via web de pan, tilt e zoom. Ela será controlada via web para acompanhar o que se comandará ao step-motor fazer via web. O progresso do projeto CoMeVI poderá ser acompanhado pelo site http://comevi.robotica.eng.br .

<16.05.2006>

Recebi e instalei a DCS-6620G. Atenção! funciona somente com o Internet Explorer (ou Firefox com extensão IE tab), e exige a instalação de um ActiveX. Maiores detalhes em http://comevi.robotica.eng.br .

<01.08.2006>

Nestes últimos dois meses tive que deixar de lado os desenvolvimentos para poder reformular o servidor. Agora parece que está tudo estável e meus sites estão numa máquina  com sistema operacional Linux Ubuntu (aliás uma beleza! - quem tiver interesse pode acessar: http://www.ubuntubrasil.org/ ).

<17.10.2006>

O site que demonstra o controle de mecanismos microcontrolados via Internet está no ar, acesse-o pelo enderêço http://comevi.robotica.eng.br (após registro, desbloqueio e log-in, a câmara vai pedir um nome de usuário e uma senha, use comevi para os dois). Maiores detalhes em http://comevi.robotica.eng.br .

<21.10.2006>

Desativei o site que demonstra o controle de mecanismos microcontrolados via Internet porque estava bloqueando a câmara e o microcontrolador que me são necessários em outro projeto. O site, nos poucos dias que esteve no ar, conseguiu demonstrar que é possível controlar via Internet qualquer mecanismo, em qualquer nível de sofisticação desde que ele possa ser interfaceado com um microcontrolador. O custo deste tipo de controle é extremamente baixo. Para os interessados no assunto, estou disponibilizando o software fonte completo que desenvolvi para esse projeto (veja em http://comevi.robotica.eng.br). Quaisquer dúvidas podem ser encaminhadas para webmaster@robotica.eng.br .

Ao mesmo tempo em que retorno à utilização do uCOS-II na consolidação final de Um Pippo, vou desenvolver a especificação para o projeto de Dois Pippo. Lembrando o que eu já disse antes,  Dois Pippo será um robô baseado na dinâmica do pêndulo invertido.

<14.04.2007>

Neste último período Dois Pippo começou a tomar forma. Comecei desenvolvendo a estrutura física através da escolha dos componentes para a base e as placas microcontroladas que serão utilizadas. A estrutura foi montada com barras de alumínio conseguidas em desmanche, as rodas são da Jelmark e os motores com encoder integrado são os EMG30 da Devantech. As placas que serão utilizadas são: MMLMD18200, MMPIDLM629 e KERNEL. Os sensores inerciais que serão utilizados são o giroscópio CRS07-11 e o acelerômetro ADXL202EB. Veja mais fotos de Dois Pippo.

 

Nesse mesmo período comecei a desenvolver o SADÁ (Sistema de Automação da Disponibilização de Água). Isso ocorreu por uma necessidade pessoal de resolver um problema de automação residencial de uma certa complexidade em minha casa no litoral. Veja as especificações do SADÁ (abra no IE ou no Firefox com IE tab). Para este projeto vou utilizar um microcontrolador BX-01.

Nos próximos meses darei detalhes de Dois Pippo e do  SADÁ

<13.11.2007>

O projeto SADÁ está pronto. Aqui está o esquema, a placa e o programa.

 


Funcionamento do sistema SADÁ

Subsistemas:

 1. Sabesp (S)
 Fornecimento público de água potável. O controle do fluxo de água é feito através de uma
 eletroválvula (Vs) (220v).

 2. Caixa inferior (Ci)
 Caixa enterrada de 12.000 litros que tem por finalidade manter um estoque de segurança de
 água que é coletada do sistema Sabesp ao nível do chão, portanto com pressão mínima.
 A funcionalidade desta caixa é composta por uma bóia mecânica para caixa cheia, uma bomba
 vibratória (B) (220v ; 1000 l/h), um sensor (N4) de nível mínimo de água para proteção da
 bomba e uma eletroválvula (Vb) (220v) na saída da bomba para controle do fluxo de água.

 3. Caixa superior (Cs)
 Caixa de 2.000 litros sob o telhado da casa que serve a casa toda através de um sistema de
 pressurização. Esta caixa recebe água diretamente da Sabesp ou da caixa inferior (Ci) através
 da bomba (B). A funcionalidade desta caixa é composta por um “ladrão” para segurança, por um
 sensor de entrada de água (Fa), por um sensor de nível máximo (N1), por um sensor para
 acionamento da entrada de água (N2) e por um sensor de nível mínimo de água (N3) para proteção
 do subsistema de pressurização.

 4. Pressurização (Pr)
 Subsistema (Dancor) composto por uma bomba (220v), um tanque de 100 litros e um pressostato
 para controle da pressão da água nas tubulações da casa. Este subsistema mantém automaticamente
 uma pressão de 40 psi na tubulação, através da bomba controlada pelo pressostato.

Funcionamento:

 Em condições normais (existência de água da Sabesp) a Cs estará oscilando entre os níveis N1 e
 N2 sendo alimentada diretamente pela Sabesp, o pressurizador estará desbloqueado alimentando a
 casa e a Ci estará cheia, controlada pela bóia mecânica. Quando o nível cai abaixo de N2, a
 eletroválvula da Sabesp (Vs) é acionada, permitindo a entrada de água. Quando o nível N1 é
 atingido, Vs é desligada bloqueando a entrada de água.

 No caso de falta de água da Sabesp, quando o nível em Cs cai abaixo de N2 ela passa
 automaticamente a ser alimentada pela Ci através da bomba (B) iniciando um ciclo que somente
 reverterá para a Sabesp (se o fornecimento voltar) após Cs atingir o nível N1. Se continuar
 faltando a água da Sabesp, a Cs continuará oscilando entre os níveis N1 e N2 mas agora alimentada
 pela Ci através da bomba (B) e da eletroválvula (Vb).

 Independentemente da alimentação da Cs (Sabesp ou Ci), caso o nível em Cs caia abaixo de N3,
 o pressurizador é bloqueado para proteger sua bomba. Quando o nível volta acima de N3,
 o pressurizador é desbloqueado.

 Quando a Cs estiver sendo alimentada pela Ci através da bomba (B), o nível da água em Ci começa
 a baixar (porque não há entrada de água da Sabesp, caso contrário a alimentação de Cs teria
 revertido para a Sabesp) e poderá chegar a ser menor que N4. Neste momento, a bomba (B) é
 bloqueada para proteção. Com a volta da água da Sabesp, e o nível em Ci acima de N4, a bomba é
 desbloqueada, o sistema reverte a alimentação de Cs para a Sabesp e Ci passa a ser alimentada
 pela Sabesp até ficar cheia e a bóia mecânica ser acionada.

 Quando a alimentação de Cs estiver sendo feita pela Ci através da bomba (B) e o sistema perceber
 que a bomba não está mais funcionando (ou queimada), é dado um alarme visual e sonoro para avisar
 da falha da bomba. Apesar disso, o sistema não é bloqueado de modo que se nesse ínterim a água
 da Sabesp voltar, a alimentação de Cs é revertida para a Sabesp e o sistema volta ao normal
 porém com a bomba bloqueada e com alarme de bomba inoperante. Após a troca da bomba, o sistema
 precisa ser reinicializado para incorporar a bomba (B).

 Em alguns casos detectáveis de falha nos sensores de nível, o sistema se inibe bloqueando tudo
 e dando alarme visual e sonoro de sistema em colapso.

 Os elementos de interação com o sistema são:
 Al (Al) - Alarme sonoro
 Led1 (L1) - Led vermelho
 Led2 (L2) - Led amarelo
 bit0 (L5) - Led verde
 bit1 (L4) - Led verde
 bit2 (L3) - Led verde
 Itr (S1) - Botão para o acionamento do interrupt (ver descrição na rotina Interrupt)
 S2 (S2) - Botão para acionar o display do Status do sistema via os leds (ver descrição na rotina Mostra)
 (S3) - Botão para o reset de hardware (reinicializa o microcontrolador)
 S4 (S4) - Botão para silenciar o alarme sonoro
 (R4) - Trimpot para ajuste da voltagem do ADC (cuidado!)

 O display das variáveis de estado do sistema nos permitirá analisar o funcionamento do sistema,
 especialmente quando for sinalizado algum problema.

 


Os sensores mais simples utilizados no sistema são bóias de contato. Os sensores de Fa e de Cs merecem um esclarecimento melhor. Eles são sensores da Cashtec  o de Fa (LFS-075CVM5-PVNO) é um sensor de fluxo e o de Cs (LS8-ST) é um sensor contínuo de nível. O LFS funciona como um switch, fechado quando tem fluxo de água e aberto quando não tem fluxo de água. O LS8 funciona como uma resistência variável (0 a 180 ohms) com o nível da água. Para ler o sensor LS8, utilizei um amplificador operacional (LM358) para acertar a saída como voltagem variável (0 a 5VDC) proporcional ao nível de água. Essa voltagem é lida por um ADC0831 que digitaliza o valor e o transfere ao BX-01 como um valor entre 0 e 255 proporcional ao nível da água. No sistema, para resolver o problema de "debouncing", foi utilizado o integrado MC14490. As eletroválvulas, o pressurizador e a bomba são acionados via relés com capacidade para a corrente e tensão apropriados (10A, 220V). Em função disso, o acionamento dos relés é feito através dos transistores 2N2222 e as bobinas dos relés tem diodos em paralelo para dissipar os picos gerados pela indutância da bobina quando do desligamento do relé.

<Início da Página>