Projeto e desenvolvimento de um robô de inspeção de baixo custo

1. Introdução

A infraestrutura de nossa nação está envelhecendo e se deteriorando rapidamente. Atualmente não há nenhum mecanismo para inspecionar completamente a condição de nossas pontes, tanques de resíduos, dutos e reatores. Muitas dessas estruturas chegaram ao fim de sua vida útil e precisam ser inspecionadas quanto à deterioração. Assim como em terra, há também a necessidade de inspecionar os cascos e conveses dos navios da Marinha dos Estados Unidos e dos petroleiros em busca de sinais de corrosão. Muitas estruturas antigas, como pontes altas e tanques de resíduos, costumam ser difíceis de sondar ou inspecionar por uma série de razões. O motivo mais comum é que o processo de inspeção é perigoso para os humanos ou a estrutura tem seções que são inacessíveis. Outro motivo comum é que a tecnologia de sondagem atual pode ser inadequada para inspecionar com precisão essas estruturas. Portanto, a inspeção manual é infrequente, trabalhosa, cara, perigosa e sujeita a erros. Este problema oferece uma oportunidade perfeita para um robô de inspeção bem feito.

Os robôs de inspeção são normalmente projetados e desenvolvidos por grandes equipes bem financiadas de engenheiros elétricos e mecânicos. Robôs comerciais, como o Packbot 510 (http://endeavorrobotics.com/products), podem custar mais de US $ 100.000. Dadas as restrições de um projeto individual de feira de ciências, o escopo aqui é projetar, desenvolver e testar um protótipo barato para um robô de inspeção. O objetivo deste projeto é desenvolver um protótipo de robô de inspeção pequeno, leve e barato que possa ficar preso às superfícies a serem inspecionadas. O projeto é composto pelas seguintes tarefas:revisão da literatura e designs existentes; especificação de requisitos; projeto do robô; desenvolvimento do protótipo inicial e teste; cálculos de mecânica de engenharia; programação do robô usando Python; desenvolvimento e teste do segundo protótipo; e desenvolvimento e teste do protótipo final.

Antes de construir fisicamente o robô, o software de modelagem 3D SketchUp foi usado para visualizar o robô e refinar o projeto. O robô foi construído com componentes de prateleira, incluindo um módulo Raspberry Pi 3 para controlar o robô. O design foi aprimorado iterativamente por meio de testes repetidos. O código Python foi escrito do zero para programar o robô. Conforme o design evoluiu, o hardware e o software tiveram que ser modificados em conjunto. O protótipo foi demonstrado para especialistas em engenharia do Washington River Protection Solutions e do Pacific Northwest National Laboratory, e para a classe de design sênior no estado de Washington

Universidade, Tri Cities. Com base no feedback dos especialistas, cálculos de engenharia mecânica e resultados dos testes, o terceiro protótipo foi construído e programado. O robô resultante é capaz de escalar paredes a uma velocidade razoável e possui várias câmeras para ajudar na navegação e inspeção. O robô produzido por este projeto representa um design único com software escrito especificamente para este fim. Este protótipo serve como uma plataforma flexível em que novos sensores podem ser adicionados conforme necessário para aumentar os recursos de inspeção.

2. Revisão de literatura

Antes de começar a trabalhar no projeto, fiz uma revisão da literatura para avaliar as soluções existentes. As sondas disponíveis atualmente podem ser classificadas em dois tipos - estacionárias e móveis.

As sondas estacionárias são a ferramenta mais amplamente usada para inspecionar estruturas. Eles fornecem informações muito detalhadas sobre uma seção específica de uma estrutura e podem monitorá-la continuamente. No entanto, uma vez posicionados em um local, o alcance de observação será limitado. Devido à falta de mobilidade, eles são inadequados para monitorar grandes estruturas. A outra categoria é composta de probes montados por robôs. Eles oferecem um maior grau de funcionalidade, pois a sonda pode ser movida livremente. A maioria dos robôs atualmente no mercado é muito especializada em uma tarefa específica ou tipo de inspeção. Alguns robôs podem se especializar em atravessar água, grandes altitudes ou terreno pantanoso semissólido, mas nenhum desses robôs é útil para inspeção estrutural.

O robô de inspeção aquática AQUA ¹ é um ótimo exemplo. O AQUA é um robô de inspeção altamente especializado e caro. Ele rasteja no leito de corpos d'água e faz varreduras tridimensionais (3D) de sua área. É capaz de usar câmeras, varreduras de sensor e algoritmos para seguir um caminho designado debaixo d'água. Apesar de ser um robô de inspeção, é inútil para a inspeção estrutural, pois não tem a capacidade de subir em superfícies ferrosas.

Outro exemplo é o AETOS ² drone aéreo. O drone AETOS é um quadricóptero usado para levantamento topográfico, mapeamento paisagístico e resposta a emergências. O próprio robô é um quadricóptero pilotado remotamente que suspende uma câmera de alta potência. A câmera é capaz de capturar e gravar imagens e vídeos detalhados de estruturas e paisagens. O drone AETOS é versátil em seu uso e pode até inspecionar estruturas expostas, como pontes do ar. A desvantagem do drone é que ele não é ideal para inspeções estruturais detalhadas, porque o vento pode deslocar o drone enquanto ele está no meio de uma inspeção. O drone também não pode ser usado em estruturas fechadas, pois corre o risco de cair. O drone AETOS requer carregamento frequente e não pode permanecer no ar por longos períodos de tempo. Também é caro, sujeito a danos e difícil de recuperar em caso de acidente.

Alguns dos robôs disponíveis atualmente incluem sensores poderosos, várias câmeras e habilidades para escalar paredes. Esses robôs são extremamente caros e não podem ser implantados em grande número para realizar inspeções. Os riscos de danos associados a esses robôs e os custos de substituição também são muito altos. O dano é uma consideração muito real, porque praticamente todos os robôs empregados para inspecionar os reatores nucleares danificados no local de Fukushima Daiichi no Japão falharam em março de 2017. Um exemplo de um robô caro é a MagneBike ³ . A MagneBike é um robô relativamente novo que ainda não foi vendido comercialmente, mas está atualmente em teste e desenvolvimento privado. A MagneBike é uma bicicleta robótica que possui duas rodas conectadas a um corpo principal por uma articulação livre. Essa junta permite que o robô se mova livremente em qualquer superfície ferrosa, independentemente dos contornos. Cada roda também tem duas alavancas presas às laterais e se assemelha a rodinhas de apoio. O comprimento de cada alavanca é ligeiramente maior que o raio de cada roda. As alavancas são usadas para desvincular a roda da superfície magnética à qual está conectada, permitindo que ela se desloque suavemente em ângulos internos. A MagneBike pode ser configurada para suportar uma câmera de alta definição e um sensor de mapeamento 3D, que permite criar um modelo 3D de seus arredores. O robô é controlado e alimentado por um cabo e é um dispositivo com fio para fácil recuperação. A desvantagem da MagneBike, no entanto, é que ela é muito difícil de substituir se quebrada e muito cara se as peças usadas forem suficientes.

Um robô com rodas magnéticas semelhante é o robô magnético multissegmentado da Marinha dos EUA ⁴ (MSMR). O MSMR é um robô naval projetado para inspeção do casco de navios. Embora o MSMR não seja projetado para inspeção estrutural acima do solo, ele pode ser facilmente adaptado para inspecionar estruturas. Além disso, inspecionar o casco de um navio e inspecionar uma estrutura industrial não são tarefas diferentes. O MSMR é um robô de 3 segmentos, com cada segmento sendo uma caixa de metal contendo eletrônicos, com duas rodas presas em suas laterais. Os segmentos são conectados por conectores flexíveis ou articulados.

Cada roda pode funcionar de forma independente, e o robô é capaz de escalar obstáculos 3D facilmente quando todas as rodas trabalham juntas. As rodas são magnetizadas e podem suportar o robô. As desvantagens do robô são que ele não possui uma corda e, portanto, é alimentado apenas por uma bateria. Isso é desvantajoso, porque torna o robô significativamente mais difícil de controlar e limita a vida de inspeção do robô. O MSMR também não foi lançado e é usado apenas pela Marinha. O robô provavelmente permanecerá assim no futuro próximo.

Outro exemplo de robô de inspeção é o Microbot de Escalada de Parede Omnidirecional ⁵ . O Microbot é um minúsculo robô circular pesando apenas 7,2 gramas. Tem um diâmetro de 26 mm e uma altura de 16,4 mm. O bot está atualmente nos estágios finais de teste e ainda não está disponível comercialmente. O robô suporta 3 micromotores de rodas magnéticas com capacidade de giro de 360 ​​°. As rodas permitem que ele atravesse a maioria das superfícies ferrosas com facilidade. O Microbot pode ser configurado para suportar uma única microcâmera. A câmera pode enviar imagens e vídeos simples para o controlador. O robô também está amarrado. Ele é conectado ao seu controlador por fios de cobre que podem ser isolados para proteção. Embora o robô seja barato e possa ser usado em grupos, ele só pode suportar uma única câmera e a corda é fraca. Ele também não tem espaço para expansão e não pode suportar nenhum sensor.

Existem projetos de robôs que usam ventosas ou pressão negativa gerada por hélices para se prender às superfícies. As ventosas oferecem mobilidade limitada em comparação com as rodas magnéticas e não são adequadas para robôs pesados ​​equipados com várias câmeras e sensores. Além disso, o poder de sucção irá degradar com o tempo devido ao desgaste mecânico. O sistema de pressão negativa requer potência considerável e potência constante. Se houver perda de energia, o robô se desconectará da superfície. Cada um dos designs testados antes tem suas vantagens e desvantagens, mas nenhum resolveu o problema de inspeção completamente. A revisão da literatura permitiu-me fazer um levantamento da paisagem, aprender sobre o que foi tentado antes e criar meu próprio projeto.

1. Especificação de requisitos

O robô de inspeção teria que atender a várias restrições. A primeira restrição do robô seria o tamanho. Um robô de inspeção seria idealmente pequeno. Alguns dos espaços que o robô inspecionaria têm menos de trinta centímetros de largura e altura. O tamanho é limitado neste projeto a 25x25x25 cm. O tamanho menor aumenta a mobilidade e versatilidade do robô em ambientes complexos, como vigas de pontes. Uma vantagem do tamanho pequeno também é que o robô consumirá menos energia e será mais fácil de manipular. O robô também teria que ser amarrado. Um robô conectado seria capaz de enviar mais dados de forma mais rápida e confiável do que um robô sem fio.

O controlador do robô não teria que se preocupar com o robô saindo do alcance do sinal wireless, e também seria capaz de extrair facilmente o robô em caso de acidente ou falha. Além disso, um robô de inspeção teria que suportar várias câmeras para inspeção e navegação completas. A filmagem da câmera ao vivo do robô para o controlador seria necessária para que o robô fosse conduzido com precisão pela estrutura que está inspecionando e para alertar o controlador sobre perigos imediatos. Outra restrição que o robô precisa atender é que ele precisa ser capaz de escalar superfícies ferrosas. A maneira mais fácil de atender a essa restrição seria o robô ter rodas magnéticas ou um corpo magnético, permitindo ao robô escalar superfícies ferrosas com facilidade. Isso ocorre porque os materiais ferromagnéticos, como aço-carbono, aço de baixa liga e ferro, são materiais primários na construção de tais estruturas. Por último, o robô deve ser barato, de preferência com um custo abaixo de $ 200. Um robô barato é fácil de substituir e, ao inspecionar estruturas mais antigas, não seria surpreendente que um robô fosse danificado. Um robô barato também significa que mais robôs podem ser comprados e usados ​​para uma tarefa, o que pode aumentar muito a eficiência da inspeção.

4. Projeto e Desenvolvimento do Robô

4.1. Protótipo 1:LEGO EV3

Para projetar um robô que atenda às restrições declaradas acima, comecei a fazer um protótipo com um módulo de controle LEGO EV3 e outras peças LEGO. Eu originalmente comecei a trabalhar com LEGOs para prototipagem porque é fácil construir com LEGOs e criar um robô é bastante simples. O módulo EV3 é um núcleo de robô programável que controla o robô LEGO e já estava disponível em casa. Usando peças de Lego, foi bastante fácil criar um corpo robusto de robô com 4 motores e rodas acoplados. Quando comecei com o EV3, tentei fazer um design plano e compacto para meu robô. Por causa da maneira como as peças de LEGO se encaixam, essa ideia começou a falhar quando chegou a hora de anexar meu terceiro ^º e 4 ^th motor. Não consegui encaixar meus motores em meu módulo de controle. Em seguida, mudei para um design angular, com o módulo suspenso acima do resto do meu robô e os motores arqueando em uma estrutura principal. Depois de projetar a estrutura de suporte principal, que se encaixou confortavelmente sob o controlador, fui capaz de projetar os suportes do motor. Os suportes eram braços inclinados para baixo que se projetavam da estrutura principal e se prendiam aos motores. Os motores foram totalmente fixados nas extremidades dos suportes para evitar falha estrutural durante o teste. Para estabilizar ainda mais os motores e seus suportes, liguei cada motor ao motor mais próximo com conectores rígidos. O conector também evitou que um motor fosse muito mais rápido do que os outros, porque servia para ligar os motores e criar uma estrutura secundária.

Depois de terminar o projeto estrutural e construção do robô LEGO, mudei para o projeto das rodas. Para as rodas, comecei com 4 rodas EV3 de tamanho padrão. Cada roda tinha um raio de 17 mm e uma largura de 17 mm. Cada roda vinha adicionalmente com um pneu oco de borracha acoplado. Para configurar as rodas para movimento magnético, comecei removendo os pneus. Depois de remover os pneus, apenas a roda de plástico nua foi deixada. O plástico tinha entalhes profundos como uma fada, que cobriam consistentemente a maior parte da roda. Por causa das reentrâncias, não fui capaz de prender ímãs diretamente nas rodas. Os ímãs que usei para o robô LEGO eram discos D51-N52 da K&J Magnetics ⁶ . Os ímãs D51-N52 são ímãs de disco de neodímio-ferro-boro (NdFeB) que têm um diâmetro de 5/16 "(8 mm) e uma espessura de 1/16"

(1,6 mm). Escolhi usar esses ímãs porque eram pequenos o suficiente para que eu pudesse enrolá-los em uma corrente ao redor da roda e criar uma faixa magnética. Cada D51-N52 tem uma força de tração de 2,05 lb (9,1 Newton) quando preso diretamente a uma placa de aço. Com quatro rodas envolvidas nos ímãs, o magnetismo seria mais do que suficiente para segurar o robô LEGO, que é mostrado na Figura 1.

Testei métodos de anexar ímãs às rodas do meu robô. Eu originalmente tentei embrulhar um papel ao redor da roda e super-cola de ímãs naquele papel. Essa ideia não funcionou porque o papel era muito fraco para fornecer uma superfície firme para os ímãs e não era

forte o suficiente para evitar que os ímãs se aglomerem e saiam da roda. Em seguida, tentei preencher os buracos nas rodas com argila ou playdoh e colocar ímãs sobre eles. Essa ideia também falhou porque nenhum dos materiais grudaria na supercola. Depois que nenhuma das ideias funcionou, fiz experiências para ver se um híbrido das duas ideias funcionaria. Preenchi as reentrâncias da roda com tiras de papel dobradas e comprimidas. Em seguida, colei as tiras no lugar.

Depois, embrulhei um papel que foi dobrado e reforçado por finos fios de metal em volta da roda. O papel reforçado era uma superfície resistente, mas flexível o suficiente para que eu pudesse colar os ímãs. Depois de prender ímãs com sucesso em todas as quatro rodas, envolvi cada uma delas com fita adesiva em vez de usar um pneu. A razão pela qual optei por não usar um pneu foi que um pneu reduziria muito a força de tração dos imãs devido à sua espessura, enquanto a fita adesiva não reduziria significativamente a força de tração enquanto ainda oferecia tração. Depois de embrulhar as rodas, passei um eixo LEGO por cada roda e usei para prender cada uma aos meus motores.

A fixação das rodas marcou o fim do desenvolvimento do meu primeiro protótipo. Testei o protótipo pressionando-o contra uma porta de aço. O robô foi capaz de se agarrar firmemente à porta sem escorregar. O robô não atendeu a várias restrições de projeto:era maior que 25x25x25 cm, custava mais de US $ 200, não era conectado, exigia baterias e não era compatível com câmeras.

No entanto, este protótipo inicial atendeu a um objetivo principal. O verdadeiro objetivo do meu primeiro protótipo era me ajudar a entender como prender um robô a uma superfície ferrosa de forma eficiente com ímãs, e me ajudar a entender como projetar um robô e rodas para resolver o problema de inspeção.

4.2 Seleção de materiais e componentes para o segundo protótipo

Depois de construir meu primeiro protótipo de robô com LEGOs, decidi selecionar componentes e projetar e visualizar meu próximo protótipo no computador antes de começar a construção. Primeiro, decidi que usaria um Raspberry Pi como o núcleo de meus futuros protótipos. A razão pela qual escolhi a Raspberry Pi foi que a Pi é uma placa de circuito bastante poderosa, apesar de ser muito leve e compacta. O Pi pode se conectar a placas de controle de motor, embora ainda tenha recursos de USB e Ethernet. Além disso, o Pi é um computador muito barato e vem com um pacote de sistema operacional gratuito. A Figura 2 é uma fotografia do Raspberry Pi 3.

Em seguida, decidi usar a placa de controle do motor L298N para controlar meus motores. O L298N é um controlador de motor bastante simples que pode controlar até 2 motores CC. O controlador do motor está documentado como sendo capaz de lidar com tensões de até 35 V. Como a maioria dos motores que eu queria usar estava na faixa de 6 V-12 V, o L298N era ideal para mim. A placa em si é bem pequena, tendo apenas um terço do tamanho de uma Raspberry Pi. Devido a esta simplicidade, é fácil comprar vários L298Ns por um custo baixo. Também decidi que começaria com uma única câmera para meu primeiro protótipo com o Raspberry Pi. A câmera que escolhi usar é a câmera Raspberry Pi NoIR.

Esta câmera NoIR é uma câmera compatível com Pi projetada para visão noturna. Embora estruturas como pontes possam ser iluminadas, o interior dos tanques provavelmente estará escuro; então escolhi a câmera Pi NoIR em vez da câmera Pi padrão. Também escolhi a câmera NoIR porque ela foi construída para o Raspberry Pi e seria mais fácil de usar do que qualquer outra câmera.

Para meus motores, escolhi motores Arduino de plástico de 6 V DC padrão. Eu escolhi esses motores, embora fossem motores Arduino, porque eu sabia que minha placa de driver poderia operar qualquer motor CC dentro de seu limite de tensão. Fiz um cálculo de mecânica de engenharia, conforme discutido abaixo, para estimar o torque do motor necessário. Os motores de plástico são muito fáceis de usar e cabear, além de serem baratos. Se um dos motores quebrasse, seria fácil substituí-lo por um novo motor. Os motores também vêm com rodas de plástico grandes o suficiente para suportar e mover o robô, mas pequenas o suficiente para serem facilmente controladas. Além de meus dois motores de acionamento, eu queria usar outro motor para criar um mecanismo de alavanca sob o robô que pudesse sustentá-lo. O mecanismo seria usado para levantar a extremidade frontal do robô do chão para que ele pudesse se conectar a uma superfície ferrosa melhor. Eu planejava montar o robô em um chassi de robô de plástico simples e usar tiras de metal para formar uma plataforma elevada para qualquer peça que não pudesse ser acomodada no próprio chassi. Decidi alimentar o L298Ns com uma bateria 4-AA ou duas baterias 2-AA. O Raspberry Pi foi projetado para receber energia de um cabo USB que se estendia até uma tomada elétrica. O robô seria controlado por um controlador do Xbox 360 com fio conectado a ele por meio de um cabo USB. Decidi usar um Xbox Controller porque ele tem um direcional, o que seria ideal para controlar o movimento do robô. Ele também possui botões extras que podem ser atribuídos a diferentes tarefas dentro do código do robô, como controles de câmera. Para os ímãs, decidi continuar usando os ímãs D51-N52 porque provei que usá-los para criar uma banda magnética ao redor de uma roda era um método viável de criar uma roda magnética com meu primeiro protótipo.

4.3 Projeto Auxiliado por Computador (CAD) do Segundo Protótipo

Depois de decidir sobre os materiais e componentes que usaria para fazer meu 2 ^nd protótipo, passei a construir um desenho CAD do meu protótipo, para que eu pudesse construí-lo com facilidade assim que as peças que eu especificasse chegassem. Para fazer os desenhos CAD, usei um software chamado SketchUp, porque o software era gratuito, fácil de aprender por conta própria e fácil de usar. Usando medições físicas e online (uma vez que as peças chegaram) das peças que planejei usar para fazer meu 2 ^nd Robô protótipo, fui capaz de construir um desenho CAD 3D realista do meu protótipo de robô, conforme mostrado na Figura 3. Em seguida, refinei ainda mais meu protótipo levando em consideração as localizações ideais dos parafusos. Depois de algumas iterações para adicionar recursos de design e refinar os detalhes, consegui um modelo 3D satisfatório do meu robô. Isso serviu para simplificar a parte de hardware do meu projeto, já que eu apenas tive que construir uma cópia física do modelo do computador usando peças reais.

4.4 Protótipo 2a:Chassi Pré-Fabricado

Construindo Protótipo 2a

Depois que todas as minhas peças chegaram e meus desenhos CAD foram concluídos, construir meu robô foi uma tarefa simples. Ao construir o robô, comecei fazendo orifícios para montar o Raspberry Pi. Para traçar os pontos que eu perfuraria no chassi de plástico, segurei o Pi na parte superior da extremidade traseira do chassi e usei um lápis fino para marcar a área sob cada orifício de parafuso no chassi. Em seguida, selecionei uma broca ligeiramente maior do que os orifícios dos parafusos no Pi para fazer cada orifício. Em seguida, fiz orifícios semelhantes na frente do chassi para acomodar a placa do driver. Para montar a placa do driver e o Raspberry Pi, usei parafusos e porcas # 4-40. Depois de montar as duas placas, usei os parafusos fornecidos para prender a roda traseira e

motores para pré-cortar orifícios no chassi. O chassi, motores e roda traseira vieram juntos com porcas, parafusos e instruções, portanto, conectar os dois componentes ao chassi foi fácil.

Para este protótipo, usei fita dupla-face resistente para prender um terceiro motor na parte inferior do robô, diretamente entre os dois motores de acionamento. Em seguida, peguei quatro palitos de picolé e colei-os longitudinalmente em conjuntos de dois. Como resultado, obtive dois palitos de picolé muito grossos. Em seguida, cortei os palitos de picolé ao meio e esbocei a extremidade do eixo do motor na extremidade de cada meio palito de picolé. Em seguida, usei uma furadeira para fazer um orifício em cada uma das novas hastes que acomodariam o eixo do motor. Como resultado, obtive 4 palitos de picolé furados com metade do comprimento e grossos. Em seguida, escolhi os dois manípulos que se encaixam melhor e os fixei em cada extremidade do eixo do motor do meio. Prendi os palitos de picolé com cola quente. O propósito dessa engenhoca motorizada era servir como um elevador que empurraria o robô para fora da superfície em que estava, uma vez que o motor fosse ativado. Este dispositivo foi projetado para permitir que o robô se desprenda de uma superfície ferrosa. Também permitiria ao robô elevar suas rodas magnéticas principais do solo para que pudesse se prender a uma parede de ferro de outra superfície. Este é um dos vários recursos de design exclusivos deste projeto. O design da roda magnética é outro recurso inovador.

Depois de prender o terceiro motor, usei fita adesiva de metal perfurada para criar estruturas em forma de ponte acima da placa do driver e do Raspberry Pi. A fita suspensa serviu como uma superfície secundária na qual peças adicionais poderiam ser montadas. Por causa das perfurações, foi fácil fazer orifícios no chassi para encaixar a fita de suporte de metal e prendê-lo com os parafusos e porcas restantes. No topo da ponte de fita suspensa na frente do robô, coloquei uma segunda placa de driver para controlar o terceiro motor, pois cada placa pode controlar apenas dois motores. Consegui prender a placa do driver usando fita dupla-face. Com mais fita dupla-face, consegui prender um suporte de bateria 4-AA na parte superior do hangar de metal traseiro para alimentar a placa do driver principal. Também coloquei dois suportes de bateria 2-AA na frente do meu robô para alimentar a segunda placa do driver.

Terminei este segundo protótipo colando a quente a câmera Raspberry Pi NoIR na frente da ponte de fita de suporte de metal. Depois de construir o robô, só faltou magnetizar as rodas. Tirei os pneus das rodas e coloquei uma camada de fita dupla-face sobre cada roda. As rodas e motores de plástico são mostrados na Figura 4. Fixei os pequenos ímãs circulares D51-N52 em um círculo ao redor do aro de cada roda, de forma que houvesse dois anéis em cada roda. Depois de adicionar todos os ímãs, cobri as duas rodas com uma única camada de fita adesiva para protegê-los. Para magnetizar a roda traseira, colei ímãs com cola quente em um anel ao redor da roda e os envolvi com fita adesiva. A razão pela qual a fita adesiva foi usada foi porque ela é fina o suficiente para não reduzir a força de tração significativamente, mas é forte o suficiente para proteger os ímãs.

Protótipo de fiação 2a

Depois de conectar todos os componentes do meu robô, comecei a conectá-los. A alimentação do Raspberry Pi veio por meio da porta micro USB na lateral. Em seguida, conectei as baterias às respectivas placas de driver. The motors were also connected to the driver boards using wires that came with the motors. I soldered the wires to the power leads on the motor and connected them with screws to the driver board. I then wired the GPIO pins on the Pi to the driver boards. The GPIO pins are general purpose input/output pins on the Raspberry Pi. Some pins are used for ground and power, while some can be used to send signals through a wire. I wired GPIO 2 &6 to one driver board and 4 &9 to the other driver board. Those pins were 5 V pins and were used to enable motor movement and control through the driver boards. I then wired pin 11, 12, 13, &15 to the first driver board, and wired pins 16, &18 to the other driver board. Those pins were used for sending the actual motor control signal. Each motor

required two pins for control, and since the robot used 3 motors the driver boards required 6 connected signal GPIO pins for motor control, in addition to a 5V and ground per board. After I connected the necessary GPIO pins, I connected an Ethernet cable between my Pi and my laptop, so that my laptop would be able to have a remote desktop connection with my Raspberry Pi, eliminating the need for a monitor, keyboard, and mouse. I also connected a powered hub via USB to my Pi. The hub was connected to an Xbox controller, so that I would be able to control the robot through the Xbox controller.

Programming Prototype 2a

The hardest part about designing my 2 ^nd prototype was the code. With my first prototype, it was merely a hardware model; it ran no code. My reason being, with my 1 ^st prototype, try as I might, I was unable to get all 4 motors to move simultaneously with code. The first prototype was also created mainly to test the magnetic wheel concept and to help me come up with an ideal design for future prototypes. On the Raspberry Pi, I coded with Python, because it was the only language for the Raspberry Pi that I understood. But even before I started on my code, I had to set up my robot to be remote desktop compatible with my laptop.

To set up my Pi, I had to temporarily attach a monitor, keyboard, and mouse to the Raspberry Pi. Afterwards, I booted up the Pi and set a static IP for it over Ethernet. I chose 192.168.1.10 because it was a simple and easy address. To set the IP I had to edit

/ect/dhcpcd.conf in my Pi. The dhpcd.conf file controls the IP and network connection of the Pi; to set a static IP I had to add the lines to the beginning of the file:

interface eth0

static ip_address=192.168.1.10 static routers=192.168.1.1

After setting the static IP of the Pi, I installed the Linux package tightvncserver. Tightvncserver is a package that allows for a VNC (virtual network connection) server to be set up on the Raspberry Pi. Remote Desktop connections are run through VNC servers. After setting up the VNC server, I was able to create a Remote Desktop connection to my Raspberry Pi through my

laptop. After confirming that I could access my Pi, I disconnected my monitor, keyboard, and mouse. I then began the coding for the robot.

First, I needed a way to find out which GPIO pin corresponded to what motor on my Pi. Each GPIO pin when activated, rotates a single motor either forward or backward at a constant speed. Thus, each motor has two corresponding GPIO pins, a forward motion controller, and a backward motion controller. To find out what each GPIO pin corresponded to, I wrote a program that individually tested each GPIO pin, so that I would be able to note down which GPIO pin did what. I recorded my observations through comments on my program:

import RPi.GPIO as GPIO from time import sleep

GPIO.setmode(GPIO.BOARD)

GPIO.setup(12,GPIO.OUT) #Left Backward GPIO.setup(11,GPIO.OUT) #Left Forward GPIO.setup(13,GPIO.OUT) #Right Forward GPIO.setup(15,GPIO.OUT) #Right Backward GPIO.setup(16,GPIO.OUT) #Lifter Out GPIO.setup(18,GPIO.OUT) #Lifter In

GPIO.output(12,GPIO.HIGH)

sleep(2) GPIO.output(12,GPIO.LOW)

sleep(1)

GPIO.output(11,GPIO.HIGH)

sleep(2) GPIO.output(11,GPIO.LOW)

sleep(1)

GPIO.output(13,GPIO.HIGH)

sleep(2) GPIO.output(13,GPIO.LOW)

sleep(1)

GPIO.output(15,GPIO.HIGH)

sleep(2) GPIO.output(15,GPIO.LOW)

sleep(1)

GPIO.output(16,GPIO.HIGH)

sleep(0.5) GPIO.output(16,GPIO.LOW)

sleep(1)

GPIO.output(18,GPIO.HIGH)

sleep(0.5) GPIO.output(18,GPIO.LOW)

sleep(1)

Next, I needed software or code that would enable my Raspberry Pi to receive and understand signals sent to it by the Xbox controller. Xboxdrv is an Xbox controller driver for Linux. I installed it and used it to try to connect my Pi to my Xbox controller. Normally running the command ‘sudo xboxdrv’ in the prompt will display the inputs of connected Xbox controller in the command prompt window. My Xbox controller however, was not made by Microsoft, so it was not supported normally by xboxdrv I fixed the problem by running the command:

sudo xboxdrv –device-by-id 1bad:f02e –type xbox360 –detach-kernel-driver –mimic-xpad

I was able to create this command after researching how to use xboxdrv and how to modify the normal function with code. With this command, I identified the connected controller as an Xbox controller using its device id which was 1bad:f02e. This command allowed me to view the inputs from the controller in the command prompt. I needed a way to access the input values from a

Python program, so that I would be able to use the values to control my robot. After some searching online, I found a Python program that received and displayed Xbox controller input values on Github ⁷ . The code was by martinohanlon. I downloaded the code onto my Raspberry Pi and started working on modifying it to control the motors on the robot based on the values it received. The problem I faced was that the code was so long and complex, that I was unable to tell where the input value from the Xbox controller was read. To solve that problem, I went through the program and I made a series of print statements that printed the variables of the program as it ran. Through the process of observing the values as buttons were pressed, and deleting print statements, I was able to find the main event system in the program at line 265:

#run until the controller is stopped while(self.running):

#react to the pygame events that come from the xbox controller for event in pygame.event.get():

#thumb sticks, trigger buttons

if event.type ==JOYAXISMOTION:#is this axis on our xbox controller

if event.axis in self.AXISCONTROLMAP:#is this a y axis

yAxis =True if (event.axis ==self.PyGameAxis.LTHUMBY or event.axis ==self.PyGameAxis.RTHUMBY) else False

#update the control value self.updateControlValue(self.AXISCONTROLMAP[event.axis],

self._sortOutAxisValue(event.value, yAxis)) #is this axis a trigger

