Conception et développement d'un robot d'inspection à faible coût

1. Présentation

L'infrastructure de notre pays vieillit et se détériore rapidement. À l'heure actuelle, il n'existe aucun mécanisme pour inspecter en profondeur l'état de nos ponts, réservoirs de déchets, pipelines et réacteurs. Bon nombre de ces structures ont atteint la fin de leur durée de vie nominale et doivent être inspectées pour déceler toute détérioration. À l'instar de cette situation à terre, il est également nécessaire d'inspecter les coques et les ponts des navires et des pétroliers de l'US Navy à la recherche de signes de corrosion. De nombreuses structures anciennes, telles que les ponts hauts et les réservoirs de déchets, sont souvent difficiles à sonder ou à inspecter pour une multitude de raisons. La raison la plus courante est que le processus d'inspection est dangereux pour l'homme ou que la structure comporte des sections inaccessibles. Une autre raison courante est que la technologie actuelle des sondes peut être inadéquate pour inspecter avec précision de telles structures. Ainsi, l'inspection manuelle est peu fréquente, laborieuse, coûteuse, dangereuse et sujette aux erreurs. Ce problème offre une opportunité parfaite pour un robot d'inspection bien fait.

Les robots d'inspection sont généralement conçus et développés par de grandes équipes bien financées d'ingénieurs électriciens et mécaniciens. Les robots commerciaux, tels que le Packbot 510 (http://endeavorrobotics.com/products), peuvent coûter plus de 100 000 $. Compte tenu des contraintes d'un projet d'expo-sciences individuel, la portée ici est de concevoir, développer et tester un prototype peu coûteux pour un robot d'inspection. Le but de ce projet est de développer un prototype de robot d'inspection petit, léger et peu coûteux qui peut rester attaché aux surfaces à inspecter. Le projet comprend les tâches suivantes :revue de la littérature et des conceptions existantes; spécification des exigences; conception de robots; développement du prototype initial et essais ; calculs de mécanique d'ingénierie; programmer le robot à l'aide de Python ; développement et test du deuxième prototype; et développement et test du prototype final.

Avant de construire physiquement le robot, le logiciel de modélisation 3D SketchUp a été utilisé pour visualiser le robot et affiner la conception. Le robot a été construit à partir de composants commerciaux standard, y compris un module Raspberry Pi 3 pour contrôler le robot. La conception a été améliorée de manière itérative grâce à des tests répétés. Le code Python a été écrit à partir de zéro pour programmer le robot. Au fur et à mesure de l'évolution de la conception, le matériel et le logiciel ont dû être modifiés en tandem. Le prototype a été présenté à des experts en ingénierie de Washington River Protection Solutions et du Pacific Northwest National Laboratory, ainsi qu'à la classe de conception senior de l'État de Washington

Université, Tri Cities. Sur la base des commentaires des experts, des calculs de mécanique d'ingénierie et des résultats des tests, le troisième prototype a été construit et programmé. Le robot résultant est capable d'escalader les murs à une vitesse raisonnable et dispose de plusieurs caméras pour faciliter la navigation et l'inspection. Le robot produit par ce projet représente une conception unique avec un logiciel écrit spécifiquement à cet effet. Ce prototype sert de plate-forme flexible dans la mesure où de nouveaux capteurs peuvent être ajoutés au besoin pour augmenter les capacités d'inspection.

2. Revue de la littérature

Avant de commencer à travailler sur le projet, j'ai effectué une revue de la littérature pour évaluer les solutions existantes. Les sondes actuellement disponibles peuvent être classées en deux types :fixes et mobiles.

Les sondes fixes sont l'outil le plus largement utilisé pour inspecter les structures. Ils fournissent des informations très détaillées sur une section particulière d'une structure et peuvent la surveiller en permanence. Cependant, une fois qu'ils sont positionnés dans un endroit, la plage d'observation sera limitée. En raison du manque de mobilité, ils sont inadaptés à la surveillance de grandes structures. L'autre catégorie est constituée de sondes montées sur robot. Ceux-ci offrent un plus grand degré de fonctionnalité car la sonde peut être déplacée librement. La plupart des robots actuellement sur le marché sont très spécialisés dans une tâche ou un type d'inspection spécifique. Certains robots peuvent se spécialiser dans la traversée de l'eau, des hautes altitudes ou des terrains marécageux semi-solides, mais aucun de ces robots n'est utile pour l'inspection structurelle.

Le robot d'inspection aquatique AQUA ¹ est un excellent exemple. AQUA est un robot d'inspection hautement spécialisé et coûteux. Il rampe sur le lit des plans d'eau et effectue des scans en 3 dimensions (3D) de sa zone. Il est capable d'utiliser des caméras, des analyses de capteurs et des algorithmes pour suivre un chemin désigné sous l'eau. Bien qu'il s'agisse d'un robot d'inspection, il est inutile pour l'inspection structurelle, car il n'a pas la capacité de grimper sur des surfaces ferreuses.

Un autre exemple est l'AETOS ² drone aérien. Le drone AETOS est un quadricoptère utilisé pour l'arpentage, la cartographie du paysage et les interventions d'urgence. Le robot lui-même est un quadricoptère téléguidé qui suspend une caméra haute puissance. La caméra est capable de capturer et d'enregistrer des images et des vidéos détaillées de structures et de paysages. Le drone AETOS est polyvalent dans son utilisation et peut même inspecter des structures exposées telles que des ponts depuis les airs. L'inconvénient du drone est qu'il n'est pas idéal pour les inspections structurelles détaillées, car le vent peut déplacer le drone pendant qu'il est au milieu d'une inspection. Le drone n'est pas non plus utilisable dans des structures fermées, car il risque de s'écraser. Le drone AETOS nécessite une charge fréquente et ne peut pas rester dans les airs pendant de longues périodes. Il est également coûteux, sujet aux dommages et difficile à récupérer après un accident.

Certains des robots actuellement disponibles contiennent des capteurs puissants, plusieurs caméras et des capacités d'escalade. De tels robots sont extrêmement coûteux et ne peuvent pas être déployés en grand nombre pour effectuer des inspections. Les risques de dommages liés à ces robots et les coûts de remplacement sont également très élevés. Les dommages sont une considération très réelle, car pratiquement tous les robots utilisés pour inspecter les réacteurs nucléaires endommagés sur le site de Fukushima Daiichi au Japon ont échoué en mars 2017. Un exemple de robot coûteux est le MagneBike ³ . . Le MagneBike est un robot assez récent qui n'est pas encore commercialisé mais qui est actuellement en test et en développement privé. Le MagneBike est un vélo robotisé qui comporte deux roues reliées à un corps principal par une articulation libre. Cette articulation permet au robot de se déplacer librement sur n'importe quelle surface ferreuse quels que soient les contours. Chaque roue a également deux leviers fixés sur ses côtés et ressemble à des roues d'entraînement. La longueur de chaque levier est légèrement supérieure au rayon de chaque roue. Les leviers sont utilisés pour dissocier la roue de la surface magnétique à laquelle elle est connectée, lui permettant de se déplacer en douceur sur les angles intérieurs. Le MagneBike peut être configuré pour prendre en charge une caméra haute définition et prend en charge un capteur de cartographie 3D, qui lui permet de créer un modèle 3D de son environnement. Le robot est contrôlé et alimenté par un câble et est un dispositif attaché pour une récupération facile. Cependant, l'inconvénient du MagneBike est qu'il est très difficile à remplacer s'il est cassé et qu'il est assez coûteux si les pièces utilisées sont de qualité.

Un robot à roues magnétiques similaire est le robot magnétique multi-segment de l'US Navy ⁴ (MADAME MONSIEUR). Le MSMR est un robot naval conçu pour l'inspection de la coque des navires. Bien que le MSMR ne soit pas conçu pour l'inspection des structures en surface, il pourrait être facilement adapté pour inspecter les structures. Aussi, inspecter la coque d'un navire et inspecter une structure industrielle ne sont pas des tâches différentes. Le MSMR est un robot à 3 segments, chaque segment étant une boîte métallique contenant de l'électronique, avec deux roues fixées sur ses côtés. Les segments sont reliés par des connecteurs flexibles ou articulés.

Chaque roue peut fonctionner indépendamment et le robot est capable d'escalader facilement des obstacles 3D lorsque toutes les roues fonctionnent ensemble. Les roues sont aimantées et peuvent supporter le robot. Les inconvénients du robot sont qu'il n'a pas d'attache et n'est donc alimenté que par une batterie. Ceci est désavantageux, car cela rend le robot beaucoup plus difficile à contrôler et limite la durée de vie d'inspection du robot. Le MSMR est également actuellement inédit et utilisé uniquement par la Marine. Le robot le restera probablement dans un avenir prévisible.

Un autre exemple de robot d'inspection est le Microbot d'escalade murale omnidirectionnel ⁵ . Le Microbot est un minuscule robot circulaire pesant seulement 7,2 grammes. Il a un diamètre de 26 mm et une hauteur de 16,4 mm. Le bot est actuellement en phase finale de test et n'est pas encore disponible dans le commerce. Le robot prend en charge 3 micromoteurs à roues magnétiques avec une capacité de rotation à 360 °. Les roues lui permettent de traverser facilement la plupart des surfaces ferreuses. Le Microbot peut être configuré pour prendre en charge une seule micro caméra. La caméra peut renvoyer des images et des vidéos simples au contrôleur. Le robot est également attaché. Il est relié à son contrôleur par des fils de cuivre qui peuvent être isolés pour la protection. Bien que le robot soit peu coûteux et puisse être utilisé en groupe, il ne peut prendre en charge qu'une seule caméra et l'attache est faible. Il manque également de place pour l'extension et ne peut prendre en charge aucun capteur.

Il existe des conceptions de robots qui utilisent des ventouses ou une pression négative générée par des hélices pour se fixer aux surfaces. Les ventouses offrent une mobilité limitée par rapport aux roues magnétiques et ne conviennent pas aux robots lourds équipés de plusieurs caméras et capteurs. De plus, la puissance d'aspiration va se dégrader avec le temps en raison de l'usure mécanique. Le système à pression négative nécessite une puissance considérable et une puissance constante. En cas de coupure de courant, le robot se détachera de la surface. Chacune des conceptions qui ont été essayées auparavant a ses avantages et ses inconvénients, mais aucune n'a complètement résolu le problème de l'inspection. La revue de la littérature m'a permis d'étudier le paysage, d'apprendre ce qui a été essayé auparavant et de proposer mon propre design.

1. Spécification des exigences

Le robot d'inspection devrait répondre à plusieurs contraintes. La première contrainte sur le robot serait la taille. Un robot d'inspection serait idéalement petit. Certains des espaces que le robot inspecterait ont moins d'un pied de largeur et de hauteur. La taille est limitée dans ce projet à 25x25x25 cm. La plus petite taille augmente la mobilité et la polyvalence du robot dans des environnements complexes, tels que les poutres de pont. Un avantage de la petite taille est également que le robot consommera moins d'énergie et sera plus facile à manipuler. Le robot devrait également être attaché. Un robot captif serait capable d'envoyer plus de données plus rapidement et de manière plus fiable qu'un robot sans fil.

Le contrôleur du robot n'aurait pas à se soucier du fait que le robot quitte la portée du signal sans fil, et serait également capable d'extraire facilement le robot en cas d'accident ou de panne. De plus, un robot d'inspection devrait prendre en charge plusieurs caméras pour une inspection et une navigation approfondies. Les images de la caméra en direct du robot au contrôleur seraient nécessaires pour que le robot soit conduit avec précision à travers la structure qu'il inspecte et pour avertir le contrôleur des dangers immédiats. Une autre contrainte que le robot devrait respecter est qu'il devrait être capable de grimper sur des surfaces ferreuses. Le moyen le plus simple de répondre à cette contrainte serait que le robot ait des roues magnétiques ou un corps magnétique permettant ainsi au robot de mettre à l'échelle des surfaces ferreuses avec facilité. En effet, les matériaux ferromagnétiques, tels que l'acier doux, l'acier faiblement allié et le fer, sont des matériaux primaires dans la construction de telles structures. Enfin, le robot doit être peu coûteux, de préférence avec un coût inférieur à 200 $. Un robot bon marché est facile à remplacer, et lors de l'inspection de structures plus anciennes, il ne serait pas surprenant qu'un robot soit endommagé. Un robot bon marché signifie également que davantage de robots peuvent être achetés et utilisés pour une tâche, ce qui peut augmenter considérablement l'efficacité de l'inspection.

4. Conception et développement du robot

4.1. Prototype 1 :LEGO EV3

Afin de concevoir un robot répondant aux contraintes énoncées ci-dessus, j'ai commencé le prototypage avec un module de commande LEGO EV3 et d'autres pièces LEGO. J'ai commencé à travailler avec des LEGO pour le prototypage car il est facile de construire avec des LEGO et la création d'un robot est assez simple. Le module EV3 est un noyau de robot programmable qui contrôle le robot LEGO et était déjà disponible à la maison. En utilisant des pièces LEGO, il était assez facile de créer un corps de robot robuste avec 4 moteurs et roues attachés. Lorsque j'ai commencé avec l'EV3, j'ai essayé de créer un design plat et compact pour mon robot. En raison de la façon dont les pièces LEGO s'emboîtent, cette idée a commencé à échouer quand est venu le temps d'attacher mon 3 ^ème et 4 ^ème moteur. Je n'ai pas pu installer mes moteurs sur mon module de commande. Ensuite, je suis passé à une conception angulaire, avec le module suspendu au-dessus du reste de mon robot et les moteurs se cambrant à partir d'un châssis principal. Après avoir conçu le cadre de support principal, qui s'adapte confortablement sous le contrôleur, j'ai pu concevoir des supports de moteur. Les supports étaient des bras inclinés vers le bas qui dépassaient du cadre principal et étaient attachés aux moteurs. Les moteurs ont été soigneusement épinglés à l'extrémité des supports pour éviter une défaillance structurelle pendant les tests. Pour stabiliser davantage les moteurs et leurs supports, j'ai relié chaque moteur au moteur le plus proche avec des connecteurs rigides. Le connecteur empêchait également un moteur d'aller beaucoup plus vite que les autres, car il servait à relier les moteurs entre eux et à créer un cadre secondaire.

Après avoir terminé la conception structurelle et la construction du robot LEGO, je suis passé à la conception des roues. Pour les roues, j'ai commencé avec 4 roues EV3 de taille standard. Chaque roue avait un rayon de 17 mm et une largeur de 17 mm. Chaque roue était en outre livrée avec un pneu en caoutchouc creux attaché. Pour configurer les roues pour un mouvement magnétique, j'ai commencé par retirer les pneus. Après avoir enlevé les pneus, il ne restait que la roue en plastique nue. Le plastique avait de profondes empreintes de fée, qui couvraient systématiquement la majeure partie de la roue. En raison des indentations, je n'ai pas pu attacher directement les aimants aux roues. Les aimants que j'ai utilisés pour le robot LEGO étaient des disques D51-N52 de K&J Magnetics ⁶ . Les aimants D51-N52 sont des disques magnétiques en néodyme-fer-bore (NdFeB) qui ont un diamètre de 5/16" (8 mm) et une épaisseur de 1/16"

(1,6 millimètres). J'ai choisi d'utiliser ces aimants car ils étaient suffisamment petits pour que je puisse en enrouler une chaîne autour de la roue et créer une bande magnétique. Chaque D51-N52 a une force de traction de 2,05 lb (9,1 Newton) lorsqu'il est collé directement sur une plaque d'acier. Avec quatre roues enveloppées dans les aimants, le magnétisme serait plus que suffisant pour soutenir le robot LEGO, illustré à la figure 1.

J'ai testé des méthodes de fixation d'aimants sur les roues de mon robot. Au départ, j'ai essayé d'enrouler un papier autour de la roue et de super-coller des aimants sur ce papier. Cette idée n'a pas fonctionné car le papier était trop faible pour fournir une surface ferme pour les aimants, et n'était pas

assez fort pour empêcher les aimants de s'agglutiner et de quitter la roue. Ensuite, j'ai essayé de remplir les trous des roues avec de l'argile ou du playdoh et d'y attacher des aimants. Cette idée a également échoué car aucun des deux matériaux ne collerait à la superglue. Après qu'aucune des idées n'ait fonctionné, j'ai expérimenté pour voir si un hybride des deux idées fonctionnerait. J'ai rempli les empreintes de la roue avec des bandes de papier pliées et compressées. J'ai ensuite super collé les bandes en place.

Ensuite, j'ai enveloppé du papier plié et renforcé par de minces brins de métal autour de la roue. Le papier renforcé était une surface suffisamment solide mais flexible pour que je puisse supercoller des aimants. Après avoir fixé avec succès des aimants sur les quatre roues, j'ai enveloppé chaque roue avec du ruban adhésif au lieu d'utiliser un pneu. La raison pour laquelle j'ai choisi de ne pas utiliser de pneu était qu'un pneu réduirait trop la force de traction des aimants en raison de son épaisseur, tandis que le ruban adhésif ne réduirait pas considérablement la force de traction tout en offrant une traction. Après avoir enveloppé les roues, j'ai fait passer un axe LEGO dans chaque roue et je l'ai utilisé pour attacher chaque roue à mes moteurs.

La fixation des roues a marqué la fin du développement de mon premier prototype. J'ai testé le prototype en le pressant contre une porte en acier. Le robot a pu se coller fermement à la porte sans glisser. Le robot ne répondait pas à plusieurs contraintes de conception :il mesurait plus de 25 x 25 x 25 cm, coûtait plus de 200 $, n'était pas attaché, nécessitait des piles et ne prenait pas en charge les caméras.

Cependant, ce prototype initial a atteint un objectif clé. Le véritable objectif de mon premier prototype était de m'aider à comprendre comment attacher un robot à une surface ferreuse efficacement avec des aimants, et de m'aider à comprendre comment concevoir un robot et des roues pour résoudre le problème d'inspection.

4.2     Sélection des matériaux et des composants pour le deuxième prototype

Après avoir construit mon premier prototype de robot avec des LEGO, j'ai décidé de sélectionner des composants, de concevoir et de visualiser mon prochain prototype sur ordinateur avant de commencer la construction. Tout d'abord, j'ai décidé d'utiliser un Raspberry Pi comme cœur de mes futurs prototypes. La raison pour laquelle j'ai choisi le Raspberry Pi est que le Pi est une carte de circuit imprimé assez puissante bien qu'elle soit très légère et compacte. Le Pi peut se connecter à des cartes de commande de moteur, tout en ayant des capacités USB et Ethernet. De plus, le Pi est un ordinateur très bon marché et est livré avec un système d'exploitation gratuit. La figure 2 est une photographie du Raspberry Pi 3.

Ensuite, j'ai décidé d'utiliser la carte de commande de moteur L298N pour contrôler mes moteurs. Le L298N est un contrôleur de moteur assez simple qui peut contrôler jusqu'à 2 moteurs à courant continu. Le contrôleur de moteur est documenté comme étant capable de gérer des tensions allant jusqu'à 35 V. Étant donné que la plupart des moteurs que je voulais utiliser étaient dans la gamme 6 V-12 V, le L298N était idéal pour moi. La carte elle-même est assez petite, ne faisant qu'un tiers de la taille d'un Raspberry Pi. En raison de cette simplicité, il est facile d'acheter plusieurs L298N à faible coût. J'ai également décidé de commencer avec une seule caméra pour mon premier prototype avec le Raspberry Pi. La caméra que j'ai choisi d'utiliser est la caméra Raspberry Pi NoIR.

Cette caméra NoIR est une caméra compatible Pi conçue pour la vision nocturne. Alors que les structures comme les ponts peuvent être éclairées, l'intérieur des réservoirs sera probablement sombre; J'ai donc choisi la caméra Pi NoIR au lieu de la caméra Pi standard. J'ai également choisi la caméra NoIR car elle est conçue pour le Raspberry Pi et serait plus facile à utiliser que n'importe quelle autre caméra.

Pour mes moteurs, j'ai choisi des moteurs Arduino en plastique standard 6 V DC. J'ai choisi ces moteurs même s'il s'agissait de moteurs Arduino, car je savais que ma carte de commande pouvait faire fonctionner n'importe quel moteur à courant continu dans sa limite de tension. J'ai fait un calcul de mécanique d'ingénierie, comme indiqué ci-dessous, pour estimer le couple moteur nécessaire. Les moteurs en plastique sont très faciles à utiliser et à câbler, et sont également peu coûteux. Si l'un des moteurs tombait en panne, il serait facile de le remplacer par un nouveau moteur. Les moteurs sont également livrés avec des roues en plastique suffisamment grandes pour supporter et déplacer le robot, mais suffisamment petites pour être facilement contrôlées. En plus de mes deux moteurs d'entraînement, je voulais utiliser un autre moteur pour créer un mécanisme à levier sous le robot qui pourrait le soutenir. Le mécanisme serait utilisé pour soulever l'extrémité avant du robot du sol afin qu'il puisse mieux se fixer à une surface ferreuse. J'avais prévu de monter le robot sur un simple châssis de robot en plastique, et d'utiliser des bandes métalliques pour former une plate-forme surélevée pour toute partie qui ne pourrait pas être logée sur le châssis lui-même. J'ai décidé d'alimenter les L298N avec un bloc-piles 4-AA ou deux blocs-piles 2-AA. Le Raspberry Pi a été conçu pour être alimenté par un câble USB qui s'étend jusqu'à une prise électrique. Le robot serait contrôlé par une manette Xbox 360 filaire qui lui serait connectée à l'aide d'un câble USB. J'ai décidé d'utiliser une manette Xbox car elle a un pavé directionnel, ce qui serait idéal pour contrôler le mouvement du robot. Il possède également des boutons supplémentaires qui peuvent être affectés à différentes tâches dans le code du robot, telles que les commandes de la caméra. Pour les aimants, j'ai décidé de continuer à utiliser les aimants D51-N52 car j'avais prouvé que leur utilisation pour créer une bande magnétique autour d'une roue était une méthode réalisable pour créer une roue magnétique avec mon premier prototype.

4.3    Conception assistée par ordinateur (CAO) du deuxième prototype

Après avoir décidé des matériaux et des composants que j'utiliserais pour fabriquer mon 2 ^ème prototype, je suis passé à la construction d'un dessin CAO de mon prototype, afin de pouvoir le construire facilement une fois les pièces que j'ai spécifiées arrivées. Pour faire les dessins CAO, j'ai utilisé un logiciel appelé SketchUp, car le logiciel était gratuit, facile à apprendre par moi-même et facile à utiliser. Utilisation de mesures en ligne et physiques (une fois les pièces arrivées) des pièces que j'ai prévu d'utiliser pour faire mon 2 ^ème prototype de robot, j'ai pu construire un dessin CAO 3D réaliste de mon prototype de robot, comme le montre la figure 3. J'ai ensuite affiné davantage mon prototype en tenant compte des emplacements de vis optimaux. Après quelques itérations d'ajout de fonctionnalités de conception et d'affinement des détails, j'ai pu obtenir un modèle 3D satisfaisant de mon robot. Cela a servi à simplifier la partie matérielle de mon projet, car je devais juste construire une copie physique du modèle informatique en utilisant des pièces réelles.

4.4   Prototype 2a :Châssis préfabriqué

Construire le prototype 2a

Une fois toutes mes pièces arrivées et mes dessins CAO terminés, la construction de mon robot était une affaire simple. Lors de la construction du robot, j'ai commencé par percer des trous pour le montage du Raspberry Pi. Pour tracer les points que je percerais sur le châssis en plastique, j'ai maintenu le Pi au-dessus de l'extrémité arrière du châssis et j'ai utilisé un crayon fin pour marquer la zone sous chaque trou de vis sur le châssis. J'ai ensuite sélectionné un foret légèrement plus grand que les trous de vis du Pi pour percer chaque trou. J'ai ensuite percé des trous de la même manière à l'avant du châssis pour accueillir la carte pilote. Pour monter la carte pilote et le Raspberry Pi, j'ai utilisé des boulons et des écrous #4-40. Après avoir monté les deux cartes, j'ai utilisé les vis fournies pour fixer la roue arrière et

moteurs aux trous prédécoupés sur le châssis. Le châssis, les moteurs et la roue arrière ont été assemblés avec des écrous, des boulons et des instructions, il était donc facile de fixer les deux composants au châssis.

Pour ce prototype, j'ai utilisé du ruban adhésif double face très résistant pour fixer un troisième moteur sous le robot, directement entre les deux moteurs d'entraînement. J'ai ensuite pris quatre bâtonnets de popsicle et les ai collés ensemble dans le sens de la longueur par lots de deux. En conséquence, j'ai obtenu deux bâtons de popsicle très épais. J'ai ensuite coupé les bâtons de popsicle en deux et j'ai esquissé l'extrémité de l'axe du moteur à l'extrémité de chaque demi-bâton de popsicle. J'ai ensuite utilisé une perceuse pour creuser un trou dans chacun des nouveaux bâtons qui pourraient accueillir l'axe du moteur. En conséquence, j'ai obtenu 4 bâtons de popsicle épais, mi-longs et percés. J'ai ensuite choisi les deux bâtons qui s'adaptent le mieux et les ai attachés à chaque extrémité de l'essieu sur le moteur du milieu. J'ai fixé les bâtons de popsicle avec de la colle chaude. Le but de cet engin motorisé était de servir d'élévateur qui pousserait le robot hors de la surface sur laquelle il se trouvait une fois le moteur activé. Ce dispositif a été conçu pour permettre au robot de se détacher d'une surface ferreuse. Cela permettrait également au robot d'élever ses principales roues magnétiques du sol afin qu'il puisse se fixer à un mur ferreux à partir d'une autre surface. C'est l'une des nombreuses caractéristiques de conception uniques de ce projet. La conception de la roue magnétique est une autre caractéristique innovante.

Après avoir fixé le troisième moteur, j'ai utilisé du ruban de suspension en métal perforé pour créer des structures en forme de pont au-dessus de la carte de commande et du Raspberry Pi. Le ruban de suspension servait de surface secondaire sur laquelle des pièces supplémentaires pouvaient être montées. En raison des perforations, il était facile de percer des trous dans le châssis pour s'adapter au ruban de suspension en métal et de le fixer avec des boulons et des écrous restants. Au-dessus du pont de suspension à l'avant du robot, j'ai attaché une deuxième carte de commande pour contrôler le troisième moteur, car chaque carte ne peut contrôler que deux moteurs. J'ai pu fixer la carte pilote à l'aide de ruban adhésif double face. Avec plus de ruban adhésif double face, j'ai pu attacher un support de batterie 4-AA au sommet du hangar métallique arrière pour alimenter la carte de commande principale. J'ai également fixé deux supports de piles 2-AA à l'avant de mon robot pour alimenter la deuxième carte de pilotage.

J'ai terminé ce deuxième prototype en collant à chaud la caméra Raspberry Pi NoIR à l'avant du pont de ruban de suspension métallique. Après avoir construit le robot, il ne restait plus qu'à magnétiser les roues. J'ai retiré les pneus des roues et j'ai posé une couche de ruban adhésif double face sur chaque roue. Les roues et les moteurs en plastique sont illustrés à la figure 4. J'ai collé les petits aimants circulaires D51-N52 en cercle autour de la jante de chaque roue, de sorte qu'il y avait deux anneaux sur chaque roue. Après avoir ajouté tous les aimants, j'ai recouvert les deux roues d'une seule couche de ruban adhésif pour protéger les aimants. Pour magnétiser la roue arrière, j'ai collé des aimants à chaud dans un anneau autour de la roue, puis je les ai enveloppés dans du ruban adhésif. La raison pour laquelle le ruban adhésif a été utilisé est qu'il est suffisamment fin pour ne pas réduire la force de traction de manière significative, mais suffisamment solide pour protéger les aimants.

Câblage du prototype 2a

Après avoir attaché tous les composants de mon robot, j'ai commencé à les câbler ensemble. L'alimentation du Raspberry Pi est entrée via le port micro USB sur le côté. J'ai ensuite câblé les batteries à leurs cartes pilotes respectives. Les moteurs étaient également connectés aux cartes de commande à l'aide de fils fournis avec les moteurs. J'ai soudé les fils aux câbles d'alimentation du moteur et les ai connectés avec des vis à la carte de commande. J'ai ensuite câblé les broches GPIO du Pi aux cartes pilotes. Les broches GPIO sont des broches d'entrée/sortie à usage général sur le Raspberry Pi. Certaines broches sont utilisées pour la terre et l'alimentation, tandis que d'autres peuvent être utilisées pour envoyer des signaux via un fil. J'ai câblé GPIO 2 &6 à une carte pilote et 4 &9 à l'autre carte pilote. Ces broches étaient des broches 5 V et étaient utilisées pour permettre le mouvement et le contrôle du moteur via les cartes de commande. J'ai ensuite câblé les broches 11, 12, 13 et 15 à la première carte de commande et les broches 16 et 18 à l'autre carte de commande. Ces broches ont été utilisées pour envoyer le signal de commande du moteur réel. Chaque moteur

nécessitait deux broches pour le contrôle, et comme le robot utilisait 3 moteurs, les cartes de commande nécessitaient 6 broches GPIO de signal connectées pour le contrôle du moteur, en plus d'un 5 V et d'une masse par carte. Après avoir connecté les broches GPIO nécessaires, j'ai connecté un câble Ethernet entre mon Pi et mon ordinateur portable, afin que mon ordinateur portable puisse avoir une connexion de bureau à distance avec mon Raspberry Pi, éliminant ainsi le besoin d'un moniteur, d'un clavier et d'une souris. J'ai également connecté un hub alimenté via USB à mon Pi. Le hub était connecté à une manette Xbox, afin que je puisse contrôler le robot via la manette Xbox.

Programmation du prototype 2a

La partie la plus difficile de la conception de mon 2 ^ème prototype était le code. Avec mon premier prototype, ce n'était qu'un modèle matériel; il n'a exécuté aucun code. Ma raison étant, avec mon 1 ^er prototype, essayez comme je peux, je n'ai pas pu faire bouger les 4 moteurs simultanément avec le code. Le premier prototype a également été créé principalement pour tester le concept de roue magnétique et pour m'aider à trouver un design idéal pour les futurs prototypes. Sur le Raspberry Pi, j'ai codé avec Python, car c'était le seul langage pour le Raspberry Pi que je comprenais. Mais avant même de commencer mon code, j'ai dû configurer mon robot pour qu'il soit compatible avec le bureau à distance avec mon ordinateur portable.

Pour configurer mon Pi, j'ai dû attacher temporairement un moniteur, un clavier et une souris au Raspberry Pi. Ensuite, j'ai démarré le Pi et lui ai défini une adresse IP statique via Ethernet. J'ai choisi 192.168.1.10 car c'était une adresse simple et facile. Pour définir l'IP, je devais éditer

/ect/dhcpcd.conf dans mon Pi. Le fichier dhpcd.conf contrôle l'IP et la connexion réseau du Pi; pour définir une IP statique, j'ai dû ajouter les lignes au début du fichier :

interface eth0

statique ip_address=192.168.1.10 routeurs statiques=192.168.1.1

Après avoir défini l'adresse IP statique du Pi, j'ai installé le package Linux tightvncserver. Tightvncserver est un package qui permet de configurer un serveur VNC (connexion réseau virtuel) sur le Raspberry Pi. Les connexions Bureau à distance sont exécutées via des serveurs VNC. Après avoir configuré le serveur VNC, j'ai pu créer une connexion Bureau à distance avec mon Raspberry Pi via mon

ordinateur portable. Après avoir confirmé que je pouvais accéder à mon Pi, j'ai déconnecté mon moniteur, mon clavier et ma souris. J'ai ensuite commencé le codage du robot.

Tout d'abord, j'avais besoin d'un moyen de savoir quelle broche GPIO correspondait à quel moteur sur mon Pi. Chaque broche GPIO lorsqu'elle est activée, fait tourner un seul moteur vers l'avant ou vers l'arrière à une vitesse constante. Ainsi, chaque moteur a deux broches GPIO correspondantes, un contrôleur de mouvement avant et un contrôleur de mouvement arrière. Pour savoir à quoi correspondait chaque broche GPIO, j'ai écrit un programme qui testait individuellement chaque broche GPIO, afin de pouvoir noter quelle broche GPIO faisait quoi. J'ai enregistré mes observations à travers des commentaires sur mon programme :

importer RPi.GPIO en tant que GPIO à partir de l'heure d'importation du sommeil

GPIO.setmode(GPIO.BOARD)

GPIO.setup(12,GPIO.OUT) #Gauche arrière GPIO.setup(11,GPIO.OUT) #Gauche avant GPIO.setup(13,GPIO.OUT) #Gauche avant GPIO.setup(15,GPIO.OUT) # Arrière droit GPIO.setup (16,GPIO.OUT) #Lifter Out GPIO.setup(18,GPIO.OUT) #Lifter In

GPIO.sortie(12,GPIO.HIGH)

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

dormir(1)

GPIO.sortie(11,GPIO.HIGH)

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

dormir(1)

GPIO.sortie(13,GPIO.HIGH)

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

dormir(1)

GPIO.sortie(15,GPIO.HIGH)

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

dormir(1)

GPIO.sortie (16,GPIO.HIGH)

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

dormir(1)

GPIO.sortie(18,GPIO.HIGH)

sommeil(0,5) GPIO.sortie(18,GPIO.LOW)

dormir(1)

Ensuite, j'avais besoin d'un logiciel ou d'un code qui permettrait à mon Raspberry Pi de recevoir et de comprendre les signaux qui lui sont envoyés par le contrôleur Xbox. Xboxdrv est un pilote de contrôleur Xbox pour Linux. Je l'ai installé et utilisé pour essayer de connecter mon Pi à ma manette Xbox. Normalement, l'exécution de la commande « sudo xboxdrv » dans l'invite affichera les entrées du contrôleur Xbox connecté dans la fenêtre d'invite de commande. Cependant, ma manette Xbox n'était pas fabriquée par Microsoft, elle n'était donc pas prise en charge normalement par xboxdrv. J'ai résolu le problème en exécutant la commande :

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

J'ai pu créer cette commande après avoir recherché comment utiliser xboxdrv et comment modifier la fonction normale avec du code. Avec cette commande, j'ai identifié le contrôleur connecté en tant que contrôleur Xbox en utilisant son identifiant de périphérique qui était 1bad:f02e. Cette commande m'a permis de visualiser les entrées du contrôleur dans l'invite de commande. J'avais besoin d'un moyen d'accéder aux valeurs d'entrée à partir d'un

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