Este trabalho prático foi desenvolvido como suporte para a competição Robô-Vírus que acontecerá em breve. Nele, devíamos apresentar uma série de tarefas para mostrar que nosso robô está plenamente funcional e apto para obter bons resultados na competição.

Nosso robô deveria ser capaz de realizar as seguintes tarefas:

1. Ser capaz de ser calibrado em 60 segundos ou menos;
2. Entrar em modo de espera após a calibraçao;
3. Ser posicionado manualmente sobre a luz de partida mas em uma orientação arbitrária e orientar-se segundo a luz polarizada;
4. Iniciar o cumprimento da sua tarefa após acesa a luz de início;
5. Não queimar a largada;
6. Aprender a orientar-se no campo autonomamente;
7. Coletar o bloco que encontra-se sobre a linha;
8. Identicar a cor do bloco;
9. Carregar o bloco até a base;
10. Subir e descer uma rampa 5 cm com 18 graus de inclinação (aproximadamente);
11. Desligar todos os atuadores ao término dos 60 segundos;

A construção do nosso robô foi realizada em diversas etapas, sempre tendo em vista a melhoria da robustez do mesmo. A primeira etapa teve como objetivo diminuir o tamanho do robô no comprimento, já que, depois do TP3, ele media pouco mais do que 30 cm. Para isso tornamos seus componentes mais próximos uns dos outros, sendo a principal mudança a da roda (a posicionamos mais próxima ao “corpo” do robô). Esta aproximação acabou por resolver outro problema que tínhamos, o uso de esteiras, que conectava o bloco de engrenagens de redução aos eixos das rodas.

Uma estrutura precisou ainda ser acrescentada, a garra. Inicialmente foi planejada a utilização de uma garra com dois “braços paralelos” ligados a hastes que se movimentavam horizontalmente, a abrindo e fechando. Esta hastes se ligariam a um mesmo conjunto de engrenagens, que as acionariam em sentidos opostos, e este conjunto estaria ligado a somente um motor. Mas várias foram as dificuldades desta idéia, e elas serão mostradas no tópico “Dificuldades encontradas”.

A estrutura implementada então foi uma com duas hastes, projetadas para a frente do robô, para facilitar o arraste dos blocos. A vantagem dessa estrutura é que ela ficou bem fixa no robô, enaltecendo a construção mecânica do mesmo.

Depois de termos uma estrutura com as correções necessárias, os esforços foram concentrados no inter travamento, pois além de ser uma boa prática no uso de peças LEGO, o robô deve resistir a pequenos choques.