if event.axis in self.TRIGGERCONTROLMAP:#update the control value

self.updateControlValue(self.TRIGGERCONTROLMAP[event.axis], self._sortOutTriggerValue(event.value))

#d pad

elif event.type ==JOYHATMOTION:#update control value

self.updateControlValue(self.XboxControls.DPAD, event.value)

#button pressed and unpressed

elif event.type ==JOYBUTTONUP or event.type ==JOYBUTTONDOWN:#is this button on our xbox controller

if event.button in self.BUTTONCONTROLMAP:#update control value

self.updateControlValue(self.BUTTONCONTROLMAP[event.button], self._sortOutButtonValue(event.type))

Within the main event system, I searched for the component that handled the directional pad (d- pad) on the Xbox controller, as I was planning on using it to control the motors on the robot.

After finding the directional pad control component, I added some statements to the end that sent signals through the GPIO pins to the motors whenever a certain direction was pressed on the D- Pad:

#d pad

elif event.type ==JOYHATMOTION:#update control value

self.updateControlValue(self.XboxControls.DPAD, event.value) if event.value ==(0,1):#Forward

GPIO.output(11,GPIO.HIGH) #Left Forward GPIO.output(13,GPIO.HIGH) #Right Forward

elif event.value ==(0,-1):#Backward GPIO.output(12,GPIO.HIGH) #Left Backward GPIO.output(15,GPIO.HIGH) #Right Backward

