Дизайн и разработка недорогого инспекционного робота

1. Введение

Инфраструктура нашей страны стареет и быстро разрушается. В настоящее время нет механизма для тщательной проверки состояния наших мостов, резервуаров для отходов, трубопроводов и реакторов. Срок службы многих из этих конструкций подошел к концу, и их необходимо проверить на предмет износа. Как и в этой ситуации на суше, также необходимо проверять корпуса и палубы кораблей и нефтяных танкеров ВМС США на наличие признаков коррозии. Многие старые конструкции, такие как высокие мосты и резервуары для отходов, часто трудно исследовать или осмотреть по множеству причин. Чаще всего причина в том, что процесс проверки опасен для человека или в конструкции есть недоступные участки. Другая распространенная причина заключается в том, что современная технология датчиков может быть неадекватной для точного обследования таких структур. Таким образом, ручная проверка является нечастой, трудоемкой, дорогостоящей, опасной и подверженной ошибкам. Эта проблема предлагает прекрасную возможность для хорошо сделанного робота-инспектора.

Инспекционные роботы обычно проектируются и разрабатываются большими хорошо финансируемыми группами инженеров-электриков и инженеров-механиков. Коммерческие роботы, такие как Packbot 510 (http://endeavorrobotics.com/products), могут стоить более 100 000 долларов. С учетом ограничений, установленных для отдельного проекта научной ярмарки, можно спроектировать, разработать и испытать недорогой прототип инспекционного робота. Целью этого проекта является разработка небольшого, легкого и недорогого прототипа инспекционного робота, который может оставаться прикрепленным к проверяемым поверхностям. Проект состоит из следующих задач:обзор литературы и существующих проектов; спецификация требований; конструкция робота; разработка начального прототипа и тестирование; расчеты инженерной механики; программирование робота с использованием Python; разработка и тестирование второго прототипа; и разработка и тестирование финального прототипа.

Перед физическим построением робота для визуализации робота и уточнения конструкции использовалось программное обеспечение для 3D-моделирования SketchUp. Робот был построен из готовых коммерческих компонентов, включая модуль Raspberry Pi 3 для управления роботом. Дизайн был многократно улучшен путем многократного тестирования. Код Python был написан с нуля для программирования робота. По мере развития проекта аппаратное и программное обеспечение необходимо было модифицировать одновременно. Прототип был продемонстрирован техническим экспертам из Вашингтонской лаборатории по защите реки и Тихоокеанской северо-западной национальной лаборатории, а также старшим специалистам по проектированию в штате Вашингтон

Университет, Три города. На основании отзывов экспертов, расчетов инженерной механики и результатов испытаний был построен и запрограммирован третий прототип. Получившийся робот может лазить по стенам с разумной скоростью и имеет несколько камер, помогающих с навигацией и осмотром. Робот, созданный в рамках этого проекта, представляет собой уникальную конструкцию с программным обеспечением, написанным специально для этой цели. Этот прототип служит гибкой платформой, позволяющей добавлять новые датчики по мере необходимости для расширения возможностей проверки.

2. Обзор литературы

Перед тем, как начать работу над проектом, я провел обзор литературы, чтобы оценить существующие решения. Доступные в настоящее время зонды можно разделить на два типа - стационарные и мобильные.

Стационарные зонды - наиболее широко используемый инструмент для обследования конструкций. Они предоставляют очень подробную информацию о конкретном участке конструкции и могут постоянно отслеживать его. Однако, как только они будут размещены в определенном месте, диапазон наблюдения будет ограничен. Из-за отсутствия мобильности они не подходят для наблюдения за большими сооружениями. Другая категория - это зонды, устанавливаемые на роботах. Они предлагают большую функциональность, поскольку зонд можно свободно перемещать. Большинство роботов, представленных в настоящее время на рынке, очень специализированы для выполнения конкретной задачи или вида проверки. Некоторые роботы могут специализироваться на перемещении по воде, большой высоте или болотистой полутвердой местности, но ни один из этих роботов бесполезен для проверки конструкции.

Робот для водной инспекции AQUA ¹ отличный пример. AQUA - высокоспециализированный и дорогой робот-инспектор. Он ползает по дну водоемов и делает трехмерное (3D) сканирование своей территории. Он может использовать камеры, сканирование датчиков и алгоритмы, чтобы следовать по заданному пути под водой. Несмотря на то, что это инспекционный робот, он бесполезен для проверки конструкций, так как у него нет возможности лазать по черным поверхностям.

Другой пример - AETOS ² воздушный дрон. Дрон AETOS - это квадрокоптер, который используется для съемки, картографирования ландшафта и реагирования на чрезвычайные ситуации. Сам робот представляет собой дистанционно управляемый квадрокоптер, на котором установлена ​​мощная камера. Камера способна снимать и записывать подробные изображения и видео структур и ландшафтов. Дрон AETOS универсален в использовании и может даже осматривать открытые конструкции, такие как мосты, с воздуха. Недостатком дрона является то, что он не идеален для детального обследования конструкции, потому что ветер может сместить дрон, пока он находится в процессе осмотра. Дрон также нельзя использовать в закрытых конструкциях, так как он может разбиться. Дрон AETOS требует частой зарядки и не может находиться в воздухе длительное время. Кроме того, он дорог, подвержен повреждениям и его трудно восстановить после сбоя.

Некоторые из доступных в настоящее время роботов оснащены мощными датчиками, несколькими камерами и способностями лазать по стенам. Такие роботы чрезвычайно дороги и не могут быть развернуты в больших количествах для проведения проверок. Риски повреждения, связанные с этими роботами, и затраты на замену также очень высоки. Повреждения - это вполне реальная проблема, потому что практически каждый робот, задействованный для осмотра поврежденных ядерных реакторов на площадке Фукусима-дайити в Японии, вышел из строя по состоянию на март 2017 года. Примером дорогостоящего робота является MagneBike ³ . MagneBike - это довольно новый робот, который еще не продается в коммерческих целях, но в настоящее время проходит тестирование и частную разработку. MagneBike - это роботизированный велосипед, в котором два колеса соединены с основным корпусом свободным шарниром. Этот шарнир позволяет роботу свободно перемещаться по любой железной поверхности независимо от контуров. Каждое колесо также имеет два рычага, прикрепленных к его сторонам, и напоминает тренировочные колеса. Длина каждого рычага немного больше радиуса каждого колеса. Рычаги используются для отсоединения колеса от магнитной поверхности, с которой оно соединено, что позволяет ему плавно перемещаться по внутренним углам. MagneBike может быть настроен для поддержки камеры высокой четкости и поддерживает датчик 3D-карт, что позволяет создавать 3D-модель своего окружения. Робот управляется и приводится в действие через кабель и представляет собой привязанное устройство для легкого извлечения. Однако недостатком MagneBike является то, что его очень трудно заменить, если он сломан, и довольно дорого, если используемые детали не пригодятся.

Аналогичным роботом на магнитных колесах является многосегментный магнитный робот ВМС США ⁴ . (МСМР). MSMR - это военно-морской робот, предназначенный для осмотра корпуса судов. Хотя MSMR не предназначен для наземной проверки конструкций, его можно легко адаптировать для проверки конструкций. Кроме того, осмотр корпуса судна и осмотр промышленного объекта - это не разные задачи. MSMR представляет собой 3-сегментный робот, каждый из которых представляет собой металлический ящик, содержащий электронику, с двумя колесами, прикрепленными к его бокам. Сегменты соединяются гибкими или сочлененными соединителями.

Каждое колесо может работать независимо, и робот может легко масштабировать трехмерные препятствия, когда все колеса работают вместе. Колеса намагничены и могут поддерживать робота. Недостатки робота в том, что он не имеет привязи и поэтому питается только от аккумулятора. Это невыгодно, потому что это значительно затрудняет управление роботом и ограничивает срок его службы. MSMR в настоящее время также не выпускается и используется только ВМФ. Робот, вероятно, останется таким в обозримом будущем.

Другой пример инспекционного робота - всенаправленный микробот для лазания по стенам ⁵ . Microbot - это миниатюрный круглый робот весом всего 7,2 грамма. Он имеет диаметр 26 мм и высоту 16,4 мм. В настоящее время бот находится на завершающей стадии тестирования и пока недоступен для продажи. Робот поддерживает 3 микромотора на магнитных колесах с возможностью поворота на 360 °. Колеса позволяют легко перемещаться по большинству железных поверхностей. Microbot может быть настроен для поддержки одной микрокамеры. Камера может отправлять обратно в контроллер простые изображения и видео. Робот тоже привязан. Он подключен к своему контроллеру медными проводами, которые можно изолировать для защиты. Робот недорогой и его можно использовать в группах, но он может поддерживать только одну камеру, а привязка слабая. Он также не имеет места для расширения и не может поддерживать какие-либо датчики.

Существуют конструкции роботов, в которых для прикрепления к поверхностям используются присоски или отрицательное давление, создаваемое пропеллерами. Присоски обладают ограниченной мобильностью по сравнению с магнитными колесами и не подходят для тяжелых роботов, оснащенных несколькими камерами и датчиками. Кроме того, мощность всасывания со временем снижается из-за механического износа. Система отрицательного давления требует значительной мощности и постоянной мощности. При отключении питания робот отрывается от поверхности. Каждая из опробованных ранее конструкций имеет свои преимущества и недостатки, но ни одна из них не решает проблему проверки полностью. Обзор литературы позволил мне изучить ландшафт, узнать о том, что уже пробовали раньше, и разработать свой собственный дизайн.

1. Спецификация требований

Робот-инспектор должен отвечать нескольким ограничениям. Первым ограничением для робота будет размер. В идеале инспекционный робот должен быть маленьким. Некоторые пространства, которые робот будет осматривать, имеют ширину и высоту менее фута. Размер в этом проекте ограничен 25x25x25 см. Меньший размер увеличивает мобильность и универсальность робота в сложных условиях, таких как мостовые балки. Преимущество небольшого размера также состоит в том, что робот потребляет меньше энергии и им легче управлять. Робота тоже нужно привязать. Привязанный робот сможет отправлять больше данных быстрее и надежнее, чем беспроводной робот.

Контроллеру робота не придется беспокоиться о том, что робот покинет зону действия беспроводного сигнала, а также он сможет легко извлечь робота в случае аварии или сбоя. Кроме того, инспекционный робот должен поддерживать несколько камер для тщательного осмотра и навигации. Запись с камеры в реальном времени от робота к контроллеру будет необходима для того, чтобы робот мог точно пройти через проверяемую конструкцию и предупредить контролера о непосредственных опасностях. Еще одно ограничение, с которым должен столкнуться робот, - это то, что он должен уметь лазить по железным поверхностям. Самый простой способ удовлетворить это ограничение - это иметь у робота магнитные колеса или магнитное тело, что позволит роботу легко масштабировать железные поверхности. Это связано с тем, что ферромагнитные материалы, такие как низкоуглеродистая сталь, низколегированная сталь и железо, являются основными материалами при строительстве таких конструкций. Наконец, робот должен быть недорогим, желательно не более 200 долларов. Недорогого робота легко заменить, и при осмотре старых конструкций неудивительно, что робот будет поврежден. Недорогой робот также означает, что можно купить больше роботов и использовать их для выполнения определенной задачи, что может значительно повысить эффективность проверки.

4. Дизайн и разработка робота

4.1. Прототип 1:LEGO EV3

Чтобы спроектировать робота, отвечающего указанным выше ограничениям, я начал создание прототипа с помощью модуля управления LEGO EV3 и других деталей LEGO. Изначально я начал работать с LEGO для создания прототипов, потому что их легко построить с помощью LEGO, а создать робота довольно просто. Модуль EV3 - это программируемое ядро ​​робота, которое управляет роботом LEGO и уже было доступно дома. Используя детали LEGO, было довольно легко создать прочное тело робота с четырьмя прикрепленными двигателями и колесами. Начиная с EV3, я пытался сделать своего робота плоским и компактным. Из-за того, как части LEGO сочетаются друг с другом, эта идея потерпела неудачу, когда пришло время прикрепить мои 3 ^rd и 4 ^th мотор. Мне не удалось установить двигатели на модуль управления. Затем я перешел к угловой конструкции, при которой модуль подвешен над остальной частью моего робота, а двигатели выступают из основной рамы. После разработки основной опорной рамы, которая удобно помещалась под контроллером, я смог спроектировать опоры двигателя. Опоры представляли собой наклонные вниз рычаги, которые выступали из основной рамы и прикреплялись к двигателям. Двигатели были тщательно прикреплены к концам опор, чтобы предотвратить разрушение конструкции во время испытаний. Чтобы еще больше стабилизировать двигатели и их опоры, я связал каждый двигатель с ближайшим двигателем с помощью жестких соединителей. Соединитель также не позволял одному двигателю работать намного быстрее, чем другие, поскольку он служил для соединения двигателей и создания вторичного каркаса.

Закончив структурное проектирование и конструирование робота LEGO, я перешел к дизайну колес. Что касается колес, я начал с четырех стандартных колес EV3. Каждое колесо имело радиус 17 мм и ширину 17 мм. К каждому колесу дополнительно прилагалась полая резиновая шина. Чтобы настроить колеса на магнитное движение, я начал со снятия шин. После снятия покрышек осталось только голое пластиковое колесо. В пластике были сказочно глубокие вмятины, которые покрывали большую часть колеса. Из-за вмятин у меня не получалось напрямую прикрепить магниты к колесам. В качестве магнитов для робота LEGO я использовал диски D51-N52 от K&J Magnetics ⁶ . Магниты D51-N52 представляют собой дисковые магниты из неодима, железа и бора (NdFeB) диаметром 5/16 дюйма (8 мм) и толщиной 1/16 дюйма

(1,6 мм). Я решил использовать эти магниты, потому что они были достаточно маленькими, чтобы я мог обернуть их цепочку вокруг колеса и создать магнитную ленту. Каждый D51-N52 имеет тяговое усилие 2,05 фунта (9,1 Ньютона), когда он прикреплен непосредственно к стальной пластине. С четырьмя колесами, обернутыми в магниты, магнетизма будет более чем достаточно, чтобы удерживать робота LEGO, как показано на рисунке 1.

Я опробовал способы крепления магнитов к колесам своего робота. Изначально я пытался обернуть колесо бумагой и приклеить к ней магниты. Эта идея не сработала, потому что бумага была слишком непрочной, чтобы обеспечить твердую поверхность для магнитов, и не была

достаточно сильные, чтобы магниты не слипались и не покидали колесо. Затем я попытался заполнить отверстия на колесах глиной или пластилином и прикрепить к ним магниты. Эта идея также потерпела неудачу, потому что ни один из материалов не мог прилипнуть к суперклее. После того, как ни одна из идей не сработала, я поэкспериментировал, чтобы посмотреть, сработает ли гибрид из двух идей. Я заполнил углубления в колесе сложенными и сжатыми полосками бумаги. Затем я приклеил полоски на место.

После этого я обернул вокруг колеса бумагу, которая была сложена и укреплена тонкими металлическими нитями. Армированная бумага была прочной, но достаточно гибкой поверхностью, чтобы я мог суперклеить магниты. После успешного прикрепления магнитов ко всем четырем колесам я обмотал каждое колесо изолентой вместо шины. Причина, по которой я решил не использовать шину, заключалась в том, что шина слишком сильно уменьшала тянущее усилие магнитов из-за своей толщины, в то время как клейкая лента не могла значительно уменьшить тяговое усилие, сохраняя тягу. Обернув колеса, я пропустил ось LEGO через каждое колесо и использовал ее, чтобы прикрепить каждое колесо к своим двигателям.

Крепление колес положило конец разработке моего первого прототипа. Я протестировал прототип, прижав его к стальной двери. Робот смог плотно прижаться к двери, не соскользнув. Робот не соответствовал нескольким конструктивным ограничениям:он был больше 25x25x25 см, стоил более 200 долларов, не был привязан, требовал батарей и не поддерживал камеры.

Однако этот первоначальный прототип выполнил ключевую задачу. Истинная цель моего первого прототипа заключалась в том, чтобы помочь мне понять, как эффективно прикрепить робота к железной поверхности с помощью магнитов, и помочь мне понять, как сконструировать робота и колеса для решения проблемы проверки.

4.2 Выбор материалов и компонентов для второго прототипа

После создания моего первого прототипа робота с помощью LEGO я решил выбрать компоненты, а также спроектировать и визуализировать свой следующий прототип на компьютере перед началом строительства. Во-первых, я решил, что буду использовать Raspberry Pi в качестве ядра своих будущих прототипов. Причина, по которой я выбрал Raspberry Pi, заключалась в том, что Pi - довольно мощная печатная плата, несмотря на то, что она очень легкая и компактная. Pi может подключаться к платам управления двигателями, сохраняя при этом возможности USB и Ethernet. Кроме того, Pi - очень недорогой компьютер с бесплатным пакетом ОС. На рисунке 2 представлена ​​фотография Raspberry Pi 3.

Затем я решил использовать плату управления двигателями L298N для управления своими двигателями. L298N - довольно простой контроллер двигателя, который может управлять двумя двигателями постоянного тока. Контроллер мотора задокументирован как способный выдерживать напряжение до 35 В. Поскольку большинство двигателей, которые я хотел использовать, были в диапазоне от 6 до 12 В, L298N был идеальным для меня. Сама плата довольно маленькая, всего в треть размера Raspberry Pi. Благодаря этой простоте легко купить несколько L298N по невысокой цене. Я также решил, что начну с одной камеры для моего первого прототипа с Raspberry Pi. Я выбрал камеру Raspberry Pi NoIR.

Эта камера NoIR представляет собой Pi-совместимую камеру, предназначенную для ночного видения. Хотя такие конструкции, как мосты, могут быть освещены, внутри резервуаров, вероятно, будет темно; поэтому я выбрал камеру Pi NoIR вместо стандартной камеры Pi. Я также выбрал камеру NoIR, потому что она создана для Raspberry Pi и ее проще использовать, чем любую другую камеру.

Для своих моторов я выбрал стандартные пластиковые моторы Arduino на 6 В постоянного тока. Я выбрал эти двигатели, даже если они были двигателями Arduino, потому что я знал, что моя плата драйвера может работать с любым двигателем постоянного тока в пределах своего предела напряжения. Я выполнил расчет инженерной механики, как описано ниже, чтобы оценить необходимый крутящий момент двигателя. Пластиковые двигатели очень просты в использовании и проволоке, а также недороги. Если бы один из двигателей сломался, его легко было бы заменить новым. Двигатели также поставляются с пластиковыми колесами, которые достаточно велики, чтобы выдерживать и перемещать робота, но при этом достаточно малы, чтобы ими было легко управлять. В дополнение к моим двум приводным двигателям я хотел использовать еще один двигатель, чтобы создать под роботом рычажный механизм, который мог бы поддерживать его. Этот механизм будет использоваться для подъема передней части робота от земли, чтобы он мог лучше прикрепляться к железной поверхности. Я планировал установить робота на простое пластиковое шасси робота и использовать металлические полосы, чтобы сформировать приподнятую платформу для любой части, которая не могла быть размещена на самом шасси. Я решил запитать L298N от батарейного блока 4-AA или двух батарейных блоков 2-AA. Raspberry Pi был разработан для получения питания от USB-кабеля, подключенного к электрической розетке. Роботом будет управлять проводной контроллер Xbox 360, подключенный к нему с помощью кабеля USB. Я решил использовать Xbox Controller, потому что у него есть направляющая панель, которая идеально подходит для управления движением робота. У него также есть дополнительные кнопки, которые можно назначить для различных задач в коде робота, таких как элементы управления камерой. Что касается магнитов, я решил продолжить использование магнитов D51-N52, потому что я доказал, что их использование для создания магнитной ленты вокруг колеса было возможным методом создания магнитного колеса с моим первым прототипом.

4.3 Компьютерное проектирование (САПР) второго прототипа

После того, как я определился с материалами и компонентами, я бы использовал свои 2 ^nd prototype, я перешел к созданию чертежа моего прототипа в САПР, чтобы я мог легко построить его, как только будут доставлены детали, которые я указал. Для создания чертежей в САПР я использовал программу под названием SketchUp, потому что это программное обеспечение было бесплатным, простым в освоении и простым в использовании. Используя онлайн-измерения и физические измерения (после получения деталей) деталей, которые я планировал использовать для изготовления своих 2-х ^nd прототип робота, я смог построить реалистичный трехмерный чертеж в САПР моего прототипа робота, как показано на рисунке 3. Затем я дополнительно доработал свой прототип, приняв во внимание оптимальное расположение винтов. После нескольких итераций по добавлению конструктивных особенностей и уточнению деталей я смог получить удовлетворительную 3D-модель своего робота. Это помогло упростить аппаратную часть моего проекта, так как мне просто нужно было построить физическую копию компьютерной модели, используя реальные детали.

4.4 Прототип 2a:готовое шасси

Строительный прототип 2а

После того, как все мои детали были доставлены и мои чертежи в САПР были закончены, создание моего робота стало простым делом. Создавая робота, я начал с просверливания отверстий для установки Raspberry Pi. Чтобы нанести точки, которые я хотел бы просверлить на пластиковом шасси, я прижал Pi к задней части шасси и тонким карандашом обозначил область под каждым отверстием для винта на шасси. Затем я выбрал сверло, которое было немного больше, чем отверстия для винтов на Pi, чтобы просверлить каждое отверстие. Затем я аналогичным образом просверлил отверстия в передней части корпуса для размещения платы драйвера. Для крепления платы драйвера и Raspberry Pi я использовал болты и гайки №4-40. После установки обеих плат я использовал прилагаемые винты, чтобы прикрепить заднее колесо и

двигатели в предварительно вырезанные отверстия в шасси. Шасси, двигатели и заднее колесо поставлялись вместе с гайками, болтами и инструкциями, поэтому прикрепить оба компонента к шасси было легко.

Для этого прототипа я использовал прочную двустороннюю ленту, чтобы прикрепить третий двигатель к нижней части робота, прямо между обоими приводными двигателями. Затем я взял четыре палочки для мороженого и склеил их в продольном направлении по две штуки. В результате у меня получилось две очень толстых палочки от мороженого. Затем я разрезал палочки для мороженого пополам и нарисовал конец оси двигателя на концах каждой половинки палочки для мороженого. Затем я использовал дрель, чтобы вырезать отверстие в каждой из новых рукояток, которое бы подходило для оси двигателя. В результате у меня получилось 4 толстых перфорированных палочек половинной длины. Затем я выбрал две палки, которые подходят лучше всего, и прикрепил их к каждому концу оси на среднем двигателе. Я закрепила палочки для мороженого горячим клеем. Назначение этого моторизованного устройства состояло в том, чтобы служить подъемником, который отталкивал бы робота от поверхности, на которой он находился, после того, как двигатель был активирован. Это устройство было разработано, чтобы позволить роботу отрываться от железной поверхности. Это также позволило бы роботу поднять свои основные магнитные колеса над землей, чтобы он мог прикрепиться к железной стене с другой поверхности. Это одна из нескольких уникальных дизайнерских особенностей этого проекта. Еще одна инновационная особенность - конструкция магнитного колеса.

После присоединения третьего двигателя я использовал перфорированную металлическую ленту для подвешивания, чтобы создать мостообразные конструкции над платой драйвера и Raspberry Pi. Подвесная лента служила второстепенной поверхностью, на которую можно было установить дополнительные детали. Из-за перфорации было легко просверлить отверстия в корпусе для крепления металлической подвесной ленты и закрепить ее оставшимися болтами и гайками. Поверх подвесного ленточного моста в передней части робота я прикрепил вторую плату драйвера для управления третьим двигателем, поскольку каждая плата может управлять только двумя двигателями. Мне удалось прикрепить плату драйвера с помощью двустороннего скотча. С помощью большего количества двустороннего скотча я смог прикрепить держатель батарейки 4-AA к верхней части заднего металлического ангара для питания основной платы драйвера. Я также прикрепил два держателя батареек 2-AA к передней части моего робота для питания второй платы драйвера.

Я закончил этот второй прототип горячим приклеиванием камеры Raspberry Pi NoIR к передней части металлического ленточного моста. После сборки робота оставалось только намагнитить колеса. Я снял шины с колес и наложил слой двустороннего скотча на каждое колесо. Пластиковые колеса и двигатели показаны на рис. 4. Я воткнул маленькие круглые магниты D51-N52 по кругу вокруг обода каждого колеса так, чтобы на каждом колесе было по два кольца. После добавления всех магнитов я покрыл оба колеса одним слоем изоленты, чтобы защитить магниты. Чтобы намагнитить заднее колесо, я склеил магниты горячим клеем в кольцо вокруг колеса, а затем обмотал их изолентой. Причина использования клейкой ленты заключалась в том, что она достаточно тонкая, чтобы существенно не уменьшить тянущее усилие, но достаточно прочная, чтобы защитить магниты.

Прототип подключения 2а

После присоединения всех компонентов моего робота я начал соединять их вместе. Питание Raspberry Pi поступало через порт micro USB на его стороне. Затем я подключил аккумуляторные батареи к соответствующим платам драйверов. Двигатели также были подключены к платам драйверов с помощью проводов, идущих в комплекте с двигателями. Я припаял провода к выводам питания на двигателе и соединил их винтами с платой драйвера. Затем я подключил контакты GPIO на Pi к платам драйверов. Контакты GPIO - это контакты ввода / вывода общего назначения на Raspberry Pi. Некоторые контакты используются для заземления и питания, а некоторые могут использоваться для передачи сигналов по проводам. Я подключил GPIO 2 и 6 к одной плате драйвера, а 4 и 9 - к другой плате драйвера. Эти контакты были контактами 5 В и использовались для обеспечения движения двигателя и управления через платы драйверов. Затем я подключил контакты 11, 12, 13 и 15 к первой плате драйвера, а контакты 16 и 18 - к другой плате драйвера. Эти контакты использовались для отправки фактического сигнала управления двигателем. Каждый мотор

требовалось два контакта для управления, а поскольку робот использовал 3 двигателя, платы драйверов требовали 6 подключенных сигнальных контактов GPIO для управления двигателем, в дополнение к 5 В и заземлению на плату. После того, как я подключил необходимые контакты GPIO, я подключил кабель Ethernet между моим Pi и моим ноутбуком, чтобы мой ноутбук мог иметь подключение к удаленному рабочему столу с моим Raspberry Pi, устраняя необходимость в мониторе, клавиатуре и мыши. Я также подключил к своему Pi концентратор с питанием через USB. Хаб был подключен к контроллеру Xbox, чтобы я мог управлять роботом через контроллер Xbox.

Прототип программирования 2а

Самая сложная часть разработки моего 2-го ^nd прототипом был код. В моем первом прототипе это была просто аппаратная модель; он не запускал кода. Моя причина в том, что с моим 1 ^st prototype, как я ни старался, мне не удалось заставить все 4 двигателя двигаться одновременно с кодом. Первый прототип также был создан в основном для проверки концепции магнитного колеса и для того, чтобы помочь мне придумать идеальный дизайн для будущих прототипов. На Raspberry Pi я кодировал на Python, потому что это был единственный язык для Raspberry Pi, который я понимал. Но еще до того, как я начал писать код, мне пришлось настроить своего робота так, чтобы он был совместим с удаленным рабочим столом с моим ноутбуком.

Чтобы настроить свой Pi, мне пришлось временно подключить к Raspberry Pi монитор, клавиатуру и мышь. После этого я загрузил Pi и установил для него статический IP-адрес через Ethernet. Я выбрал 192.168.1.10, потому что это был простой и легкий адрес. Чтобы установить IP, мне пришлось отредактировать

/ect/dhcpcd.conf в моем Pi. Файл dhpcd.conf управляет IP-адресом и сетевым подключением Pi; чтобы установить статический IP, мне пришлось добавить строки в начало файла:

интерфейс eth0

статический ip_address =192.168.1.10 статические маршрутизаторы =192.168.1.1

После установки статического IP-адреса Pi я установил пакет Linux tightvncserver. Tightvncserver - это пакет, который позволяет настроить сервер VNC (виртуальное сетевое соединение) на Raspberry Pi. Подключения к удаленному рабочему столу выполняются через серверы VNC. После настройки сервера VNC я смог создать подключение к удаленному рабочему столу с моим Raspberry Pi через мой

ноутбук. Убедившись, что я могу получить доступ к своему Pi, я отключил монитор, клавиатуру и мышь. Затем я начал кодирование робота.

Во-первых, мне нужен был способ узнать, какой вывод GPIO соответствует какому двигателю на моем Pi. Каждый вывод GPIO при активации вращает один двигатель вперед или назад с постоянной скоростью. Таким образом, каждый двигатель имеет два соответствующих контакта GPIO, контроллер движения вперед и контроллер движения назад. Чтобы узнать, чему соответствует каждый вывод GPIO, я написал программу, которая индивидуально тестировала каждый вывод GPIO, чтобы я мог отметить, какой вывод GPIO что делал. Я записал свои наблюдения в комментариях к моей программе:

импортировать RPi.GPIO как GPIO из режима ожидания по времени

GPIO.setmode (GPIO.BOARD)

GPIO.setup (12, GPIO.OUT) # Влево назад GPIO.setup (11, GPIO.OUT) # Влево вперед GPIO.setup (13, GPIO.OUT) # Вправо вперед 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)

сон (2) GPIO.output (12, GPIO.LOW)

сон (1)

GPIO.output (11, GPIO.HIGH)

сон (2) GPIO.output (11, GPIO.LOW)

сон (1)

GPIO.output (13, GPIO.HIGH)

сон (2) GPIO.output (13, GPIO.LOW)

сон (1)

GPIO.output (15, GPIO.HIGH)

сон (2) GPIO.output (15, GPIO.LOW)

сон (1)

GPIO.output (16, GPIO.HIGH)

спящий режим (0.5) GPIO.output (16, GPIO.LOW)

сон (1)

GPIO.output (18, GPIO.HIGH)

спящий режим (0.5) GPIO.output (18, GPIO.LOW)

сон (1)

Затем мне потребовалось программное обеспечение или код, которые позволили бы моему Raspberry Pi получать и понимать сигналы, отправляемые ему контроллером Xbox. Xboxdrv - это драйвер контроллера Xbox для Linux. Я установил его и попытался подключить Pi к контроллеру Xbox. Обычно запуск команды «sudo xboxdrv» в командной строке отображает входные данные подключенного контроллера Xbox в окне командной строки. Однако мой контроллер Xbox не был произведен Microsoft, поэтому xboxdrv обычно не поддерживает его. Я решил проблему, выполнив команду:

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

Я смог создать эту команду после исследования того, как использовать xboxdrv и как изменить обычную функцию с помощью кода. С помощью этой команды я идентифицировал подключенный контроллер как контроллер Xbox, используя его идентификатор устройства, который был 1bad:f02e. Эта команда позволила мне просмотреть входные данные контроллера в командной строке. Мне нужен был способ доступа к входным значениям из

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