Design und Entwicklung eines kostengünstigen Inspektionsroboters

1. Einführung

Die Infrastruktur unseres Landes altert und verschlechtert sich rapide. Derzeit gibt es keinen Mechanismus, um den Zustand unserer Brücken, Abwassertanks, Pipelines und Reaktoren gründlich zu überprüfen. Viele dieser Strukturen haben das Ende ihrer Lebensdauer erreicht und müssen auf Verschleiß untersucht werden. Wie diese Situation an Land müssen auch die Rümpfe und Decks von Schiffen und Öltankern der US Navy auf Anzeichen von Korrosion untersucht werden. Viele alte Bauwerke, wie hohe Brücken und Abwassertanks, sind aus einer Vielzahl von Gründen oft schwer zu untersuchen oder zu inspizieren. Der häufigste Grund ist, dass der Inspektionsprozess für Menschen gefährlich ist oder die Struktur unzugängliche Abschnitte enthält. Ein weiterer häufiger Grund ist, dass die derzeitige Sondentechnologie möglicherweise nicht ausreicht, um solche Strukturen genau zu untersuchen. Somit ist eine manuelle Inspektion selten, mühsam, teuer, gefährlich und fehleranfällig. Dieses Problem bietet eine perfekte Gelegenheit für einen gut gemachten Inspektionsroboter.