elif event.value ==(1,0):#Right GPIO.output(11,GPIO.HIGH) #Left Forward

GPIO.output(15,GPIO.HIGH) #Right Backward elif event.value ==(0,1):#Left

GPIO.output(12,GPIO.HIGH) #Left Backward GPIO.output(13,GPIO.HIGH) #Right Forward

GPIO.output(12,GPIO.LOW) GPIO.output(11,GPIO.LOW) GPIO.output(13,GPIO.LOW) GPIO.output(15,GPIO.LOW)

After successfully configuring the motors, my next challenge was to code the Raspberry NoIR camera. The Pi camera came with a Python camera package. Coding it so that pictures were taken or videos were recorded every time certain buttons on the Xbox controller were pressed was fairly easy.

#button pressed and unpressed

elif event.type ==JOYBUTTONUP or event.type ==JOYBUTTONDOWN:#is this button on our xbox controller

if event.button in self.BUTTONCONTROLMAP:#update control value

self.updateControlValue(self.BUTTONCONTROLMAP[event.button], self._sortOutButtonValue(event.type))

if event.button ==0 and event.type ==10:camera.capture(‘image’ + imgNum + ‘.jpg’) imgNum =imgNum + 1

if event.button ==1 and event.type ==10:if isRec ==False:

camera.start_recording(‘video’ + recNum + ‘.h264’) isRec =True

