1. Inleiding

De infrastructuur van ons land veroudert en verslechtert snel. Momenteel is er geen mechanisme om de staat van onze bruggen, afvaltanks, pijpleidingen en reactoren grondig te inspecteren. Veel van deze constructies hebben het einde van hun ontwerplevensduur bereikt en moeten worden geïnspecteerd op verslechtering. Net als deze situatie op het land, is het ook nodig om de rompen en dekken van Amerikaanse marineschepen en olietankers te inspecteren op tekenen van corrosie. Veel oude constructies, zoals hoge bruggen en afvaltanks, zijn om verschillende redenen vaak moeilijk te onderzoeken of te inspecteren. De meest voorkomende reden is dat het inspectieproces gevaarlijk is voor mensen, of dat de constructie delen heeft die ontoegankelijk zijn. Een andere veel voorkomende reden is dat de huidige sondetechnologie mogelijk niet toereikend is om dergelijke structuren nauwkeurig te inspecteren. Handmatige inspectie is dus zeldzaam, arbeidsintensief, duur, gevaarlijk en foutgevoelig. Dit probleem biedt een uitgelezen kans voor een goed gemaakte inspectierobot.

Inspectierobots worden doorgaans ontworpen en ontwikkeld door grote, goed gefinancierde teams van elektrische en mechanische ingenieurs. Commerciële robots, zoals de Packbot 510 (http://endeavorrobotics.com/products), kunnen meer dan $ 100.000 kosten. Gezien de beperkingen van een individueel wetenschapsbeursproject, is het hier de bedoeling om een ​​goedkoop prototype voor een inspectierobot te ontwerpen, ontwikkelen en testen. Het doel van dit project is om een ​​klein, lichtgewicht en goedkoop prototype van een inspectierobot te ontwikkelen die aan de te inspecteren oppervlakken kan blijven zitten. Het project bestaat uit de volgende taken:literatuuronderzoek en bestaande ontwerpen; specificatie van eisen; robotontwerp; ontwikkeling van het eerste prototype en testen; technische mechanica berekeningen; de robot programmeren met Python; ontwikkeling en testen van het tweede prototype; en ontwikkeling en testen van het definitieve prototype.

Voordat de robot fysiek werd gebouwd, werd de 3D-modelleringssoftware SketchUp gebruikt om de robot te visualiseren en het ontwerp te verfijnen. De robot is opgebouwd uit commerciële kant-en-klare componenten, waaronder een Raspberry Pi 3-module om de robot te besturen. Het ontwerp werd iteratief verbeterd door herhaalde tests. Python-code is helemaal opnieuw geschreven om de robot te programmeren. Naarmate het ontwerp evolueerde, moesten zowel de hardware als de software tegelijk worden aangepast. Het prototype werd gedemonstreerd aan technische experts van Washington River Protection Solutions en Pacific Northwest National Laboratory, en de Senior Design Class in de staat Washington

Universiteit, drie steden. Op basis van feedback van de experts, technische mechanica-berekeningen en de testresultaten werd het derde prototype gebouwd en geprogrammeerd. De resulterende robot kan met een redelijke snelheid muren beklimmen en heeft meerdere camera's om te helpen bij navigatie en inspectie. De robot die door dit project wordt geproduceerd, vertegenwoordigt een uniek ontwerp met software die speciaal voor dit doel is geschreven. Dit prototype dient als een flexibel platform doordat nieuwe sensoren kunnen worden toegevoegd als dat nodig is om de inspectiemogelijkheden te vergroten.

2. Literatuuroverzicht

Voordat ik aan het project begon, voerde ik een literatuuronderzoek uit om bestaande oplossingen te evalueren. De momenteel beschikbare sondes kunnen in twee typen worden ingedeeld:stationair en mobiel.

Stationaire sondes zijn het meest gebruikte hulpmiddel voor het inspecteren van constructies. Ze geven zeer gedetailleerde informatie over een bepaald deel van een constructie en kunnen deze continu bewaken. Als ze echter eenmaal op een locatie zijn geplaatst, is het waarnemingsbereik beperkt. Door het gebrek aan mobiliteit zijn ze niet geschikt voor het bewaken van grote constructies. De andere categorie bestaat uit op een robot gemonteerde sondes. Deze bieden een grotere mate van functionaliteit omdat de sonde vrij kan worden bewogen. De meeste robots die momenteel op de markt zijn, zijn zeer gespecialiseerd in een specifieke taak of soort inspectie. Sommige robots zijn misschien gespecialiseerd in het doorkruisen van water, grote hoogten of moerassig halfvast terrein, maar geen van deze robots is nuttig voor structurele inspectie.

De aquatische inspectierobot AQUA ¹ is een geweldig voorbeeld. AQUA is een zeer gespecialiseerde en dure inspectierobot. Het kruipt op de bodem van waterlichamen en maakt driedimensionale (3D) scans van zijn gebied. Het kan camera's, sensorscans en algoritmen gebruiken om een ​​aangewezen pad onder water te volgen. Ondanks het feit dat het een inspectierobot is, is het nutteloos voor structurele inspectie, omdat het niet in staat is om op ijzerhoudende oppervlakken te klimmen.

Een ander voorbeeld is de AETOS ² lucht drone. De AETOS-drone is een quadcopter die wordt gebruikt voor landmetingen, landschapskaarten en noodhulp. De robot zelf is een op afstand bestuurde quadcopter die een krachtige camera ophangt. De camera kan gedetailleerde afbeeldingen en video's van structuren en landschappen vastleggen en opnemen. De AETOS-drone is veelzijdig inzetbaar en kan zelfs blootgestelde constructies zoals bruggen vanuit de lucht inspecteren. Het nadeel van de drone is dat hij niet ideaal is voor gedetailleerde bouwkundige inspecties, omdat wind de drone kan verschuiven terwijl hij midden in een inspectie zit. De drone kan ook niet worden gebruikt binnen gesloten constructies, omdat deze het risico loopt te crashen. De AETOS-drone moet regelmatig worden opgeladen en kan niet voor langere tijd in de lucht blijven. Het is ook duur, vatbaar voor schade en moeilijk te herstellen na een crash.

Sommige van de momenteel beschikbare robots bevatten krachtige sensoren, meerdere camera's en mogelijkheden om muren te beklimmen. Dergelijke robots zijn extreem kostbaar en kunnen niet in grote aantallen worden ingezet om inspecties uit te voeren. De risico's op schade die aan deze robots zijn verbonden en de vervangingskosten zijn ook zeer hoog. Schade is een zeer reële overweging, omdat praktisch elke robot die werd ingezet om de beschadigde kernreactoren op de Fukushima Daiichi-site in Japan te inspecteren, sinds maart 2017 is uitgevallen. Een voorbeeld van een dure robot is de MagneBike ³ . De MagneBike is een vrij nieuwe robot die nog niet commercieel wordt verkocht, maar momenteel wordt getest en privé wordt ontwikkeld. De MagneBike is een robotfiets met twee wielen die door een vrije verbinding met een hoofdlichaam zijn verbonden. Door dit gewricht kan de robot vrij bewegen op elk ijzerhoudend oppervlak, ongeacht de contouren. Elk wiel heeft ook twee hendels die aan de zijkanten zijn bevestigd en lijkt op zijwieltjes. De lengte van elke hendel is iets groter dan de straal van elk wiel. De hendels worden gebruikt om het wiel los te koppelen van het magnetische oppervlak waarmee het is verbonden, zodat het soepel over binnenhoeken kan bewegen. De MagneBike kan worden ingesteld om een ​​high-definition camera te ondersteunen en ondersteunt een 3D-mappingsensor, waarmee hij een 3D-model van zijn omgeving kan maken. De robot wordt bestuurd en gevoed via een kabel en is een vastgemaakt apparaat voor gemakkelijke terughaalbaarheid. Het nadeel van de MagneBike is echter dat hij erg moeilijk te vervangen is als hij kapot is, en vrij duur als de gebruikte onderdelen iets te bieden hebben.

Een vergelijkbare robot met magnetische wielen is de Multi-Segmented Magnetic Robot van de Amerikaanse marine ⁴ (MEVR. DHR). De MSMR is een marinerobot die is ontworpen voor het inspecteren van scheepsrompen. Hoewel de MSMR niet is ontworpen voor bovengrondse structurele inspectie, kan deze gemakkelijk worden aangepast om constructies te inspecteren. Ook het inspecteren van een scheepsromp en het inspecteren van een industriële constructie zijn geen ongelijksoortige taken. De MSMR is een robot met 3 segmenten, waarbij elk segment een metalen doos met elektronica is, met twee wielen aan de zijkanten. De segmenten zijn verbonden door flexibele of scharnierende connectoren.

Elk wiel kan onafhankelijk werken en de robot kan 3D-obstakels gemakkelijk schalen wanneer alle wielen samenwerken. De wielen zijn gemagnetiseerd en kunnen de robot ondersteunen. De nadelen van de robot zijn dat deze geen ketting heeft en dus alleen wordt aangedreven door een batterij. Dit is nadelig, omdat het de robot aanzienlijk moeilijker te besturen maakt en de inspectielevensduur van de robot beperkt. De MSMR is momenteel ook niet vrijgegeven en wordt alleen door de marine gebruikt. De robot zal waarschijnlijk in de nabije toekomst zo blijven.

Een ander voorbeeld van een inspectierobot is de Omni-Directional Wall-Climbing Microbot ⁵ . De Microbot is een minuscule cirkelvormige robot met een gewicht van slechts 7,2 gram. Het heeft een diameter van 26 mm en een hoogte van 16,4 mm. De bot bevindt zich momenteel in de laatste testfase en is nog niet commercieel verkrijgbaar. De robot ondersteunt 3 magnetische micromotoren op wielen met 360° draaimogelijkheid. Dankzij de wielen kan hij gemakkelijk over de meeste ijzerhoudende oppervlakken rijden. De Microbot kan worden ingesteld om een ​​enkele microcamera te ondersteunen. De camera kan eenvoudige afbeeldingen en video's terugsturen naar de controller. De robot is ook vastgebonden. Het is verbonden met de controller door middel van koperdraden die kunnen worden geïsoleerd voor bescherming. Hoewel de robot goedkoop is en in groepen kan worden gebruikt, kan hij slechts één camera ondersteunen en is de ketting zwak. Het heeft ook geen ruimte voor uitbreiding en ondersteunt geen sensoren.

Er zijn robotontwerpen die zuignappen of negatieve druk gebruiken die wordt gegenereerd door propellers om aan oppervlakken te bevestigen. De zuignappen bieden beperkte mobiliteit in vergelijking met magnetische wielen en zijn niet geschikt voor zware robots die zijn uitgerust met meerdere camera's en sensoren. Bovendien zal de zuigkracht na verloop van tijd afnemen door mechanische slijtage. Het onderdruksysteem vereist veel vermogen en constant vermogen. Als de stroom uitvalt, raakt de robot los van het oppervlak. Elk van de eerder uitgeprobeerde ontwerpen heeft zijn voor- en nadelen, maar geen enkele heeft het inspectieprobleem volledig opgelost. Dankzij het literatuuronderzoek kon ik het landschap overzien, leren wat er al eerder is geprobeerd en mijn eigen ontwerp bedenken.

1. Specificatie van vereisten

De inspectierobot zou aan een aantal beperkingen moeten voldoen. De eerste beperking voor de robot zou de grootte zijn. Een inspectierobot zou idealiter klein zijn. Sommige van de ruimtes die de robot zou inspecteren, zijn minder dan een voet in breedte en hoogte. Het formaat is in dit project beperkt tot 25x25x25 cm. Het kleinere formaat vergroot de mobiliteit en veelzijdigheid van de robot in complexe omgevingen, zoals brugbalken. Een voordeel van het kleine formaat is ook dat de robot minder stroom verbruikt en makkelijker te manipuleren is. De robot zou ook moeten worden vastgebonden. Een gekoppelde robot zou sneller en betrouwbaarder meer gegevens kunnen verzenden dan een draadloze robot.

De controller van de robot hoeft zich geen zorgen te maken dat de robot het bereik van het draadloze signaal verlaat, en zou de robot ook gemakkelijk kunnen verwijderen in geval van een ongeluk of storing. Daarnaast zou een inspectierobot meerdere camera's moeten ondersteunen voor grondige inspectie en navigatie. De live camerabeelden van de robot naar de controller zijn nodig om de robot nauwkeurig door de structuur te laten rijden die hij inspecteert en om de controller te waarschuwen voor onmiddellijke gevaren. Een andere beperking waaraan de robot moet voldoen, is dat hij op ijzerhoudende oppervlakken moet kunnen klimmen. De gemakkelijkste manier om aan die beperking te voldoen, zou zijn als de robot magnetische wielen of een magnetisch lichaam heeft, waardoor de robot gemakkelijk ijzerhoudende oppervlakken kan schalen. Dit komt omdat ferromagnetische materialen, zoals zacht staal, laaggelegeerd staal en ijzer, primaire materialen zijn bij de constructie van dergelijke constructies. Ten slotte moet de robot goedkoop zijn, bij voorkeur met een kostprijs van minder dan $ 200. Een goedkope robot is eenvoudig te vervangen en bij het inspecteren van oudere constructies zou het niet verwonderlijk zijn dat een robot beschadigd raakt. Een goedkope robot betekent ook dat er meer robots kunnen worden gekocht en voor een taak kunnen worden gebruikt, wat de inspectie-efficiëntie aanzienlijk kan verhogen.

4. Ontwerp en ontwikkeling van de robot

4.1. Prototype 1:LEGO EV3

Om een ​​robot te ontwerpen die aan de bovengenoemde beperkingen voldoet, begon ik prototypes te maken met een LEGO EV3-besturingsmodule en andere LEGO-onderdelen. Ik begon oorspronkelijk met LEGO's te werken voor prototyping omdat het gemakkelijk is om met LEGO's te bouwen en het maken van een robot vrij eenvoudig is. De EV3-module is een programmeerbare robotkern die de LEGO-robot aanstuurt en was al thuis verkrijgbaar. Met behulp van LEGO-stukken was het vrij eenvoudig om een ​​stevige robotbody te maken met 4 bevestigde motoren en wielen. Toen ik begon met de EV3, probeerde ik een plat, compact ontwerp voor mijn robot te maken. Vanwege de manier waarop LEGO-stukken in elkaar passen, begon dat idee te mislukken toen het tijd was om mijn 3 ^e te bevestigen en 4 ^de motor. Ik kon mijn motoren niet op mijn regelmodule passen. Vervolgens ging ik naar een hoekig ontwerp, waarbij de module boven de rest van mijn robot hing en de motoren uit een hoofdframe boog. Na het ontwerpen van het hoofdsteunframe, dat comfortabel onder de controller past, kon ik motorsteunen ontwerpen. De steunen waren naar beneden hellende armen die uit het hoofdframe staken en aan de motoren waren bevestigd. De motoren werden grondig vastgemaakt aan het uiteinde van de steunen om constructief falen tijdens het testen te voorkomen. Om de motoren en hun steunen verder te stabiliseren, heb ik elke motor met stijve connectoren aan de dichtstbijzijnde motor gekoppeld. De connector voorkwam ook dat de ene motor veel sneller ging dan de andere, omdat hij diende om motoren aan elkaar te koppelen en een secundair raamwerk te creëren.

Nadat ik klaar was met het structurele ontwerp en de constructie van de LEGO-robot, ging ik over naar het ontwerp van de wielen. Voor de wielen ben ik begonnen met 4 standaard EV3-wielen. Elk wiel had een straal van 17 mm en een breedte van 17 mm. Elk wiel werd bovendien geleverd met een aangehechte, holle, rubberen band. Om de wielen te configureren voor magnetische beweging, begon ik met het verwijderen van de banden. Na het verwijderen van de banden bleef alleen het kale plastic wiel over. Het plastic had sprookjesachtige inkepingen, die consequent het grootste deel van het wiel bedekten. Door de inkepingen kon ik de magneten niet direct op de wielen bevestigen. De magneten die ik gebruikte voor de LEGO-robot waren D51-N52-schijven van K&J Magnetics ⁶ . D51-N52 magneten zijn neodymium-ijzer-borium (NdFeB) schijfmagneten met een diameter van 5/16” (8 mm) en een dikte van 1/16”

(1,6mm). Ik koos ervoor om die magneten te gebruiken omdat ze klein genoeg waren om een ​​ketting om het wiel te kunnen wikkelen en een magnetische band te creëren. Elke D51-N52 heeft een trekkracht van 2,05 lb (9,1 Newton) wanneer deze rechtstreeks op een stalen plaat wordt geplakt. Met vier wielen in de magneten gewikkeld, zou het magnetisme meer dan voldoende zijn om de LEGO-robot op te houden, die wordt weergegeven in figuur 1.

Ik heb methoden getest om magneten aan de wielen van mijn robot te bevestigen. Ik heb oorspronkelijk geprobeerd een papier om het wiel te wikkelen en magneten op dat papier te lijmen. Dat idee werkte niet omdat het papier te zwak was om een ​​stevig oppervlak voor de magneten te bieden, en niet

sterk genoeg om te voorkomen dat de magneten samenklonteren en het wiel verlaten. Vervolgens probeerde ik de gaten in de wielen te vullen met klei of playdoh en er magneten over te bevestigen. Dit idee mislukte ook omdat geen van beide materialen aan superlijm zou blijven kleven. Nadat geen van beide ideeën werkte, experimenteerde ik om te zien of een hybride van de twee ideeën zou werken. Ik vulde de inkepingen in het wiel met gevouwen en samengedrukte stroken papier. Vervolgens heb ik de strips op hun plaats gelijmd.

Daarna wikkelde ik papier dat was gevouwen en verstevigd met dunne draadjes metaal rond het wiel. Het versterkte papier was een stevig maar flexibel genoeg oppervlak voor mij om magneten te superlijmen. Nadat ik magneten met succes op alle vier de wielen had bevestigd, omwikkelde ik elk wiel met ducttape in plaats van een band te gebruiken. De reden dat ik ervoor koos geen band te gebruiken, was dat een band de trekkracht van de magneten te veel zou verminderen vanwege de dikte, terwijl ducttape de trekkracht niet significant zou verminderen en toch tractie zou bieden. Nadat ik de wielen had omwikkeld, liet ik een LEGO-as door elk wiel lopen en gebruikte het om elk wiel aan mijn motoren te bevestigen.

De bevestiging van de wielen betekende het einde van de ontwikkeling van mijn eerste prototype. Ik heb het prototype getest door het tegen een stalen deur te drukken. De robot kon stevig aan de deur blijven plakken zonder uit te glijden. De robot voldeed niet aan verschillende ontwerpbeperkingen:hij was groter dan 25x25x25 cm, kostte meer dan $200, was niet vastgebonden, vereiste batterijen en ondersteunde geen camera's.

Dit eerste prototype voldeed echter aan een belangrijke doelstelling. Het echte doel van mijn eerste prototype was om me te helpen begrijpen hoe ik een robot efficiënt met magneten aan een ijzerhoudend oppervlak kon bevestigen, en me te helpen begrijpen hoe ik een robot en wielen moest ontwerpen om het inspectieprobleem op te lossen.

4.2     Materiaal- en componentselectie voor het tweede prototype

Nadat ik mijn eerste prototyperobot met LEGO's had gebouwd, besloot ik componenten te selecteren en mijn volgende prototype op de computer te ontwerpen en te visualiseren voordat ik met de bouw begon. Eerst besloot ik dat ik een Raspberry Pi zou gebruiken als de kern van mijn toekomstige prototypes. De reden dat ik voor de Raspberry Pi koos, was dat de Pi een redelijk krachtige printplaat is, ondanks dat hij erg licht en compact is. De Pi kan verbinding maken met motorbesturingskaarten, terwijl hij nog steeds USB- en Ethernet-mogelijkheden heeft. Bovendien is de Pi een zeer goedkope computer en wordt hij geleverd met een gratis OS-pakket. Afbeelding 2 is een foto van de Raspberry Pi 3.

Vervolgens besloot ik de L298N-motorbesturingskaart te gebruiken om mijn motoren te besturen. De L298N is een vrij eenvoudige motorcontroller die tot 2 gelijkstroommotoren kan aansturen. Er is gedocumenteerd dat de motorcontroller spanningen tot 35 V aankan. Aangezien de meeste motoren die ik wilde gebruiken in het bereik van 6 V-12 V zaten, was de L298N ideaal voor mij. Het bord zelf is vrij klein, slechts een derde van de grootte van een Raspberry Pi. Door deze eenvoud is het gemakkelijk om meerdere L298N’s tegen lage kosten aan te schaffen. Ik besloot ook dat ik zou beginnen met een enkele camera voor mijn eerste prototype met de Raspberry Pi. De camera die ik heb gekozen om te gebruiken, is de Raspberry Pi NoIR-camera.

Deze NoIR-camera is een Pi-compatibele camera die is ontworpen voor nachtzicht. Terwijl constructies zoals bruggen verlicht kunnen zijn, zal het interieur van tanks waarschijnlijk donker zijn; dus koos ik de Pi NoIR-camera in plaats van de standaard Pi-camera. Ik heb ook voor de NoIR-camera gekozen omdat deze is gebouwd voor de Raspberry Pi en gemakkelijker te gebruiken zou zijn dan welke andere camera dan ook.

Voor mijn motoren heb ik gekozen voor standaard 6 V DC plastic Arduino-motoren. Ik koos deze motoren, ook al waren het Arduino-motoren, omdat ik wist dat mijn driverboard elke gelijkstroommotor binnen zijn spanningslimiet kon laten draaien. Ik heb een technische mechanische berekening gemaakt, zoals hieronder besproken, om het benodigde motorkoppel te schatten. De plastic motoren zijn zeer gemakkelijk te gebruiken en te bedraden, en zijn ook goedkoop. Als een van de motoren kapot gaat, is deze eenvoudig te vervangen door een nieuwe motor. De motoren worden ook geleverd met plastic wielen die groot genoeg zijn om de robot te ondersteunen en te verplaatsen, maar klein genoeg om gemakkelijk te kunnen worden bestuurd. Naast mijn twee aandrijfmotoren wilde ik een andere motor gebruiken om een ​​hefboommechanisme onder de robot te creëren dat hem zou kunnen ondersteunen. Het mechanisme zou worden gebruikt om de voorkant van de robot van de grond te tillen, zodat deze beter op een ijzerhoudend oppervlak kan worden bevestigd. Ik was van plan de robot op een eenvoudig plastic robotchassis te monteren en metalen strips te gebruiken om een ​​verhoogd platform te vormen voor elk onderdeel dat niet op het chassis zelf kon worden ondergebracht. Ik besloot de L298N's van stroom te voorzien met een 4-AA-batterijpak of twee 2-AA-batterijen. De Raspberry Pi is ontworpen om stroom te ontvangen van een USB-kabel die zich uitstrekte tot een stopcontact. De robot zou worden bestuurd door een bedrade Xbox 360-controller die erop is aangesloten via een USB-kabel. Ik besloot een Xbox-controller te gebruiken omdat deze een richtingspad heeft, wat ideaal zou zijn om de beweging van de robot te regelen. Het heeft ook extra knoppen die kunnen worden toegewezen aan verschillende taken binnen de code van de robot, zoals camerabediening. Voor de magneten besloot ik D51-N52-magneten te blijven gebruiken omdat ik had bewezen dat het gebruik ervan om een ​​magnetische band rond een wiel te maken een haalbare methode was om een ​​magnetisch wiel te maken met mijn eerste prototype.

4.3    Computer Aided Design (CAD) van het tweede prototype

Nadat ik had besloten welke materialen en componenten ik zou gebruiken om mijn 2 ^de . te maken prototype, ging ik verder met het maken van een CAD-tekening van mijn prototype, zodat ik het gemakkelijk zou kunnen bouwen zodra de onderdelen die ik had gespecificeerd waren aangekomen. Om de CAD-tekeningen te maken, gebruikte ik een software genaamd SketchUp, omdat de software gratis was, gemakkelijk zelf te leren en gemakkelijk te gebruiken. Met behulp van online en fysieke metingen (zodra de onderdelen zijn aangekomen) van de onderdelen die ik van plan was te gebruiken om mijn 2 ^de te maken prototyperobot, kon ik een realistische 3D CAD-tekening van mijn robotprototype maken, zoals weergegeven in figuur 3. Vervolgens heb ik mijn prototype verder verfijnd, rekening houdend met de optimale schroeflocaties. Na een paar iteraties van het toevoegen van ontwerpkenmerken en het verfijnen van de details, kon ik een bevredigend 3D-model van mijn robot krijgen. Dit diende om het hardwaregedeelte van mijn project te vereenvoudigen, omdat ik gewoon een fysieke kopie van het computermodel moest maken met behulp van echte onderdelen.

4.4   Prototype 2a:kant-en-klaar chassis

Prototype 2a bouwen

Nadat al mijn onderdelen waren aangekomen en mijn CAD-tekeningen klaar waren, was het bouwen van mijn robot een eenvoudige zaak. Bij het bouwen van de robot begon ik met het boren van gaten voor de Raspberry Pi om op te monteren. Om de punten in kaart te brengen die ik op het plastic chassis zou boren, hield ik de Pi op de achterkant van het chassis en gebruikte een dun potlood om het gebied onder elk schroefgat op het chassis te markeren. Ik heb toen een boor gekozen die iets groter was dan de schroefgaten op de Pi om elk gat mee te boren. Vervolgens heb ik op dezelfde manier gaten geboord aan de voorkant van het chassis om plaats te bieden aan het bestuurdersbord. Om het driverbord en de Raspberry Pi te monteren, heb ik #4-40 bouten en moeren gebruikt. Nadat ik beide planken had gemonteerd, gebruikte ik de meegeleverde schroeven om het achterwiel te bevestigen en

motoren om gaten in het chassis voor te snijden. Het chassis, de motoren en het achterwiel kwamen samen met moeren, bouten en instructies, dus het bevestigen van beide componenten aan het chassis was eenvoudig.

Voor dit prototype heb ik zware dubbelzijdige tape gebruikt om een ​​derde motor aan de onderkant van de robot te bevestigen, direct tussen beide aandrijfmotoren. Ik nam toen vier ijslollystokjes en plakte ze in de lengte aan elkaar in sets van twee. Als resultaat kreeg ik twee hele dikke ijslollystokjes. Ik sneed toen de ijslollystokjes doormidden en schetste het uiteinde van de motoras aan het uiteinde van elke halve ijslollystokjes. Vervolgens heb ik een boor gebruikt om een ​​gat te maken in elk van de nieuwe stokken waar de motoras in zou passen. Als resultaat kreeg ik 4 dikke, halflange, geboorde ijslollystokjes. Ik koos toen de twee stokken die het beste pasten en bevestigde ze aan elk uiteinde van de as op de middelste motor. Ik heb de ijslollystokjes vastgezet met hete lijm. Het doel van dit gemotoriseerde apparaat was om te dienen als een lifter die de robot van het oppervlak zou duwen waarop hij zich bevond zodra de motor was geactiveerd. Dit apparaat is ontworpen om de robot in staat te stellen zichzelf los te maken van een ijzerhoudend oppervlak. Het zou de robot ook in staat stellen om zijn belangrijkste magnetische wielen van de grond te tillen, zodat hij zich vanaf een ander oppervlak aan een ijzerhoudende muur zou kunnen hechten. Dit is een van de vele unieke ontwerpkenmerken van dit project. Het ontwerp van het magnetische wiel is een ander innovatief kenmerk.

Nadat ik de derde motor had bevestigd, gebruikte ik geperforeerde metalen hangertape om brugachtige structuren boven het driverbord en Raspberry Pi te creëren. De ophangband diende als secundair oppervlak waarop extra onderdelen konden worden gemonteerd. Door de perforaties was het gemakkelijk om gaten in het chassis te boren om de metalen ophangband te passen en deze vast te zetten met overgebleven bouten en moeren. Bovenop de ophangbandbrug aan de voorkant van de robot heb ik een tweede driverbord bevestigd om de derde motor te besturen, aangezien elk bord slechts twee motoren kan besturen. Ik heb het bestuurdersbord met dubbelzijdig plakband kunnen bevestigen. Met meer dubbelzijdig plakband kon ik een 4-AA-batterijhouder aan de bovenkant van de achterste metalen hangar bevestigen om het hoofdbestuurdersbord van stroom te voorzien. Ik heb ook twee 2-AA-batterijhouders aan de voorkant van mijn robot bevestigd om het tweede bestuurdersbord van stroom te voorzien.

Ik heb dit tweede prototype afgemaakt door de Raspberry Pi NoIR-camera warm te lijmen aan de voorkant van de metalen ophangbandbrug. Nadat de robot was gebouwd, hoefden we alleen nog maar de wielen te magnetiseren. Ik verwijderde de banden van de wielen en legde een laag dubbelzijdig plakband over elk wiel. De plastic wielen en motoren worden getoond in figuur 4. Ik heb de kleine ronde D51-N52-magneten in een cirkel rond de rand van elk wiel geplakt, zodat er twee ringen op elk wiel zaten. Nadat ik alle magneten had toegevoegd, bedekte ik beide wielen met een enkele laag ducttape om de magneten te beschermen. Om het achterwiel te magnetiseren, heb ik magneten in een ring rond het wiel warmgelijmd en vervolgens in ducttape gewikkeld. De reden dat ducttape werd gebruikt, was omdat het dun genoeg is om de trekkracht niet significant te verminderen, maar sterk genoeg om de magneten te beschermen.

Bedradingsprototype 2a

Nadat ik alle componenten van mijn robot had bevestigd, begon ik ze aan elkaar te bedraden. De stroom voor de Raspberry Pi kwam binnen via de micro-USB-poort aan zijn kant. Vervolgens heb ik de batterijpakketten aangesloten op hun respectieve bestuurdersborden. De motoren waren ook verbonden met de driverborden met behulp van draden die bij de motoren waren geleverd. Ik soldeerde de draden aan de stroomkabels op de motor en verbond ze met schroeven aan het driverbord. Vervolgens heb ik de GPIO-pinnen op de Pi aangesloten op de driverborden. De GPIO-pinnen zijn invoer-/uitvoerpinnen voor algemene doeleinden op de Raspberry Pi. Sommige pinnen worden gebruikt voor aarde en voeding, terwijl andere kunnen worden gebruikt om signalen door een draad te sturen. Ik heb GPIO 2 &6 aangesloten op de ene driverkaart en 4 &9 op de andere driverkaart. Die pinnen waren 5 V-pinnen en werden gebruikt om motorbewegingen en controle via de driverboards mogelijk te maken. Vervolgens heb ik pin 11, 12, 13 en 15 aangesloten op de eerste driverkaart en pinnen 16 en 18 op de andere driverkaart. Die pinnen werden gebruikt voor het verzenden van het eigenlijke motorbesturingssignaal. Elke motor

vereiste twee pinnen voor besturing, en aangezien de robot 3 motoren gebruikte, hadden de driverkaarten 6 aangesloten signaal-GPIO-pinnen nodig voor motorbesturing, naast een 5V en aarde per bord. Nadat ik de benodigde GPIO-pinnen had aangesloten, heb ik een Ethernet-kabel aangesloten tussen mijn Pi en mijn laptop, zodat mijn laptop een externe desktopverbinding met mijn Raspberry Pi zou kunnen hebben, waardoor er geen monitor, toetsenbord en muis meer nodig zijn. Ik heb ook een powered hub via USB op mijn Pi aangesloten. De hub was verbonden met een Xbox-controller, zodat ik de robot via de Xbox-controller zou kunnen besturen.

Prototype 2a programmeren

Het moeilijkste aan het ontwerpen van mijn 2 ^de prototype was de code. Bij mijn eerste prototype was het slechts een hardwaremodel; het liep geen code. Mijn reden hiervoor is, met mijn 1 ^e prototype, hoe ik ook probeerde, ik was niet in staat om alle 4 motoren tegelijkertijd met code te laten bewegen. Het eerste prototype is ook voornamelijk gemaakt om het magnetische wielconcept te testen en om mij te helpen een ideaal ontwerp te bedenken voor toekomstige prototypes. Op de Raspberry Pi heb ik gecodeerd met Python, omdat het de enige taal voor de Raspberry Pi was die ik begreep. Maar zelfs voordat ik aan mijn code begon, moest ik mijn robot instellen om remote desktop compatibel te maken met mijn laptop.

Om mijn Pi in te stellen, moest ik tijdelijk een monitor, toetsenbord en muis op de Raspberry Pi aansluiten. Daarna startte ik de Pi op en stelde er een statisch IP voor in via Ethernet. Ik koos 192.168.1.10 omdat het een eenvoudig en gemakkelijk adres was. Om het IP-adres in te stellen moest ik bewerken

/ect/dhcpcd.conf in mijn Pi. Het dhpcd.conf-bestand bestuurt de IP- en netwerkverbinding van de Pi; om een ​​statisch IP-adres in te stellen moest ik de regels aan het begin van het bestand toevoegen:

interface eth0

statisch ip_address=192.168.1.10 statische routers=192.168.1.1

Nadat ik het statische IP-adres van de Pi had ingesteld, installeerde ik het Linux-pakket tightvncserver. Tightvncserver is een pakket waarmee een VNC-server (virtual network connection) op de Raspberry Pi kan worden opgezet. Remote Desktop-verbindingen worden uitgevoerd via VNC-servers. Nadat ik de VNC-server had ingesteld, kon ik een Remote Desktop-verbinding met mijn Raspberry Pi maken via mijn

laptop. Nadat ik had bevestigd dat ik toegang had tot mijn Pi, heb ik mijn monitor, toetsenbord en muis losgekoppeld. Ik begon toen met het coderen voor de robot.

Eerst had ik een manier nodig om erachter te komen welke GPIO-pin overeenkwam met welke motor op mijn Pi. Elke GPIO-pin draait, wanneer geactiveerd, een enkele motor vooruit of achteruit met een constante snelheid. Elke motor heeft dus twee corresponderende GPIO-pinnen, een voorwaartse bewegingscontroller en een achterwaartse bewegingscontroller. Om erachter te komen waarmee elke GPIO-pin overeenkwam, schreef ik een programma dat elke GPIO-pin afzonderlijk testte, zodat ik zou kunnen noteren welke GPIO-pin wat deed. Ik heb mijn observaties vastgelegd door middel van opmerkingen over mijn programma:

importeer RPi.GPIO als GPIO van time import sleep

GPIO.setmode(GPIO.BOARD)

GPIO.setup(12,GPIO.OUT) #Links achteruit GPIO.setup(11,GPIO.OUT) #Links vooruit GPIO.setup(13,GPIO.OUT) #Rechts vooruit GPIO.setup(15,GPIO.OUT) # Rechts achteruit GPIO.setup (16,GPIO.OUT) #Lifter uit GPIO.setup(18,GPIO.OUT) #Lifter in

GPIO.output (12,GPIO.HIGH)

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

slaap(1)

GPIO.output (11,GPIO.HIGH)

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

slaap(1)

GPIO.output(13,GPIO.HIGH)

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

slaap(1)

GPIO.output (15,GPIO.HIGH)

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

slaap(1)

GPIO.output (16,GPIO.HIGH)

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

slaap(1)

GPIO.output (18,GPIO.HIGH)

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

slaap(1)

Vervolgens had ik software of code nodig waarmee mijn Raspberry Pi signalen kan ontvangen en begrijpen die door de Xbox-controller worden verzonden. Xboxdrv is een Xbox-controllerstuurprogramma voor Linux. Ik heb het geïnstalleerd en gebruikt om te proberen mijn Pi op mijn Xbox-controller aan te sluiten. Normaal gesproken geeft het uitvoeren van de opdracht 'sudo xboxdrv' in de prompt de ingangen van de aangesloten Xbox-controller weer in het opdrachtpromptvenster. Mijn Xbox-controller is echter niet gemaakt door Microsoft, dus het werd niet normaal ondersteund door xboxdrv. Ik heb het probleem opgelost door de opdracht uit te voeren:

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

Ik kon deze opdracht maken nadat ik had onderzocht hoe ik xboxdrv moest gebruiken en hoe ik de normale functie met code kon wijzigen. Met deze opdracht identificeerde ik de aangesloten controller als een Xbox-controller met behulp van de apparaat-ID die 1bad:f02e was. Met deze opdracht kon ik de invoer van de controller in de opdrachtprompt bekijken. Ik had een manier nodig om toegang te krijgen tot de invoerwaarden van een

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