Inspektionsroboter werden in der Regel von großen, gut ausgestatteten Teams von Elektro- und Maschinenbauingenieuren entworfen und entwickelt. Kommerzielle Roboter wie der Packbot 510 (http://endeavorrobotics.com/products) können mehr als 100.000 US-Dollar kosten. Angesichts der Beschränkungen eines einzelnen Science-Fair-Projekts besteht der Umfang hier darin, einen kostengünstigen Prototyp für einen Inspektionsroboter zu konzipieren, zu entwickeln und zu testen. Ziel dieses Projekts ist die Entwicklung eines kleinen, leichten und kostengünstigen Prüfroboter-Prototyps, der an den zu prüfenden Oberflächen befestigt bleiben kann. Das Projekt setzt sich aus folgenden Aufgaben zusammen:Überprüfung der Literatur und bestehender Entwürfe; Spezifikation der Anforderungen; Roboterdesign; Entwicklung erster Prototypen und Tests; Berechnungen der technischen Mechanik; Programmierung des Roboters mit Python; Entwicklung und Erprobung des zweiten Prototyps; und Entwicklung und Test des endgültigen Prototyps.

Vor dem physischen Bau des Roboters wurde die 3D-Modellierungssoftware SketchUp verwendet, um den Roboter zu visualisieren und das Design zu verfeinern. Der Roboter wurde aus handelsüblichen Komponenten gebaut, darunter ein Raspberry Pi 3-Modul zur Steuerung des Roboters. Durch wiederholtes Testen wurde das Design iterativ verbessert. Python-Code wurde von Grund auf neu geschrieben, um den Roboter zu programmieren. Im Zuge der Weiterentwicklung des Designs mussten sowohl die Hardware als auch die Software gleichzeitig modifiziert werden. Der Prototyp wurde den Ingenieursexperten der Washington River Protection Solutions und des Pacific Northwest National Laboratory sowie der Senior Design Class im Bundesstaat Washington vorgeführt

Universität, Tri-Städte. Basierend auf dem Feedback der Experten, Berechnungen der Ingenieurmechanik und den Testergebnissen wurde der dritte Prototyp gebaut und programmiert. Der resultierende Roboter kann Wände mit angemessener Geschwindigkeit erklimmen und verfügt über mehrere Kameras, die bei der Navigation und Inspektion helfen. Der in diesem Projekt hergestellte Roboter stellt ein einzigartiges Design mit speziell für diesen Zweck geschriebener Software dar. Dieser Prototyp dient als flexible Plattform, da nach Bedarf neue Sensoren hinzugefügt werden können, um die Inspektionsfunktionen zu erweitern.

2. Literaturübersicht

Vor Beginn der Projektarbeit habe ich eine Literaturrecherche durchgeführt, um bestehende Lösungen zu bewerten. Derzeit verfügbare Sonden können in zwei Typen eingeteilt werden – stationär und mobil.

Stationäre Sonden sind das am weitesten verbreitete Werkzeug zur Inspektion von Bauwerken. Sie liefern sehr detaillierte Informationen über einen bestimmten Abschnitt eines Bauwerks und können diesen kontinuierlich überwachen. Sobald sie jedoch an einem Ort positioniert sind, wird der Beobachtungsbereich eingeschränkt. Für die Überwachung großer Bauwerke sind sie wegen mangelnder Mobilität ungeeignet. Die andere Kategorie besteht aus robotermontierten Sonden. Diese bieten eine höhere Funktionalität, da die Sonde frei bewegt werden kann. Die meisten derzeit auf dem Markt befindlichen Roboter sind auf eine bestimmte Aufgabe oder Art der Inspektion sehr spezialisiert. Einige Roboter sind möglicherweise darauf spezialisiert, Wasser, große Höhen oder sumpfiges, halbfestes Gelände zu durchqueren, aber keiner dieser Roboter ist für die Strukturprüfung geeignet.

Der aquatische Inspektionsroboter AQUA ¹ ist ein tolles Beispiel. AQUA ist ein hochspezialisierter und teurer Inspektionsroboter. Es kriecht auf dem Grund von Gewässern und macht dreidimensionale (3D) Scans seiner Umgebung. Es ist in der Lage, Kameras, Sensorscans und Algorithmen zu verwenden, um einem bestimmten Pfad unter Wasser zu folgen. Obwohl es sich um einen Inspektionsroboter handelt, ist er für die Strukturinspektion unbrauchbar, da ihm die Fähigkeit fehlt, auf eisenhaltigen Oberflächen zu klettern.

Ein weiteres Beispiel ist der AETOS ² Drohne aus der Luft. Die AETOS-Drohne ist ein Quadrocopter, der zur Vermessung, Landschaftskartierung und Notfallhilfe verwendet wird. Der Roboter selbst ist ein ferngesteuerter Quadrocopter, der eine Hochleistungskamera aufhängt. Die Kamera ist in der Lage, detaillierte Bilder und Videos von Bauwerken und Landschaften aufzunehmen und aufzuzeichnen. Die AETOS-Drohne ist vielseitig einsetzbar und kann sogar exponierte Bauwerke wie Brücken aus der Luft inspizieren. Der Nachteil der Drohne ist, dass sie für detaillierte Strukturinspektionen nicht ideal ist, da der Wind die Drohne mitten in einer Inspektion verdrehen kann. Die Drohne ist auch in geschlossenen Strukturen nicht verwendbar, da sie abstürzen kann. Die AETOS-Drohne muss häufig aufgeladen werden und kann nicht über längere Zeit in der Luft bleiben. Außerdem ist es teuer, anfällig für Beschädigungen und nach einem Absturz schwer wiederzubekommen.

Einige der derzeit verfügbaren Roboter verfügen über leistungsstarke Sensoren, mehrere Kameras und Fähigkeiten zum Klettern an Wänden. Solche Roboter sind extrem kostspielig und können nicht in großer Zahl zur Durchführung von Inspektionen eingesetzt werden. Auch die mit diesen Robotern verbundenen Beschädigungsrisiken und die Wiederbeschaffungskosten sind sehr hoch. Schäden sind eine sehr reale Überlegung, denn seit März 2017 ist praktisch jeder Roboter, der zur Inspektion der beschädigten Kernreaktoren am Standort Fukushima Daiichi in Japan eingesetzt wurde, ausgefallen. Ein Beispiel für einen teuren Roboter ist der MagneBike ³ . Das MagneBike ist ein relativ neuer Roboter, der noch nicht kommerziell verkauft wird, sich aber derzeit in der Erprobung und privaten Entwicklung befindet. Das MagneBike ist ein Roboterfahrrad mit zwei Rädern, die durch ein freies Gelenk mit einem Hauptkörper verbunden sind. Dieses Gelenk ermöglicht es dem Roboter, sich unabhängig von Konturen auf jeder eisenhaltigen Oberfläche frei zu bewegen. Jedes Rad hat auch zwei Hebel an seinen Seiten und ähnelt Stützrädern. Die Länge jedes Hebels ist etwas größer als der Radius jedes Rades. Die Hebel werden verwendet, um das Rad von der magnetischen Oberfläche, mit der es verbunden ist, zu entkoppeln, sodass es in Innenwinkeln reibungslos verfahren werden kann. Das MagneBike kann so eingerichtet werden, dass es eine hochauflösende Kamera unterstützt und einen 3D-Mapping-Sensor unterstützt, mit dem es ein 3D-Modell seiner Umgebung erstellen kann. Der Roboter wird über ein Kabel gesteuert und mit Strom versorgt und ist ein angebundenes Gerät für eine einfache Abrufbarkeit. Der Nachteil des MagneBikes besteht jedoch darin, dass es bei einem Defekt sehr schwer zu ersetzen ist und ziemlich teuer ist, wenn die verwendeten Teile ausreichend sind.

Ein ähnlicher Roboter mit magnetischen Rädern ist der Multi-Segmented Magnetic Robot der US Navy ⁴ (FRAU HERR). Der MSMR ist ein Marineroboter, der für die Inspektion von Schiffsrümpfen entwickelt wurde. Obwohl das MSMR nicht für die oberirdische Bauwerksinspektion ausgelegt ist, könnte es leicht für die Inspektion von Bauwerken angepasst werden. Auch die Inspektion eines Schiffsrumpfes und die Inspektion einer Industriestruktur sind keine unähnlichen Aufgaben. Der MSMR ist ein Roboter mit 3 Segmenten, wobei jedes Segment eine Metallbox mit Elektronik ist, an deren Seiten zwei Räder angebracht sind. Die Segmente werden durch flexible oder gelenkige Verbinder verbunden.

Jedes Rad kann unabhängig arbeiten und der Roboter kann 3D-Hindernisse problemlos erklimmen, wenn alle Räder zusammenarbeiten. Die Räder sind magnetisiert und können den Roboter unterstützen. Die Nachteile des Roboters sind, dass er kein Halteseil besitzt und somit nur von einem Akku gespeist wird. Dies ist nachteilig, da es die Kontrolle des Roboters erheblich erschwert und die Inspektionslebensdauer des Roboters einschränkt. Der MSMR ist auch derzeit unveröffentlicht und wird nur von der Marine verwendet. Das wird der Roboter wohl auf absehbare Zeit bleiben.

Ein weiteres Beispiel für einen Inspektionsroboter ist der Omni-Directional Wall-Climbing Microbot ⁵ . Der Microbot ist ein winziger kreisförmiger Roboter mit einem Gewicht von nur 7,2 Gramm. Es hat einen Durchmesser von 26 mm und eine Höhe von 16,4 mm. Der Bot befindet sich derzeit in der Endphase der Erprobung und ist noch nicht im Handel erhältlich. Der Roboter unterstützt 3 magnetische Rad-Mikromotoren mit 360-Grad-Drehfähigkeit. Die Räder ermöglichen es, die meisten eisenhaltigen Oberflächen mit Leichtigkeit zu überqueren. Der Microbot kann so eingerichtet werden, dass er eine einzelne Mikrokamera unterstützt. Die Kamera kann einfache Bilder und Videos an den Controller zurücksenden. Der Roboter ist auch angebunden. Er ist über Kupferdrähte, die zum Schutz isoliert werden können, mit seinem Controller verbunden. Der Roboter ist zwar günstig und kann in Gruppen verwendet werden, kann jedoch nur eine einzelne Kamera unterstützen und die Halteleine ist schwach. Außerdem fehlt es an Raum für Erweiterungen und kann keine Sensoren unterstützen.

Es gibt Roboterkonstruktionen, die Saugnäpfe oder durch Propeller erzeugten Unterdruck verwenden, um an Oberflächen zu befestigen. Die Saugnäpfe bieten im Vergleich zu Magneträdern eine eingeschränkte Mobilität und sind nicht für schwere Roboter geeignet, die mit mehreren Kameras und Sensoren ausgestattet sind. Darüber hinaus lässt die Saugkraft aufgrund des mechanischen Verschleißes mit der Zeit nach. Das Unterdrucksystem erfordert erhebliche Leistung und konstante Leistung. Bei Stromausfall löst sich der Roboter von der Oberfläche. Jedes der bisher erprobten Designs hat seine Vor- und Nachteile, aber keines hat das Inspektionsproblem vollständig gelöst. Die Literaturrecherche ermöglichte es mir, die Landschaft zu überblicken, zu erfahren, was zuvor versucht wurde, und mein eigenes Design zu entwickeln.

1. Spezifikation der Anforderungen

Der Inspektionsroboter müsste mehrere Randbedingungen erfüllen. Die erste Einschränkung für den Roboter wäre die Größe. Ein Inspektionsroboter wäre idealerweise klein. Einige der Räume, die der Roboter inspizieren würde, sind weniger als 30 cm breit und hoch. Die Größe ist in diesem Projekt auf 25x25x25 cm begrenzt. Die kleinere Größe erhöht die Mobilität und Vielseitigkeit des Roboters in komplexen Umgebungen, wie zum Beispiel Brückenträgern. Ein Vorteil der geringen Größe besteht auch darin, dass der Roboter weniger Strom verbraucht und einfacher zu handhaben ist. Der Roboter müsste auch angebunden werden. Ein angebundener Roboter könnte mehr Daten schneller und zuverlässiger senden als ein drahtloser Roboter.

Die Steuerung des Roboters müsste sich keine Sorgen machen, dass der Roboter die Reichweite des Funksignals verlässt, und könnte den Roboter auch im Falle eines Unfalls oder Ausfalls leicht herausziehen. Darüber hinaus müsste ein Inspektionsroboter mehrere Kameras für eine gründliche Inspektion und Navigation unterstützen. Das Live-Kameramaterial vom Roboter zur Steuerung wäre erforderlich, damit der Roboter genau durch die zu prüfende Struktur fahren und die Steuerung vor unmittelbaren Gefahren warnen kann. Eine weitere Einschränkung, die der Roboter erfüllen muss, besteht darin, dass er in der Lage sein muss, auf eisenhaltigen Oberflächen zu klettern. Der einfachste Weg, diese Einschränkung zu erfüllen, besteht darin, dass der Roboter magnetische Räder oder einen magnetischen Körper hat, wodurch der Roboter leicht eisenhaltige Oberflächen skalieren kann. Dies liegt daran, dass ferromagnetische Materialien, wie Weichstahl, niedriglegierter Stahl und Eisen, Hauptmaterialien beim Bau solcher Strukturen sind. Schließlich sollte der Roboter kostengünstig sein, vorzugsweise mit Kosten unter 200 US-Dollar. Ein kostengünstiger Roboter ist leicht zu ersetzen, und bei der Inspektion älterer Bauwerke wäre es nicht verwunderlich, dass ein Roboter beschädigt wird. Ein kostengünstiger Roboter bedeutet auch, dass mehr Roboter gekauft und für eine Aufgabe verwendet werden können, was die Inspektionseffizienz erheblich steigern kann.

4. Design und Entwicklung des Roboters

4.1. Prototyp 1:LEGO EV3

Um einen Roboter zu entwerfen, der die oben genannten Einschränkungen erfüllt, begann ich mit dem Prototyping mit einem LEGO EV3-Steuermodul und anderen LEGO-Teilen. Ich habe ursprünglich angefangen, mit LEGOs für das Prototyping zu arbeiten, weil es einfach ist, mit LEGOs zu bauen und einen Roboter zu bauen ist ziemlich einfach. Das EV3-Modul ist ein programmierbarer Roboterkern, der den LEGO-Roboter steuert und bereits zu Hause erhältlich war. Mit LEGO-Teilen war es ziemlich einfach, einen robusten Roboterkörper mit 4 angebrachten Motoren und Rädern zu bauen. Als ich mit dem EV3 begann, habe ich versucht, ein flaches, kompaktes Design für meinen Roboter zu entwickeln. Aufgrund der Art und Weise, wie LEGO-Teile zusammenpassen, scheiterte diese Idee, als es an der Zeit war, mein 3. ^rd anzubringen und 4. ^te Motor. Ich konnte meine Motoren nicht an mein Steuermodul montieren. Als nächstes bewegte ich mich in Richtung eines eckigen Designs, bei dem das Modul über dem Rest meines Roboters aufgehängt war und die Motoren sich von einem Hauptrahmen wölbten. Nachdem ich den Hauptträgerrahmen entworfen hatte, der bequem unter den Controller passt, konnte ich Motorstützen entwerfen. Die Stützen waren nach unten geneigte Arme, die aus dem Hauptrahmen herausragten und an den Motoren befestigt waren. Die Motoren wurden gründlich an den Enden der Stützen befestigt, um strukturelles Versagen während des Tests zu verhindern. Um die Motoren und ihre Stützen weiter zu stabilisieren, habe ich jeden Motor mit starren Steckern mit dem nächsten Motor verbunden. Der Stecker verhinderte auch, dass ein Motor viel schneller wurde als die anderen, da er dazu diente, Motoren miteinander zu verbinden und ein sekundäres Gerüst zu schaffen.

Nachdem ich mit dem strukturellen Design und dem Bau des LEGO Roboters fertig war, ging ich zum Design der Räder über. Bei den Rädern habe ich mit 4 EV3-Rädern in Standardgröße angefangen. Jedes Rad hatte einen Radius von 17 mm und eine Breite von 17 mm. Jedes Rad wurde zusätzlich mit einem daran befestigten, hohlen Gummireifen geliefert. Um die Räder für die magnetische Bewegung zu konfigurieren, begann ich mit dem Entfernen der Reifen. Nach dem Abnehmen der Reifen war nur noch das blanke Plastikrad übrig. Der Kunststoff hatte feenhafte Vertiefungen, die durchweg den größten Teil des Rades bedeckten. Aufgrund der Vertiefungen konnte ich Magnete nicht direkt an den Rädern anbringen. Die Magnete, die ich für den LEGO-Roboter verwendet habe, waren D51-N52-Scheiben von K&J Magnetics ⁶ . D51-N52 Magnete sind Neodym-Eisen-Bor (NdFeB) Scheibenmagnete mit einem Durchmesser von 5/16” (8 mm) und einer Dicke von 1/16”

(1,6 mm). Ich habe mich für diese Magnete entschieden, weil sie klein genug waren, um eine Kette von ihnen um das Rad zu wickeln und ein Magnetband zu erstellen. Jeder D51-N52 hat eine Zugkraft von 2,05 lb (9,1 Newton), wenn er direkt auf eine Stahlplatte geklebt wird. Mit vier in die Magnete gewickelten Rädern wäre der Magnetismus mehr als ausreichend, um den LEGO-Roboter zu halten, der in Abbildung 1 gezeigt wird.

Ich habe Methoden zum Anbringen von Magneten an den Rädern meines Roboters getestet. Ich habe ursprünglich versucht, ein Papier um das Rad zu wickeln und Magnete auf dieses Papier zu kleben. Diese Idee funktionierte nicht, weil das Papier zu schwach war, um eine feste Oberfläche für die Magnete zu bieten, und es nicht war

stark genug, um zu verhindern, dass die Magnete zusammenklumpen und das Rad verlassen. Als nächstes versuchte ich, die Löcher an den Rädern mit Ton oder Playdoh zu füllen und Magnete darüber zu befestigen. Diese Idee scheiterte auch daran, dass keines der Materialien an Sekundenkleber haften würde. Nachdem keine der Ideen funktioniert hatte, experimentierte ich, um zu sehen, ob eine Mischung der beiden Ideen funktionieren würde. Die Vertiefungen im Rad habe ich mit gefalteten und zusammengedrückten Papierstreifen ausgefüllt. Ich habe dann die Streifen mit Sekundenkleber an Ort und Stelle geklebt.

Danach wickelte ich Papier, das gefaltet und mit dünnen Metallsträngen verstärkt wurde, um das Rad. Das verstärkte Papier war eine stabile und dennoch flexibel genug Oberfläche für mich, um Magnete mit Sekundenkleber zu kleben. Nachdem ich Magnete erfolgreich an allen vier Rädern befestigt hatte, wickelte ich jedes Rad mit Klebeband, anstatt einen Reifen zu verwenden. Der Grund, warum ich mich entschieden habe, keinen Reifen zu verwenden, war, dass ein Reifen aufgrund seiner Dicke die Zugkraft der Magnete zu stark reduzieren würde, während Klebeband die Zugkraft nicht wesentlich reduzierte und dennoch Traktion bietet. Nachdem ich die Räder gewickelt hatte, ließ ich eine LEGO-Achse durch jedes Rad laufen und benutzte sie, um jedes Rad an meinen Motoren zu befestigen.

Die Anbringung der Räder markierte das Ende der Entwicklung meines ersten Prototyps. Ich testete den Prototyp, indem ich ihn an eine Stahltür drückte. Der Roboter konnte sich fest an der Tür festhalten, ohne abzurutschen. Der Roboter erfüllte mehrere Designvorgaben nicht:Er war größer als 25 x 25 x 25 cm, kostete mehr als 200 US-Dollar, war nicht angebunden, benötigte Batterien und unterstützte keine Kameras.

Dieser erste Prototyp erfüllte jedoch ein wichtiges Ziel. Das wahre Ziel meines ersten Prototyps war es, mir zu helfen, zu verstehen, wie man einen Roboter effizient mit Magneten an einer eisenhaltigen Oberfläche befestigt, und mir zu helfen, zu verstehen, wie man einen Roboter und Räder konstruiert, um das Inspektionsproblem zu lösen.

4.2     Material- und Komponentenauswahl für den zweiten Prototyp

Nachdem ich meinen ersten Roboterprototyp mit LEGOs gebaut hatte, beschloss ich, Komponenten auszuwählen und meinen nächsten Prototypen auf dem Computer zu entwerfen und zu visualisieren, bevor ich mit dem Bau begann. Zuerst entschied ich mich, einen Raspberry Pi als Kernstück meiner zukünftigen Prototypen zu verwenden. Der Grund, warum ich mich für den Raspberry Pi entschieden habe, war, dass der Pi eine ziemlich leistungsstarke Platine ist, obwohl er sehr leicht und kompakt ist. Der Pi kann an Motorsteuerplatinen angeschlossen werden und verfügt dennoch über USB- und Ethernet-Funktionen. Darüber hinaus ist der Pi ein sehr günstiger Computer und wird mit einem kostenlosen Betriebssystempaket geliefert. Abbildung 2 ist ein Foto des Raspberry Pi 3.

Als nächstes entschied ich mich, die Motorsteuerplatine L298N zu verwenden, um meine Motoren zu steuern. Der L298N ist ein relativ einfacher Motorcontroller, der bis zu 2 Gleichstrommotoren steuern kann. Der Motorcontroller ist für Spannungen von bis zu 35 V dokumentiert. Da die meisten Motoren, die ich verwenden wollte, im Bereich von 6 V-12 V lagen, war der L298N für mich ideal. Das Board selbst ist ziemlich klein, nur ein Drittel so groß wie ein Raspberry Pi. Aufgrund dieser Einfachheit ist es einfach, mehrere L298N zu geringen Kosten zu kaufen. Ich entschied mich auch, für meinen ersten Prototypen mit dem Raspberry Pi mit einer einzigen Kamera zu beginnen. Die von mir gewählte Kamera ist die Raspberry Pi NoIR-Kamera.

Diese NoIR-Kamera ist eine Pi-kompatible Kamera, die für Nachtsicht entwickelt wurde. Während Strukturen wie Brücken beleuchtet sein können, ist das Innere von Panzern wahrscheinlich dunkel; Also habe ich die Pi NoIR-Kamera anstelle der Standard-Pi-Kamera gewählt. Ich habe mich auch für die NoIR-Kamera entschieden, weil sie für den Raspberry Pi gebaut wurde und einfacher zu bedienen wäre als jede andere Kamera.

Für meine Motoren habe ich Standard-6-V-DC-Arduino-Motoren aus Kunststoff gewählt. Ich wählte diese Motoren, obwohl es sich um Arduino-Motoren handelte, weil ich wusste, dass meine Treiberplatine jeden DC-Motor innerhalb seiner Spannungsgrenze betreiben konnte. Ich habe eine Berechnung der technischen Mechanik durchgeführt, wie unten beschrieben, um das erforderliche Motordrehmoment abzuschätzen. Die Kunststoffmotoren sind sehr einfach zu handhaben und zu verdrahten, und zudem kostengünstig. Wenn einer der Motoren kaputt ging, wäre er leicht durch einen neuen Motor zu ersetzen. Die Motoren werden auch mit Kunststoffrädern geliefert, die groß genug sind, um den Roboter zu stützen und zu bewegen, aber klein genug, um leicht gesteuert zu werden. Neben meinen beiden Antriebsmotoren wollte ich mit einem weiteren Motor einen Hebelmechanismus unter dem Roboter schaffen, der ihn abstützen könnte. Der Mechanismus würde verwendet werden, um das vordere Ende des Roboters vom Boden abzuheben, damit er besser an einer eisenhaltigen Oberfläche befestigt werden kann. Ich hatte vor, den Roboter auf einem einfachen Roboterchassis aus Kunststoff zu montieren und mit Metallstreifen eine erhöhte Plattform für alle Teile zu bilden, die nicht auf dem Chassis selbst untergebracht werden konnten. Ich beschloss, die L298Ns mit einem 4-AA-Akku oder zwei 2-AA-Akkus zu betreiben. Der Raspberry Pi wurde entwickelt, um Strom über ein USB-Kabel zu erhalten, das bis zu einer Steckdose reicht. Der Roboter würde über einen kabelgebundenen Xbox 360-Controller gesteuert, der über ein USB-Kabel mit ihm verbunden war. Ich habe mich für einen Xbox Controller entschieden, da dieser über ein Steuerkreuz verfügt, das ideal wäre, um die Bewegung des Roboters zu steuern. Es verfügt auch über zusätzliche Schaltflächen, die verschiedenen Aufgaben innerhalb des Robotercodes zugewiesen werden können, z. B. Kamerasteuerungen. Für die Magnete entschied ich mich, weiterhin D51-N52-Magnete zu verwenden, weil ich bewiesen hatte, dass die Verwendung dieser Magnete zum Erstellen eines Magnetbandes um ein Rad eine praktikable Methode zum Erstellen eines Magnetrads mit meinem ersten Prototyp war.

4.3    Computer Aided Design (CAD) des zweiten Prototyps

Nachdem ich mich für die Materialien und Komponenten entschieden hatte, die ich verwenden würde, um mein 2. ^nd herzustellen Prototypen erstellte ich eine CAD-Zeichnung meines Prototyps, damit ich ihn problemlos konstruieren konnte, sobald die von mir angegebenen Teile eingetroffen waren. Um die CAD-Zeichnungen zu erstellen, habe ich eine Software namens SketchUp verwendet, da die Software kostenlos, leicht selbst zu erlernen und einfach zu bedienen war. Unter Verwendung von Online- und physischen Messungen (sobald die Teile angekommen sind) der Teile, die ich verwenden wollte, um mein zweites ^nd . herzustellen Prototyp-Roboter konnte ich eine realistische 3D-CAD-Zeichnung meines Roboter-Prototyps erstellen, wie in Abbildung 3 gezeigt. Anschließend habe ich meinen Prototyp unter Berücksichtigung der optimalen Schraubenpositionen weiter verfeinert. Nach einigen Iterationen des Hinzufügens von Konstruktionsmerkmalen und Verfeinern der Details war ich in der Lage, ein zufriedenstellendes 3D-Modell meines Roboters zu erhalten. Dies diente dazu, den Hardwareteil meines Projekts zu vereinfachen, da ich nur eine physische Kopie des Computermodells mit realen Teilen erstellen musste.

4.4   Prototyp 2a:Vorgefertigtes Gehäuse

Prototyp 2a bauen

Nachdem alle meine Teile angekommen waren und meine CAD-Zeichnungen fertig waren, war der Bau meines Roboters eine einfache Sache. Beim Bau des Roboters habe ich zunächst Löcher gebohrt, auf denen der Raspberry Pi montiert werden soll. Um die Punkte zu zeichnen, die ich auf dem Kunststoffchassis bohren würde, hielt ich den Pi oben auf das hintere Ende des Chassis und markierte mit einem dünnen Bleistift den Bereich unter jedem Schraubenloch auf dem Chassis. Ich wählte dann einen Bohrer aus, der etwas größer war als die Schraubenlöcher auf dem Pi, um jedes Loch zu bohren. Ich bohrte dann ähnlich Löcher an der Vorderseite des Chassis, um die Treiberplatine aufzunehmen. Um die Treiberplatine und den Raspberry Pi zu montieren, habe ich #4-40 Schrauben und Muttern verwendet. Nachdem ich beide Boards montiert hatte, habe ich die mitgelieferten Schrauben verwendet, um das Hinterrad zu befestigen und

Motoren, um Löcher in das Chassis vorzuschneiden. Das Chassis, die Motoren und das Hinterrad wurden zusammen mit Muttern, Schrauben und Anweisungen geliefert, sodass die Befestigung beider Komponenten am Chassis einfach war.

Für diesen Prototyp habe ich schweres doppelseitiges Klebeband verwendet, um einen dritten Motor an der Unterseite des Roboters direkt zwischen den beiden Antriebsmotoren zu befestigen. Ich nahm dann vier Eis am Stiel und klebte sie der Länge nach in Zweiersätzen zusammen. Als Ergebnis habe ich zwei sehr dicke Eisstiele bekommen. Ich schneide dann die Eisstiele in zwei Hälften und skizzierte das Ende der Motorachse am Ende jedes halben Eisstiels. Ich benutzte dann einen Bohrer, um in jedem der neuen Stöcke ein Loch zu schnitzen, das die Motorachse aufnehmen würde. Als Ergebnis bekam ich 4 dicke, halblange, gebohrte Eisstiele. Ich wählte dann die beiden Stöcke aus, die am besten passten, und befestigte sie an jedem Ende der Achse des Mittelmotors. Ich befestigte die Popsicle-Sticks mit Heißkleber. Der Zweck dieser motorisierten Vorrichtung bestand darin, als Heber zu dienen, der den Roboter von der Oberfläche stoßen würde, auf der er sich befand, sobald der Motor aktiviert wurde. Dieses Gerät wurde entwickelt, um es dem Roboter zu ermöglichen, sich von einer eisenhaltigen Oberfläche zu lösen. Es würde dem Roboter auch ermöglichen, seine Hauptmagneträder vom Boden zu heben, damit er sich von einer anderen Oberfläche aus an einer eisenhaltigen Wand befestigen könnte. Dies ist eines von mehreren einzigartigen Designmerkmalen dieses Projekts. Das Magnetrad-Design ist ein weiteres innovatives Merkmal.

Nach dem Anbringen des dritten Motors habe ich perforiertes Metallaufhängerband verwendet, um brückenartige Strukturen über der Treiberplatine und dem Raspberry Pi zu erstellen. Das Aufhängerband diente als Nebenfläche, auf der weitere Teile montiert werden konnten. Aufgrund der Perforationen war es einfach, Löcher in das Chassis zu bohren, um das Metallaufhängerband zu passen, und es mit übrig gebliebenen Schrauben und Muttern zu befestigen. Oben auf der Hängebandbrücke an der Vorderseite des Roboters habe ich eine zweite Treiberplatine angebracht, um den dritten Motor zu steuern, da jede Platine nur zwei Motoren steuern kann. Die Treiberplatine konnte ich mit doppelseitigem Klebeband befestigen. Mit mehr doppelseitigem Klebeband konnte ich einen 4-AA-Batteriehalter an der Oberseite des hinteren Metallhangars anbringen, um die Haupttreiberplatine mit Strom zu versorgen. Ich habe auch zwei 2-AA-Batteriehalter an der Vorderseite meines Roboters angebracht, um die zweite Treiberplatine mit Strom zu versorgen.

Ich beendete diesen zweiten Prototyp, indem ich die Raspberry Pi NoIR-Kamera auf die Vorderseite der Metallbügel-Bandbrücke klebete. Nach dem Bau des Roboters mussten nur noch die Räder magnetisiert werden. Ich entfernte die Reifen von den Rädern und legte eine Schicht doppelseitiges Klebeband über jedes Rad. Die Kunststoffräder und -motoren sind in Abbildung 4 dargestellt. Ich klebte die kleinen runden D51-N52-Magnete in einem Kreis um die Felge jedes Rades, so dass sich auf jedem Rad zwei Ringe befanden. Nachdem ich alle Magnete hinzugefügt hatte, bedeckte ich beide Räder mit einer einzigen Schicht Klebeband, um die Magnete zu schützen. Um das Hinterrad zu magnetisieren, klebte ich Magnete in einem Ring um das Rad herum und wickelte sie dann in Klebeband. Der Grund für die Verwendung von Klebeband war, dass es dünn genug ist, um die Zugkraft nicht wesentlich zu reduzieren, aber stark genug, um die Magnete zu schützen.

Verdrahtungsprototyp 2a

Nachdem ich alle Komponenten meines Roboters angebracht hatte, begann ich, sie miteinander zu verdrahten. Der Strom für den Raspberry Pi kam über den Micro-USB-Anschluss an seiner Seite. Ich habe dann die Akkus mit ihren jeweiligen Treiberplatinen verdrahtet. Die Motoren wurden auch mit den mit den Motoren gelieferten Drähten mit den Treiberplatinen verbunden. Ich lötete die Drähte an die Stromkabel am Motor und verband sie mit Schrauben mit der Treiberplatine. Ich habe dann die GPIO-Pins des Pi mit den Treiberplatinen verdrahtet. Die GPIO-Pins sind Allzweck-Eingangs-/Ausgangspins auf dem Raspberry Pi. Einige Pins werden für Masse und Strom verwendet, während andere zum Senden von Signalen über einen Draht verwendet werden können. Ich habe GPIO 2 &6 an eine Treiberplatine und 4 &9 an die andere Treiberplatine angeschlossen. Diese Pins waren 5-V-Pins und wurden verwendet, um die Motorbewegung und -steuerung über die Treiberplatinen zu ermöglichen. Ich habe dann die Pins 11, 12, 13 und 15 mit der ersten Treiberplatine und die Pins 16 und 18 mit der anderen Treiberplatine verdrahtet. Diese Pins wurden zum Senden des eigentlichen Motorsteuersignals verwendet. Jeder Motor

benötigte zwei Pins für die Steuerung, und da der Roboter 3 Motoren verwendete, benötigten die Treiberplatinen 6 verbundene Signal-GPIO-Pins für die Motorsteuerung, zusätzlich zu 5 V und Masse pro Platine. Nachdem ich die notwendigen GPIO-Pins angeschlossen hatte, habe ich ein Ethernet-Kabel zwischen meinem Pi und meinem Laptop angeschlossen, damit mein Laptop eine Remote-Desktop-Verbindung mit meinem Raspberry Pi haben kann, ohne dass Monitor, Tastatur und Maus benötigt werden. Ich habe auch einen aktiven Hub über USB an meinen Pi angeschlossen. Der Hub war mit einem Xbox-Controller verbunden, sodass ich den Roboter über den Xbox-Controller steuern konnte.

Prototyp 2a programmieren

Das Schwierigste an der Gestaltung meines 2. ^nd Prototyp war der Code. Bei meinem ersten Prototyp war es lediglich ein Hardwaremodell; es lief kein Code. Mein Grund ist, mit meinem 1. ^st Prototyp, so sehr ich es auch versuchen mag, ich konnte nicht alle 4 Motoren gleichzeitig mit dem Code bewegen. Der erste Prototyp wurde auch hauptsächlich erstellt, um das Magnetradkonzept zu testen und mir zu helfen, ein ideales Design für zukünftige Prototypen zu finden. Auf dem Raspberry Pi habe ich mit Python codiert, weil es die einzige Sprache für den Raspberry Pi war, die ich verstand. Aber noch bevor ich mit meinem Code begann, musste ich meinen Roboter so einrichten, dass er Remote-Desktop-kompatibel mit meinem Laptop war.

Um meinen Pi einzurichten, musste ich vorübergehend einen Monitor, eine Tastatur und eine Maus an den Raspberry Pi anschließen. Danach habe ich den Pi hochgefahren und eine statische IP dafür über Ethernet eingestellt. Ich habe 192.168.1.10 gewählt, weil es eine einfache und unkomplizierte Adresse war. Um die IP einzustellen musste ich bearbeiten

/ect/dhcpcd.conf in meinem Pi. Die Datei dhpcd.conf steuert die IP- und Netzwerkverbindung des Pi; Um eine statische IP zu setzen, musste ich die Zeilen am Anfang der Datei hinzufügen:

Schnittstelle eth0

statische IP-Adresse=192.168.1.10 statische Router=192.168.1.1

Nachdem ich die statische IP des Pi eingestellt hatte, installierte ich das Linux-Paket tightvncserver. Tightvncserver ist ein Paket, das die Einrichtung eines VNC-Servers (Virtual Network Connection) auf dem Raspberry Pi ermöglicht. Remotedesktopverbindungen werden über VNC-Server ausgeführt. Nach dem Einrichten des VNC-Servers konnte ich über mein

. eine Remotedesktop-Verbindung zu meinem Raspberry Pi herstellen

Laptop. Nachdem ich bestätigt hatte, dass ich auf meinen Pi zugreifen konnte, trennte ich meinen Monitor, meine Tastatur und meine Maus. Dann begann ich mit der Codierung für den Roboter.

Zuerst brauchte ich eine Möglichkeit herauszufinden, welcher GPIO-Pin welchem ​​Motor auf meinem Pi entsprach. Jeder GPIO-Pin dreht bei Aktivierung einen einzelnen Motor mit konstanter Geschwindigkeit entweder vorwärts oder rückwärts. Somit hat jeder Motor zwei entsprechende GPIO-Pins, einen Vorwärtsbewegungscontroller und einen Rückwärtsbewegungscontroller. Um herauszufinden, was jedem GPIO-Pin entsprach, schrieb ich ein Programm, das jeden GPIO-Pin einzeln testete, damit ich notieren konnte, welcher GPIO-Pin was tat. Ich habe meine Beobachtungen durch Kommentare zu meinem Programm aufgezeichnet:

RPi.GPIO als GPIO aus der Zeit importieren Schlaf importieren

GPIO.setmode(GPIO.BOARD)

GPIO.setup(12,GPIO.OUT) #Links Rückwärts GPIO.setup(11,GPIO.OUT) #Links Vorwärts GPIO.setup(13,GPIO.OUT) #Rechts Vorwärts GPIO.setup(15,GPIO.OUT) # Rechts Rückwärts 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)

schlafen(1)

GPIO.output(11,GPIO.HIGH)

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

schlafen(1)

GPIO.output(13,GPIO.HIGH)

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

schlafen(1)

GPIO.output(15,GPIO.HIGH)

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

schlafen(1)

GPIO.output(16,GPIO.HIGH)

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

schlafen(1)

GPIO.output(18,GPIO.HIGH)

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

schlafen(1)

Als nächstes brauchte ich eine Software oder einen Code, der es meinem Raspberry Pi ermöglicht, die vom Xbox-Controller an ihn gesendeten Signale zu empfangen und zu verstehen. Xboxdrv ist ein Xbox-Controller-Treiber für Linux. Ich habe es installiert und versucht, meinen Pi mit meinem Xbox-Controller zu verbinden. Normalerweise werden beim Ausführen des Befehls „sudo xboxdrv“ in der Eingabeaufforderung die Eingaben des verbundenen Xbox-Controllers im Eingabeaufforderungsfenster angezeigt. Mein Xbox-Controller wurde jedoch nicht von Microsoft hergestellt, daher wurde er von xboxdrv nicht normal unterstützt. Ich habe das Problem behoben, indem ich den Befehl ausgeführt habe:

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

Ich konnte diesen Befehl erstellen, nachdem ich untersucht hatte, wie man xboxdrv verwendet und wie man die normale Funktion mit Code ändert. Mit diesem Befehl habe ich den verbundenen Controller anhand seiner Geräte-ID, die 1bad:f02e war, als Xbox-Controller identifiziert. Mit diesem Befehl konnte ich die Eingaben des Controllers in der Eingabeaufforderung anzeigen. Ich brauchte eine Möglichkeit, von einem

. auf die Eingabewerte zuzugreifen

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