else:

camera.stop_recording() isRec =False

if event.button ==1 and event.type ==10:if isPrev ==False:

camera.start_preview() isPrev ==True

else:

camera.stop_preview() isPrev ==False

For this portion of the code, I did have to make variables to serve as counters every time a picture or video was taken, so that they would be numbered. I also had to make Boolean variables that determined whether a video was being taken, to prevent the robot from trying to take another video while one was already recording. After coding the camera, I was finished with programming the robot.

Testing Prototype 2a

The first thing I recorded was the mass of the robot. Using a standard kitchen scale, I recorded the mass of the robot to be 0.66 kg. While not being especially light, prototype 2a was significantly lighter than prototype 1, which had a mass of 0.92 kg without cameras. Prototype 2a was also measured to be 15 cm long x 18 cm wide x 12 cm tall. Prototype 2a could meet the size constraint, which was another improvement over prototype 1. Prototype 2a could stick to ferrous surfaces. While the motor of prototype 1 could not overcome the magnetic pull force and move the robot, prototype 2 could move the robot downward or sideways but not upward when attached to a vertical steel wall. The 3 ^rd motor on the robot that was planned for lifting of off surfaces was also unable to function because of a lack of torque. Prototype 2a had only mounted 1 camera, and thus failed the multiple camera requirement. However, prototype 2a was an improvement over prototype 1. Prototype 2a only cost about $120 to build compared to prototype 1, which cost more than $400 even without cameras.