Outro aspecto de extrema importância na contrução foi a utilização de sensores. O sensoriamento deste robô se baseia em 5 LDR`s, 4 LED`s, 2 filtros polarizadores e dois sensores de contato, divididos em: sensor para identificar cores (4 LED`s e 1 LDR), sensores para identificação de luz polarizada (2 LDR`s e 2 filtros polarizadores), indentificação da iluminação debaixo do robô (2 LDR`s) e identificação de obstáculos (2 sensores de contato).

O sensor de identificação de cores já estava pronto desde o último trabalho, são 4 LED`s, um amerelo, um azul, um vermelho e um verde, que são ligados um a um, quando são realizadas medidas no LDR, e os valores obtidos comparados aos encontrados na calibração, e a cor é encontrada.

Assim como o anterior, o sensor de identificação de luz polarizada também já estava pronto, que pode ser visto como 2 sensores na realidade. Cada “metade” do sensor é um LDR envolto por uma proteção escura em suas laterais (para evitar interferência de luzes indesejadas) e em sua frente por um filtro polarizador paralelo a uma das luzes do campo de competições (sendo os dois filtros assim perpendiculares entre si). Com medidas de cada um dos sensores comparadas àquelas obtidas na calibração é possivel identificar se o robô está na direção de uma das luzes.

O sensor para identificação da iluminação já existia também no TP3, porém com outra finalidade, de seguir linha. Como a linha era seguida de acordo com a leitura do LDR da iluminação do chão, ele pode ser usado na identificação da luz de partida.

O último conjunto de sensores foi o único novo neste robô, os sensores de obstáculo. São usados dois sensores de contato, um em cada garra, em sua extremidade, para que ao encontrar um obstáculo eles sejam ativados e a atitude necessária para sair daquele obstáculo seja tomada.

Várias dificuldades foram encontradas para a construção correta deste robô. A primeira foi de natureza intrínseca, já que o robô não funcionava para todas as tarefas exigidas no TP3 e, como já falado, media mais do que o máximo especificado. Logo, tivemos de refazê-lo algumas vezes para que sua construção ficasse satisfatória.

Como uma das atividades da prévia era subir uma rampa, algumas modificações no robô foram feitas com esta finalidade. A primeira foi alterar a frente do robô. Anteriormente, a frente era localizada na parte onde os eixos das rodas estavam inseridos. Isso fez com que o robô não tivesse força para subir a rampa, fazendo com que o roll-on ficasse deslizando. Assim, mudando a frente para a parte onde o roll-on se localizava, fez com que houvesse potência e torque suficiente para que o robô subisse. Infelizmente, com as alterações feitas após isso, para inserção de garras e dos sensores, o robô não foi capaz de subir a rampa no final de seu projeto. Como esta atividade não era de muita relevância em comparação com as outras desejadas, desconsideramos-a, já que na competição não é necessário fazê-la.

A segunda dificuldade veio com a o funcionamento dos sensores. Isso porque inicialmente os LEDs utilizados para reconhecer cores estavam fracos, logo seu funcionamento não estava correto 100% dos testes. A solução para isso foi trocarmos todos eles por LEDs de alto brilho, o que facilitou a realização da tarefa requerida. Mas a utilização desses sensores dificultou um pouco mais na atividade de detectar o bloco na frente do robô. Após algumas modificações no software, obtivemos sucesso nessa atividade.

Os sensores de contato também apresentaram alguns problemas. Isso porque um dos que nos foi fornecido estava um pouco duro, de forma que não estava sendo acionado quando o robô batia na parede obliquoamente. Assim, tivemos de trocá-lo. Outro problema relacionado a esses sensores foi o posicionamento deles no robô. Na posição em que foram deixados, as vezes eles não acionavam pois ficavam para cima da parede da arena. Este é um problema que iremos resolver para a competição, a ser realizada em breve.

Como falado na construção do robô, em uma das etapas tentamos construir uma garra para captar os blocos na arena da competição. Esta ferramenta apresentou diversos problemas de construção e de inserção da mesma no robô já construído. Primeiramente, tentamos construir um mecanismo para ser acionado com apenas um motor. Isso fez com que a garra ficasse grande para ambos os lados, já que tivemos de colocar três roldanas para transmissão do movimento correto, pois os “braços” do instrumento deveriam ser movidos em direções contrárias. Este problema foi fonte de outro grave: a falta de peças para a construção simétrica da garra. Assim, ela estava ficando desbalanceada e, quando tentamos encaixá-la no robô, ela ficou pouco travada. Como nosso objetivo inicial era fazer um robô bem robusto, com construções mecânicas corretas e intertravadas, tentamos fixar mais a garra no robô. Mas outro problema estava ocorrendo, já que precisávamos de um motor para acionar o instrumento. Após sugestões do professor Mário, resolvemos utilizar o motor do LEGO para tal tarefa. Como nosso robô estava bem compacto, não houve um lugar onde encaixar este motor, já que o único lugar encontrado fazia com que a garra tampasse os sensores LDR para a luz polarizada, o que prejudicaria em muito nosso robô. Vale ressaltar que, caso todos esses problemas fossem resolvidos, ainda haveriam outros problemas para o funcionamento da garra: o motor deveria acioná-la por um intervalo de tempo muito curto, que seria complicado de calibrar; quando ela fosse acionada para pegar os blocos havia a possibilidade dela desmontar, já que sua estrutura possuia uma parte móvel impossibilitada de travamentos com o restante do robô; e , se os blocos fossem carregados, havia a possibilidade deles serem soltos no caminho até a base, já que não haveria nenhum tipo de acionamento do motor para forçar a garra a ficar fechada, pois isso seria fatal para nosso motor.

Após tantos problemas encontrados para o funcionamento da nossa engenhosa garra, optamos por um projeto mais simples, como já falado. Porém, este projeto também apresentou dificuldades. Como eram apenas duas hastes projetadas para a frente do robô, que iriam arrastar o bloco detectado em sua frente, havia a possibilidade de perdermos o bloco enquanto o robô virava para voltar a base. Uma solução pensada para este problema é que o software pudesse fazer o robô virar uma certa quantidade e andar um pouco para frente, para consertar seu englobamento do bloco. Porém essa solução não foi implementada, já que nosso robô não ficou pronto em tempo suficiente para realizar tal atividade.

Após todos os componentes em separado serem testados e estarem bem construídos, obtivemos alguns problemas com o software. Isso porque ao juntarmos todas as atividades que o robô deveria apresentar, sofremos com as limitações da Handy Board: nela, quando ativamos quatro processos ou mais simultaneamente, nos deparamos com RUNTIME ERROR 2. Logo, tivemos de realizar algumas atividades sequenciais. Este foi o grande motivo da primeira apresentação ter sido fracassada.

Por último, vale colocar que, como em todos os TPs, o tempo e a quantidade de atividades extras realizadas pelos componentes do grupo também foram fatores limitadores do sucesso do robô. Pretendemos que na competição consigamos atingir maior sucesso do que o apresentado na prévia.

Como já mencionado, a apresentação não foi realizada com sucesso, e como teremos mais uma chance, na segunda-feira este tópico ainda precisará ser atualizado com as decisões e os resultados finais. Mas, até la estão aqui os documentos presentes.

Vale ressaltar que tentaremos implementar em nosso robô todas as atividades propostas para ele. Além disso, observamos a apresentação dos outros grupos e ouvimos comentários pertinentes acerca da implementação do código para algumas tarefas, como, por exemplo, consertar a posição do robô quando há o choque com a parede. Em nosso código, apenas movemos a roda cujo lado possui o sensor de contato que não foi ativado. Como um grupo que apresentou em nossa frente foi aconselhado a mudar este código, já que é possível que uma roda não possua torque suficiente para girar o robô como um todo (considerando que a outra está travada), também acataremos tal mudança no nosso. Porém, o código mostrado no presente momento ainda possui as imperfeições vistas na apresentação.

Figura 1- Vista lateral do robô

Figura 2- Vista frontal

Figura 3- Detalhe do sensor de identificação de cor

Figura 4- Detalhe dos sensores de luz polarizada

Figura 5- Detalhe sensor de luz de início

relatorio_previa.pdf

codigo_previa.rar