4.5   Engineering Mechanics Calculations

I calculated force and torque using equations from the literature as shown below.

Force and Torque Equations

Figure 5 shows a sketch of the robot climbing an inclined plane and the forces present.

For a robot at rest in the plane:	m*(N1 + N2) =Mgsinq	(1)
Perpendicular to the plane:	N1 + N2 =F(M1) + F(M2) + Mgcosq	(2)
For a vertical wall q =p/2.	N1 + N2 =F(M1) + F(M2); m*(N1 + N2) ≥ Mg	(3)
The required magnetic force is	F(M1) + F(M2) ≥ Mg/m	(4)

With two motors, the torque needed from each is t ≥ MgR/2                                              (5)

Force Calculation for Magnet Placement

The paper by Wang and Kimura (IEEE 2014) shows that the friction coefficient for tape covered wheel on metal m =0.45. The mass of my robot prototype 2a is M =0.655 kg. The acceleration of gravity g =9.81 m/s ² . From equation (4), the required magnetic force =14.5 Newton. The pull force of the N52 magnet away from a steel surface has been tested and reported by the manufacturer KJ Magnetics. It is shown for different distances in Figure 6. The thickness of the duct tape I used is 0.01”. At a distance of 0.01”, the pull force is 1.26 lb per magnet according to the data plotted in Figure 6. In SI units, this pull force per magnet =5.6 Newton. To get a magnetic force of at least 14.5 Newtons calculated from equation (4), we need at least 3 magnets in contact at all times (one per wheel). The m value of 0.45 is only an estimate. If it is lower (say 0.25), the required magnetic force is higher, about 26.1 Newton.

Thus, for safety, we need 2 rows of magnets per wheel.

Torque Calculation for Motor Selection

Torque is important, because it is the rotational force (force multiplied by radial distance) that the motor must generate to move the robot. From equation (6), we know that the torque must be greater than MgR/2 for each of the front wheel motors. For prototype 2a, this works to torque being more than 0.08 Newton meter per motor. The plastic encased motors I used in the prototype 2a (Figure 4) were rated by the manufacturer as 0.1 Newton meter each. In my tests, prototype #2a could stay attached to a vertical surface and climb down. However, it struggled to climb up the vertical wall. The torque was barely enough to fight gravity. The results of this test of prototype #2a show that the force and torque calculations were correct. The lesson I learned from building and testing prototype 2a is that the robot should be lighter or a motor with greater torque should be used. The use of CAD and mechanics calculations made the design and development process systematic and logical. Figure 7 shows the underside of prototype 2a. The three motors and the popsicle sticks can be clearly seen.

4.6     Prototype 2b:Pre-Made Chassis

After developing and testing Prototype 2a, I realized that there were multiple changes I could make to it to make it fit the constraints better, without constructing an entirely new bot. So instead of starting from scratch, I decided to make a series of modifications and upgrades to Prototype 2a, resulting in the creation of Prototype 2b.

Building Prototype 2b

The first change I made to prototype 2a was that I removed all the motors. The motors did not work as expected for climbing up a vertical wall because of lack of torque; so, all of them had to be replaced or removed. I replaced the drive motors with two new larger motors, and I simply removed the third motor without replacement. The new motors were Uxcell 12V high torque gearbox motors. They were chosen, because their torque rating was much higher than that of the motors they replaced, but these new motors were heavier. I fastened both motors to the underside of the robot, where the previous motors had been using strips of double sided tape for preliminary testing. The new motors had a mass almost 100 g more than that of the old motors and so adding both new motors added almost 200 g to the mass of the robot.

I removed the driver board that controlled the third motor, because there was no longer a third motor on the robot, so there was only a need for a single driver board. Next, I removed all of the battery packs on the robot. Battery packs add unnecessary mass to a robot, and only limit its inspection life. Additionally, using batteries increases chances of motor failure when the robot is in deployment, because batteries might run out of battery power in the middle of a run, resulting in the need for an emergency retrieval. I then moved the remaining driver board onto the metal hanger above the Raspberry Pi, where the 4-AA battery pack had been previously. This allowed me to remove the metal hanger at the front of the robot because it was not being used. I also removed two posts with magnetic disks at the rear of the robot that were included in Prototype 2a to increase the stability of the rear. I found out through testing that the posts were not needed.

At this stage, I encountered a major problem. My wheels were no longer compatible with my motors because the new motors had a different shaft compared to the old motors. I tried drilling and cutting the wheel wells to make the wheels fit the motors, but neither solution worked. After some research on what items fit a D shaped motor shaft, I found out that oven knobs often fit D shafts. After buying some oven knobs, I tested them to see if they attach to the motors. After finding out the oven knobs were compatible with the new motors, I sawed the top off the oven knobs, resulting in flat disks that fit onto the new motors. I then drilled out the wheel well on the wheels, after which I superglued the disks to the wheels. By supergluing the disks to the wheels, I made it so that they would be able to attach to the motor. After attaching the wheels and motors, I set up the cameras. I hot glued the Pi NoIR camera to the back of the robot and made it face backwards for my rear-view camera. I then took a wide-angle, fish-eye camera, and hot glued it to the front of my robot facing forwards for my main camera. I then double sided taped and hot glued an endoscopic inspection camera to the front rim of the chassis facing downwards. The use of oven knobs to connect wheels to the new motor shaft is an innovative solution developed in this project.

Wiring Prototype 2b

After modifying prototype 2a, there were many components to re-wire. I had to re-solder a wire to the power leads of the motors and connect it to the remaining driver board. I then removed all of the wires connected to GPIO 4, 9, 16, or 18, as they were no longer in use. I also decided to use a 12 V power cable to power the driver board instead of a battery pack. To do so, I cut the output end of the power cable off, so that all that remained was the adapter and a length of wire. I then separated the two strands of power wire, one being positive and the other being negative, and stripped the wires so that both wires were exposed at the end. After twisting and tightening the exposed wire, I connected the positive wire to the ground slot on the driver board, and the negative wire into the voltage slot on the driver board. I left the NoIR camera connected to the Pi, but I connected both the other cameras to my laptop so that my laptop directly received feeds directly from the cameras instead of getting them through the Pi, with the exception of the NoIR camera. To finish, I swapped the Xbox Controller with a Super Nintendo Entertainment System (SNES ) controller. An SNES controller is a much lighter and simpler controller than an Xbox controller and unlike the Xbox controller which requires a powered hub for power, an SNES controller can be powered by the Raspberry Pi. The two controllers are shown side by side for comparison in Figure 8.

Programming Prototype 2b

Since the Raspberry Pi had already been completely set up with the previous prototype, I was able to dive straight into programming. While no new code was needed to test the motors, since the previous motor test program worked, a new controller code became necessary because I changed the controller and was no longer using an Xbox controller. Because of the simpler nature of the SNES controller, there was no driver similar to xboxdrv for the SNES controller.

The Pi is capable of interpreting the input from the SNES controller by default. After doing some research and looking into how to interact with an SNES controller through Python, I wrote the following controller program from scratch:

import pygame

import RPi.GPIO as GPIO GPIO.setmode(GPIO.BOARD)

GPIO.setup(12,GPIO.OUT) #Left Backward GPIO.setup(11,GPIO.OUT) #Left Forward GPIO.setup(13,GPIO.OUT) #Right Forward GPIO.setup(15,GPIO.OUT) #Right Backward

global hadEvent global x

global y global a global b global up global down global left global right

hadEvent =False x =False

y =False a =False b =False up =False

down =False left =False right =False

pygame.init()

pygame.joystick.init()

j =pygame.joystick.Joystick(0) j.init()

def game_controller(events):global hadEvent

global x global y global a global b global up global down global left global right

for event in events:

if event.type ==pygame.JOYBUTTONDOWN:hadEvent =True

x =j.get_button(0) y =j.get_button(3) a =j.get_button(1) b =j.get_button(2)

if x ==1:x =True

print(“x”) elif y ==1:

y =True print(“y”)

elif a ==1:

a =True print(“a”)

elif b ==1:b =True print(“b”)

elif up ==1:up =True print(“up”)

elif event.type ==pygame.JOYBUTTONUP:hadEvent =False

x =j.get_button(0) y =j.get_button(3) a =j.get_button(1) b =j.get_button(2)

if x ==1:

x =False elif y ==1:y =False elif a ==1:a =False elif b ==1:b =False

elif up ==1:up =False

elif event.type ==pygame.JOYAXISMOTION:hadEvent =True

if event.axis ==1:

if event.value <=-1:

up =True print(“up”)

elif event.value>=1:down =True print(“down”)

else:

down =False up =False

elif event.axis ==0:

if event.value <=-1:left =True print(“left”)

elif event.value>=1:right =True print(“right”)

else:

right =False left =False

while True:game_controller(pygame.event.get())

if up ==True:#Forward GPIO.output(11,GPIO.HIGH) #Left Forward GPIO.output(13,GPIO.HIGH) #Right Forward

elif down ==True:#Backward GPIO.output(12,GPIO.HIGH) #Left Backward GPIO.output(15,GPIO.HIGH) #Right Backward

elif right ==True:#Right GPIO.output(11,GPIO.HIGH) #Left Forward GPIO.output(15,GPIO.HIGH) #Right Backward

elif left ==True:#Left GPIO.output(12,GPIO.HIGH) #Left Backward GPIO.output(13,GPIO.HIGH) #Right Forward

else:

GPIO.output(12,GPIO.LOW) GPIO.output(11,GPIO.LOW) GPIO.output(13,GPIO.LOW) GPIO.output(15,GPIO.LOW)

This code operates by importing Pygame, which is a Python package. Pygame is used for constructing videogames through Python. It adds several features, such as interpreting and translating input values from a video game controller. Because of the simplicity of an SNES controller, there were no extra steps needed. Towards the beginning of the program, I defined the GPIO pins to be used for motor control. I then listed variables I planned to use, and assigned the connected controller to pygame.joystick() and then j. I then created an event system where a value sent by the controller is defined as an event, for example, pressing a button or moving a joystick. I then specified the events I care about, such as movement on the directional pad (d- pad) or a button being pressed. I assigned a value of 1 to a variable if the event it is connected to occured. I also wrote additional code to convert the numeric value 1 to the Boolean True. At the end, there is an infinite loop that fetches the values of events that were triggered. If any of the d- pad values are triggered, the program sends signals to the motors through the GPIO pins. After running this code, the robot responded smoothly to the SNES controller. I did not need any other code for controlling this prototype.

Testing Prototype 2b

Once again, I started by recording the mass of the robot. Using a standard kitchen scale, I recorded the mass of the robot to be 0.71 kg. Prototype 2b ended up being heavier than prototype 2a, despite the removal of the battery packs, but this can be attributed to the motors which were heavier in prototype 2b. Prototype 2b was measured to be 15 cm long x 18 cm wide x 12 cm tall. Prototype 2a and 2b are the same size despite the changes between the two, the overall structure of the robot did not change. Prototype 2b was once again able to meet the size constraint. Prototype 2b had the ability to attach to ferrous surfaces and was the first prototype that could climb up on vertical ferrous surfaces. Figure 9 shows Prototype 2b climbing a vertical steel door. Prototype 2b mounted 3 cameras, and all of them sent back acceptable feeds, which was a large improvement over prototype 2a. Prototype 2b cost $170 to build compared to the $120 of prototype 2a. This increase can be attributed to the cost of cameras and the cost of better motors.

4.7     Prototype 3:Custom Polycarbonate Chassis

After building the last two prototypes, I wanted to apply the knowledge I had gained to create a new prototype that was smaller, more compact, and more efficient. To do this, I planned to design my own chassis, and refrain from using tapes and superglue to hold parts together.

Building Prototype 3

To start building my robot, I took a polycarbonate sheet and cut my chassis out of it. For my chassis, I chose a simple 6 cm wide x 11 cm long rectangle. I chose that size and shape because it was simple and based off of preliminary measurements I took, it was the smallest feasible size for mounting the parts I had chosen. After cutting out the chassis with a saw, I smoothed out the edges and corners with a file and sandpaper. I then set the Raspberry Pi on the rear end of the chassis and marked where all of the holes were, so that I would be able to drill them out. I then set the rear wheel on the underside of the chassis and marked holes for it. I also marked holes for the motors I chose at the front of the chassis. The motors I chose were Pololu 12 V gearbox motors with a gear ratio of 298:1. The motors also came with mounting brackets that attached to the motors and had holes for screws. I finally marked a large hole between the Pi and the motors for the inspection camera.

After drilling all of the holes, I screwed down all of the parts except for the Pi. Before I screwed down the Pi, I laid down a thin sheet (4 mm thick) of packing foam underneath where the Pi would be to absorb shock and prevent contact between the metal on the Pi and the bolts and nuts on the robot. I also attached a folded metal hanger tape with the same bolts as the Pi. The hanger tape formed a bridge over the Pi. I cut a smaller 4.5 cm wide x 5.5 cm long piece of polycarbonate to screw to the top of the metal hangar. I screwed a driver board to the top of the smaller polycarbonate. For the wide-angle camera, I folded and cut thin scrap metal to form a pouch for the camera with a hole for the lens. The pouch had sides that folded in and held the camera. The pouch also had a flat bottom that extended out to either side. I screwed the metal pouch down with two of the screws that also held the motors. I slid the inspection camera down into the hole that had been drilled for it. The Pi NoIR camera was held by a retaining block that was hot glued to the top of the Ethernet port on the Pi. For the wheels, I used 60 mm diameter x

8 mm thick Pololu plastic wheels. To magnetize the wheel, I covered it in a thin layer of double sided tape and put the magnets in a ring around it. I the covered the magnets with a single layer of duct-tape for protection and traction. After finishing the wheels, I attached a 3V LED light on either side of the wide-angle camera holder. I also used double sided tape to attach an ultrasonic sensor to the bottom of the robot.

The robot utilizes an HC-SR04 ultrasonic distance sensor. The HC-SR04 is a very common and popular hobby ultrasonic distance sensor. The sensor is also the least expensive and easiest to use of its type to demonstrate sensor integration. The HC-SR04 is designed mainly with compatibility and simplicity in mind, allowing it to be easily connected to a Raspberry Pi or Arduino.

The HC-SR04 functions by sending a sound wave, which bounces off the object at which the sensor points, and then receiving the sound wave. The time between the sending and the reception of the sound wave is recorded and output. The time can then be multiplied by the speed of sound and divided by 2 to identify the distance between the sensor and the surface it is pointed towards. The HC-SR04 has 4 pins for connection purposes. The pins are ground, voltage, trigger, and echo. The ground pin is to be connected to ground. The voltage pin is to be connected to a+5V source. The trigger pin will cause the sensor to produce a sound wave for as long as it is receiving +3V. The echo pin sends back +5V in a burst as long as the wait time for the sensor to receive the signal. The sensor has a range of 2 cm to 400 cm. On my robot, the HC-SR04 serves to demonstrate that an ultrasonic sensor can be mounted underneath the robot. A more expensive, advanced ultrasonic sensor can be mounted to measure the thickness of the metal surface and identify degradation.

Wiring Prototype 3

For the wiring of prototype 3, many elements stayed the same from prototype 2b but one changed. Because the Pololu wheels blocked the micro USB port on the Pi, I was unable to use it for power. After some research, I found that I could use the GPIO pins instead. I cut a USB to micro USB cable so that one portion was the USB end and a length of cable. Within the cable were two separate wires. I split and stripped those wired. I then soldered the exposed parts of the wires to the female end of a breadboard jumper. I covered my work with heat shrink tubing. I used a multimeter to tell which end was positive voltage and which end was negative. I connected the positive wire to GPIO 9, and the negative end to GPIO 14. Those two GPIO’s were 5 V &ground respectively. After connecting the USB end of the charging cable to a 5 V adapter, the Pi ran perfectly. Once again, wires were soldered to the leads of my motors, and connected back to my driver board. The driver board was connected to GPIO 11, 12, 13, &15 for control and GPIO 2 &6 for 5V and ground. The driver board was also connected to a 12 V power supply. The LED lights were wired and soldered in parallel. They were attached a 330Ω resistor, GPIO 16 &18 for power, and GPIO 9 for ground. The ultrasonic sensor which was added to this prototype was wired to GPIO 4, 29, 30, and 31. Pin 4 was used for voltage, 29 was for output, 31 was for input, and 30 was for ground. The NoIR camera was once again connected to the Pi, while the other cameras are connected to my laptop. The robot is still controlled by a USB SNES controller. The wiring diagram is shown in Figure 10.

Programming Prototype 3

To save myself the work of setting up and configuring the Pi, I moved the SD card from prototype 2b to prototype 3. Because the only new need of code for prototype 3 was for the ultrasonic sensor, I mainly just simplified and commented my SNES code, only adding a few extra lines, as shown below.

#Developed By Nikhil Devanathan 2017

#Program to control Raspberry Pi robot with wired USB SNES controller #Uses directional pad (d-pad) for motor movement

#Leaves button and triggers open for mapping

#Imports necessary packages into python

import pygame #Package that is used for game controller mapping import RPi.GPIO as GPIO #Allows control over binary pins on Pi from gpiozero import DistanceSensor

#Sets GPIO pins for motor control GPIO.setmode(GPIO.BCM)

GPIO.setup(18,GPIO.OUT) #Left Backward GPIO.setup(17,GPIO.OUT) #Left Forward GPIO.setup(27,GPIO.OUT) #Right Forward GPIO.setup(22,GPIO.OUT) #Right Backward GPIO.setup(23,GPIO.OUT) #Light1\

GPIO.setup(24,GPIO.OUT) #Light2/ Work together to power LED lights

#Conifgures ultrasonic sensor

ultrasonic =DistanceSensor(echo =6, trigger =5, threshold_distance =0.02)

#Creates variables for controller mapping

global hadEvent global x

global y global a global b global up global down global left global right

#Assigns Variables for controller mapping hadEvent =False

x =False y =False a =False b =False up =False

down =False left =False right =False

#Initializing pygame and controller pygame.init() pygame.joystick.init()

j =pygame.joystick.Joystick(0) j.init()

#Defining controller event system def game_controller(events):

#Defining variables for use in controller event system

global hadEvent global x

global y global a global b global up global down global left global right

#Searches for an event in the system for event in events:

#If a button is pressed

if event.type ==pygame.JOYBUTTONDOWN:#Set map values

hadEvent =True

x =j.get_button(0) y =j.get_button(3) a =j.get_button(1) b =j.get_button(2)

#If a button is released

elif event.type ==pygame.JOYBUTTONUP:#Set map values

hadEvent =False x =j.get_button(0) y =j.get_button(3) a =j.get_button(1) b =j.get_button(2)

#If there is axial montion on the directional pad

elif event.type ==pygame.JOYAXISMOTION:

#Set values for y axis hadEvent =True

if event.axis ==1:

if event.value <=-1:up =True

elif event.value>=1:down =True

else:

down =False up =False

#Set values for x axis elif event.axis ==0:

if event.value <=-1:left =True

elif event.value>=1:right =True

else:

right =False left =False

lightOn =False #Value to use with b button light control

#Infinite Loop while True:

#Get an event from the event system game_controller(pygame.event.get())

#Motor controls beased on directional pad values if up:#Forward

GPIO.output(17,GPIO.HIGH) #Left Forward GPIO.output(27,GPIO.HIGH) #Right Forward

elif down:#Backward GPIO.output(18,GPIO.HIGH) #Left Backward GPIO.output(22,GPIO.HIGH) #Right Backward

elif right:#Right

GPIO.output(17,GPIO.HIGH) #Left Forward GPIO.output(22,GPIO.HIGH) #Right Backward

elif left:#Left

GPIO.output(18,GPIO.HIGH) #Left Backward GPIO.output(27,GPIO.HIGH) #Right Forward

else:

GPIO.output(18,GPIO.LOW) #Reset GPIO.output(17,GPIO.LOW) GPIO.output(27,GPIO.LOW) GPIO.output(22,GPIO.LOW)

if a:#If a is pressed, for holding light on GPIO.output(23,GPIO.HIGH) #Light1 GPIO.output(24,GPIO.HIGH) #Light2

else:#If a is released, for turning light off GPIO.output(23,GPIO.LOW) #Light1 GPIO.output(24,GPIO.LOW) #Light2

if b:#If b is pressed, for holding solid light if lightOn:#If the light is on

GPIO.output(23,GPIO.LOW) #Light1 GPIO.output(24,GPIO.LOW) #Light2 lightOn =False #Declare that the light is off

else:#If the light is off GPIO.output(23,GPIO.HIGH) #Light1

GPIO.output(24,GPIO.HIGH) #Light2 lightOn =True #Declare that the light is on

if y:#If Y button is pressed

#Scan distance to ground with ultrasonic sensor u =ultrasonic.distance

print u

The only changes made to this program were the addition of comments throughout the program, and the deletion of unnecessary code segments.

Testing Prototype 3

Using a standard kitchen scale, I recorded the mass of the robot to be 0.26 kg. The mass of prototype 3 was significantly reduced compared to every other model. Prototype 3 was measured to be 14 cm long x 9 cm wide x 12 cm tall. Prototype 3 was the smallest of the prototypes and was more than a factor of two smaller than prototypes 2a &2b. Prototype 3 had the ability to attach to ferrous surfaces and was able to move on ferrous surfaces of speeds of

0.18 meters/second, making it the fastest prototype. Prototype 3 mounted 3 cameras, and all of them sent back acceptable feeds. Prototype 3 cost $175 to build compared to the $120 of prototype 2a and the $175 of prototype 2b. This can be attributed to the cost of cameras and the cost of smaller motors. Sample images from the three cameras are shown in Figure 11 and the results of robot testing are shown in Tables 1 and 2. The final prototype can be seen in Figure 12.

Source:Design and Development of a Low-Cost Inspection Robot