Diseño y desarrollo de un robot de inspección de bajo costo

1. Introducción

La infraestructura de nuestra nación está envejeciendo y deteriorándose rápidamente. Actualmente no existe ningún mecanismo para inspeccionar a fondo el estado de nuestros puentes, tanques de desechos, tuberías y reactores. Muchas de estas estructuras han llegado al final de su vida útil de diseño y necesitan ser inspeccionadas por deterioro. Al igual que esta situación en tierra, también existe la necesidad de inspeccionar los cascos y cubiertas de los barcos y petroleros de la Armada de los EE. UU. En busca de signos de corrosión. Muchas estructuras antiguas, como puentes altos y tanques de desechos, a menudo son difíciles de sondear o inspeccionar por una multitud de razones. La razón más común es que el proceso de inspección es peligroso para los humanos o que la estructura tiene secciones inaccesibles. Otra razón común es que la tecnología de sonda actual puede ser inadecuada para inspeccionar con precisión tales estructuras. Por tanto, la inspección manual es poco frecuente, laboriosa, cara, peligrosa y propensa a errores. Este problema ofrece una oportunidad perfecta para un robot de inspección bien hecho.

Los robots de inspección suelen estar diseñados y desarrollados por grandes equipos de ingenieros eléctricos y mecánicos bien financiados. Los robots comerciales, como el Packbot 510 (http://endeavorrobotics.com/products), pueden costar más de $ 100,000. Dadas las limitaciones de un proyecto de feria de ciencias individual, el alcance aquí es diseñar, desarrollar y probar un prototipo económico para un robot de inspección. El objetivo de este proyecto es desarrollar un prototipo de robot de inspección pequeño, liviano y económico que pueda permanecer adherido a las superficies a inspeccionar. El proyecto consta de las siguientes tareas:revisión de literatura y diseños existentes; especificación de requisitos; diseño de robots; desarrollo de prototipos y pruebas iniciales; cálculos de ingeniería mecánica; programar el robot usando Python; desarrollo y prueba del segundo prototipo; y desarrollo y prueba del prototipo final.

Antes de construir físicamente el robot, se utilizó el software de modelado 3D SketchUp para visualizar el robot y refinar el diseño. El robot se construyó a partir de componentes comerciales listos para usar, incluido un módulo Raspberry Pi 3 para controlar el robot. El diseño se mejoró iterativamente mediante pruebas repetidas. El código Python se escribió desde cero para programar el robot. A medida que evolucionó el diseño, tanto el hardware como el software tuvieron que modificarse en conjunto. El prototipo se demostró a expertos en ingeniería en Washington River Protection Solutions y el Laboratorio Nacional del Noroeste del Pacífico, y la Clase de Diseño Senior en el estado de Washington

Universidad, Tri Cities. Sobre la base de los comentarios de los expertos, los cálculos de ingeniería mecánica y los resultados de las pruebas, se construyó y programó el tercer prototipo. El robot resultante puede escalar paredes a una velocidad razonable y tiene varias cámaras para ayudar con la navegación y la inspección. El robot producido por este proyecto representa un diseño único con software escrito específicamente para este propósito. Este prototipo sirve como una plataforma flexible en la que se pueden agregar nuevos sensores según sea necesario para aumentar las capacidades de inspección.

2. Revisión de literatura

Antes de comenzar a trabajar en el proyecto, realicé una revisión de la literatura para evaluar las soluciones existentes. Las sondas disponibles actualmente se pueden clasificar en dos tipos:estacionarias y móviles.

Las sondas estacionarias son la herramienta más utilizada para inspeccionar estructuras. Proporcionan información muy detallada sobre una sección particular de una estructura y pueden monitorearla continuamente. Sin embargo, una vez que se colocan en un lugar, el rango de observación será limitado. Debido a la falta de movilidad, no son adecuados para monitorear grandes estructuras. La otra categoría está compuesta por sondas montadas en robots. Estos ofrecen un mayor grado de funcionalidad ya que la sonda se puede mover libremente. La mayoría de los robots actualmente en el mercado están muy especializados en una tarea o tipo de inspección específicos. Algunos robots pueden especializarse en atravesar agua, grandes altitudes o terrenos pantanosos semisólidos, pero ninguno de esos robots es útil para la inspección estructural.

El robot de inspección acuática AQUA ¹ es un gran ejemplo. AQUA es un robot de inspección costoso y altamente especializado. Se arrastra sobre el lecho de los cuerpos de agua y toma exploraciones tridimensionales (3D) de su área. Puede usar cámaras, escaneos de sensores y algoritmos para seguir una ruta designada bajo el agua. A pesar de ser un robot de inspección, es inútil para la inspección estructural, ya que carece de capacidad para trepar por superficies ferrosas.

Otro ejemplo es el AETOS ² drone aéreo. El dron AETOS es un quadcopter que se utiliza para topografía, mapeo de paisajes y respuesta de emergencia. El robot en sí es un cuadricóptero pilotado a distancia que suspende una cámara de alta potencia. La cámara puede capturar y grabar imágenes y videos detallados de estructuras y paisajes. El dron AETOS es versátil en su uso e incluso puede inspeccionar estructuras expuestas como puentes desde el aire. La desventaja del dron es que no es ideal para inspecciones estructurales detalladas, porque el viento puede mover el dron mientras se encuentra en medio de una inspección. El dron tampoco se puede utilizar dentro de estructuras cerradas, ya que corre el riesgo de estrellarse. El dron AETOS requiere una carga frecuente y no puede permanecer en el aire durante períodos prolongados. También es caro, propenso a sufrir daños y difícil de recuperar en caso de accidente.

Algunos de los robots disponibles actualmente incluyen potentes sensores, varias cámaras y capacidad para trepar paredes. Dichos robots son extremadamente costosos y no se pueden implementar en grandes cantidades para realizar inspecciones. Los riesgos de daños asociados con estos robots y los costos de reemplazo también son muy altos. El daño es una consideración muy real, porque prácticamente todos los robots empleados para inspeccionar los reactores nucleares dañados en el sitio de Fukushima Daiichi en Japón fallaron en marzo de 2017. Un ejemplo de un robot costoso es el MagneBike ³ . MagneBike es un robot bastante nuevo que aún no se vende comercialmente, pero que actualmente se encuentra en pruebas y desarrollo privado. La MagneBike es una bicicleta robótica que cuenta con dos ruedas conectadas a un cuerpo principal por una articulación libre. Esta articulación permite que el robot se mueva libremente sobre cualquier superficie ferrosa independientemente de los contornos. Cada rueda también tiene dos palancas unidas a sus lados y se asemeja a ruedas de entrenamiento. La longitud de cada palanca es ligeramente mayor que el radio de cada rueda. Las palancas se utilizan para desvincular la rueda de la superficie magnética a la que está conectada, lo que le permite moverse suavemente en ángulos interiores. La MagneBike se puede configurar para admitir una cámara de alta definición y admite un sensor de mapeo 3D, que le permite crear un modelo 3D de su entorno. El robot se controla y alimenta a través de un cable y es un dispositivo atado para una fácil recuperación. Sin embargo, la desventaja de la MagneBike es que es muy difícil de reemplazar si está rota y es bastante cara si las piezas utilizadas son adecuadas.

Un robot con ruedas magnéticas similar es el robot magnético multisegmentado ⁴ de la Marina de los EE. UU. (MSMR). El MSMR es un robot naval diseñado para la inspección del casco de un barco. Si bien el MSMR no está diseñado para inspección estructural sobre el suelo, podría adaptarse fácilmente para inspeccionar estructuras. Además, inspeccionar el casco de un barco e inspeccionar una estructura industrial no son tareas diferentes. El MSMR es un robot de 3 segmentos, y cada segmento es una caja de metal que contiene componentes electrónicos, con dos ruedas unidas a sus lados. Los segmentos están conectados mediante conectores flexibles o articulados.

Cada rueda puede funcionar de forma independiente y el robot puede escalar obstáculos 3D fácilmente cuando todas las ruedas trabajan juntas. Las ruedas están magnetizadas y pueden soportar el robot. Las desventajas del robot son que no tiene una correa y, por lo tanto, solo funciona con una batería. Esto es una desventaja, porque hace que el robot sea mucho más difícil de controlar y limita la vida útil de inspección del robot. El MSMR tampoco se ha lanzado actualmente y solo lo utiliza la Marina. El robot probablemente seguirá siendo así en el futuro previsible.

Otro ejemplo de un robot de inspección es el Microbot Omni-Directional Wall-Climbing ⁵ . El Microbot es un robot circular minúsculo que pesa solo 7,2 gramos. Tiene un diámetro de 26 mm y una altura de 16,4 mm. El bot se encuentra actualmente en las etapas finales de prueba y aún no está disponible comercialmente. El robot admite 3 micromotores magnéticos de ruedas con capacidad de giro de 360 ​​°. Las ruedas le permiten atravesar la mayoría de superficies ferrosas con facilidad. El Microbot se puede configurar para admitir una única microcámara. La cámara puede enviar imágenes y videos simples al controlador. El robot también está atado. Está conectado a su controlador mediante cables de cobre que pueden aislarse para su protección. Si bien el robot es económico y se puede usar en grupos, solo admite una sola cámara y la atadura es débil. También carece de espacio para la expansión y no puede admitir ningún sensor.

Hay diseños de robots que utilizan ventosas o presión negativa generada por hélices para adherirse a las superficies. Las ventosas ofrecen movilidad limitada en comparación con las ruedas magnéticas y no son adecuadas para robots pesados ​​equipados con múltiples cámaras y sensores. Además, la potencia de succión se degradará con el tiempo debido al desgaste mecánico. El sistema de presión negativa requiere una potencia considerable y una potencia constante. Si se pierde energía, el robot se desprenderá de la superficie. Cada uno de los diseños que se ha probado anteriormente tiene sus ventajas y desventajas, pero ninguno ha resuelto por completo el problema de la inspección. La revisión de la literatura me permitió estudiar el paisaje, aprender sobre lo que se había intentado antes y crear mi propio diseño.

1. Especificación de requisitos

El robot de inspección tendría que cumplir con varias limitaciones. La primera restricción del robot sería el tamaño. Idealmente, un robot de inspección sería pequeño. Algunos de los espacios que inspeccionaría el robot tienen menos de un pie de ancho y alto. El tamaño está limitado en este proyecto a 25x25x25 cm. El tamaño más pequeño aumenta la movilidad y versatilidad del robot en entornos complejos, como vigas de puentes. Una ventaja del tamaño pequeño es también que el robot consumirá menos energía y será más fácil de manipular. El robot también tendría que estar atado. Un robot conectado podría enviar más datos de manera más rápida y confiable que un robot inalámbrico.

El controlador del robot no tendría que preocuparse de que el robot abandone el rango de la señal inalámbrica, y también podría extraer fácilmente el robot en caso de accidente o falla. Además, un robot de inspección tendría que admitir varias cámaras para una inspección y navegación exhaustivas. El metraje de la cámara en vivo desde el robot hasta el controlador sería necesario para que el robot sea conducido con precisión a través de la estructura que está inspeccionando y para advertir al controlador de peligros inmediatos. Otra limitación que debería cumplir el robot es que debería poder trepar sobre superficies ferrosas. La forma más fácil de cumplir con esa restricción sería que el robot tuviera ruedas magnéticas o un cuerpo magnético, lo que le permitiría escalar superficies ferrosas con facilidad. Esto se debe a que los materiales ferromagnéticos, como el acero dulce, el acero de baja aleación y el hierro, son materiales primarios en la construcción de tales estructuras. Por último, el robot debe ser económico, preferiblemente con un costo inferior a 200 dólares. Un robot económico es fácil de reemplazar y, al inspeccionar estructuras más antiguas, no sería sorprendente que un robot se dañe. Un robot económico también significa que se pueden comprar y utilizar más robots para una tarea, lo que puede aumentar enormemente la eficiencia de la inspección.

4. Diseño y Desarrollo del Robot

4.1. Prototipo 1:LEGO EV3

Para diseñar un robot que cumpla con las restricciones mencionadas anteriormente, comencé a hacer prototipos con un módulo de control LEGO EV3 y otras partes de LEGO. Originalmente comencé a trabajar con LEGO para la creación de prototipos porque es fácil de construir con LEGO y crear un robot es bastante simple. El módulo EV3 es un núcleo de robot programable que controla el robot LEGO y ya estaba disponible en casa. Usando piezas de LEGO, fue bastante fácil crear un cuerpo robusto de robot con 4 motores y ruedas adjuntos. Cuando comencé con el EV3, intenté hacer un diseño plano y compacto para mi robot. Debido a la forma en que encajan las piezas de LEGO, esa idea comenzó a fallar cuando llegó el momento de adjuntar mi 3 ^rd y 4 ^th motor. No pude ajustar mis motores a mi módulo de control. Luego, me moví hacia un diseño angular, con el módulo suspendido sobre el resto de mi robot y los motores arqueándose desde un marco principal. Después de diseñar el marco de soporte principal, que se ajustaba cómodamente debajo del controlador, pude diseñar soportes de motor. Los soportes eran brazos inclinados hacia abajo que se proyectaban desde el bastidor principal y se unían a los motores. Los motores se sujetaron minuciosamente al extremo de los soportes para evitar fallas estructurales durante la prueba. Para estabilizar aún más los motores y sus soportes, conecté cada motor al motor más cercano con conectores rígidos. El conector también evitaba que un motor fuera mucho más rápido que los demás, porque servía para unir motores y crear un marco secundario.

Después de terminar con el diseño estructural y la construcción del robot LEGO, pasé al diseño de las ruedas. Para las ruedas, comencé con 4 ruedas EV3 de tamaño estándar. Cada rueda tenía un radio de 17 mm y un ancho de 17 mm. Además, cada rueda venía con una llanta de goma hueca adjunta. Para configurar las ruedas para el movimiento magnético, comencé quitando los neumáticos. Después de quitar los neumáticos, solo quedó la rueda de plástico desnuda. El plástico tenía hendiduras profundas como el hada, que cubrían consistentemente la mayor parte de la rueda. Debido a las hendiduras, no pude colocar imanes directamente en las ruedas. Los imanes que usé para el robot LEGO fueron discos D51-N52 de K&J Magnetics ⁶ . Los imanes D51-N52 son discos magnéticos de neodimio-hierro-boro (NdFeB) que tienen un diámetro de 5/16 ”(8 mm) y un grosor de 1/16”

(1,6 mm). Elegí usar esos imanes porque eran lo suficientemente pequeños como para poder envolver una cadena de ellos alrededor de la rueda y crear una banda magnética. Cada D51-N52 tiene una fuerza de tracción de 2.05 lb (9.1 Newton) cuando se pega directamente a una placa de acero. Con cuatro ruedas envueltas en los imanes, el magnetismo sería más que suficiente para sostener el robot LEGO, que se muestra en la Figura 1.

Probé métodos para colocar imanes en las ruedas de mi robot. Originalmente intenté envolver un papel alrededor de la rueda y pegar imanes a ese papel. Esa idea no funcionó porque el papel era demasiado débil para proporcionar una superficie firme para los imanes, y no

lo suficientemente fuerte como para evitar que los imanes se agrupen y salgan de la rueda. A continuación, intenté llenar los agujeros de las ruedas con arcilla o plastilina y colocar imanes sobre ellas. Esta idea también falló porque ninguno de los materiales se adhirió al superpegamento. Después de que ninguna de las ideas funcionó, experimenté para ver si funcionaba un híbrido de las dos ideas. Llené las hendiduras de la rueda con tiras de papel plegadas y comprimidas. Luego pegué las tiras en su lugar.

Luego, envolví papel que estaba doblado y reforzado con finas hebras de metal alrededor de la rueda. El papel reforzado era una superficie lo suficientemente resistente pero flexible para que yo pudiera pegar imanes con superpegamento. Después de colocar los imanes con éxito en las cuatro ruedas, envolví cada rueda con cinta adhesiva en lugar de usar una llanta. La razón por la que elegí no usar una llanta fue que una llanta reduciría demasiado la fuerza de tracción de los imanes debido a su grosor, mientras que la cinta adhesiva no reduciría significativamente la fuerza de tracción y al mismo tiempo ofrecería tracción. Después de envolver las ruedas, pasé un eje LEGO a través de cada rueda y lo usé para unir cada rueda a mis motores.

La fijación de las ruedas marcó el final del desarrollo de mi primer prototipo. Probé el prototipo presionándolo contra una puerta de acero. El robot pudo pegarse firmemente a la puerta sin resbalar. El robot no cumplió con varias restricciones de diseño:era más grande de 25x25x25 cm, costaba más de $ 200, no estaba conectado, requería baterías y no era compatible con cámaras.

Sin embargo, este prototipo inicial cumplió con un objetivo clave. El verdadero objetivo de mi primer prototipo fue ayudarme a comprender cómo unir un robot a una superficie ferrosa de manera eficiente con imanes y ayudarme a comprender cómo diseñar un robot y ruedas para resolver el problema de inspección.

4.2 Selección de materiales y componentes para el segundo prototipo

Después de construir mi primer robot prototipo con LEGO, decidí seleccionar componentes y diseñar y visualizar mi próximo prototipo en la computadora antes de comenzar la construcción. Primero, decidí que usaría una Raspberry Pi como núcleo de mis futuros prototipos. La razón por la que elegí la Raspberry Pi fue que la Pi es una placa de circuito bastante potente a pesar de ser muy ligera y compacta. El Pi puede conectarse a tableros de control de motores, sin dejar de tener capacidades USB y Ethernet. Además, la Pi es una computadora muy económica y viene con un paquete de sistema operativo gratuito. La figura 2 es una fotografía de la Raspberry Pi 3.

Luego decidí usar la placa de control de motor L298N para controlar mis motores. El L298N es un controlador de motor bastante simple que puede controlar hasta 2 motores de CC. Está documentado que el controlador del motor puede manejar voltajes de hasta 35 V. Dado que la mayoría de los motores que quería usar estaban en el rango de 6 V-12 V, el L298N era ideal para mí. La placa en sí es bastante pequeña, solo tiene un tercio del tamaño de una Raspberry Pi. Debido a esta simplicidad, es fácil comprar varios L298N a bajo costo. También decidí comenzar con una sola cámara para mi primer prototipo con la Raspberry Pi. La cámara que elegí usar es la cámara Raspberry Pi NoIR.

Esta cámara NoIR es una cámara compatible con Pi que está diseñada para visión nocturna. Si bien las estructuras como los puentes pueden estar iluminadas, el interior de los tanques probablemente estará oscuro; así que elegí la cámara Pi NoIR en lugar de la cámara Pi estándar. También elegí la cámara NoIR porque está diseñada para Raspberry Pi y sería más fácil de usar que cualquier otra cámara.

Para mis motores, elegí motores Arduino de plástico estándar de 6 V CC. Elegí estos motores a pesar de que eran motores Arduino, porque sabía que mi placa de controlador podía hacer funcionar cualquier motor de CC dentro de su límite de voltaje. Hice un cálculo de mecánica de ingeniería, como se explica a continuación, para estimar el par motor necesario. Los motores de plástico son muy fáciles de usar y cablear, y también son económicos. Si uno de los motores se rompiera, sería fácil reemplazarlo por uno nuevo. Los motores también vienen con ruedas de plástico que son lo suficientemente grandes para sostener y mover el robot, pero lo suficientemente pequeñas como para controlarlas fácilmente. Además de mis dos motores de accionamiento, quería usar otro motor para crear un mecanismo de palanca debajo del robot que pudiera apuntalarlo. El mecanismo se usaría para levantar el extremo frontal del robot del suelo para que pudiera adherirse mejor a una superficie ferrosa. Planeaba montar el robot en un simple chasis de robot de plástico y usar tiras de metal para formar una plataforma elevada para cualquier parte que no pudiera acomodarse en el propio chasis. Decidí alimentar los L298N con un paquete de baterías 4-AA o dos paquetes de baterías 2-AA. La Raspberry Pi fue diseñada para recibir energía de un cable USB que se extendía hasta una toma de corriente. El robot sería controlado por un controlador Xbox 360 con cable conectado a él mediante un cable USB. Decidí usar un controlador Xbox porque tiene un teclado direccional, que sería ideal para controlar el movimiento del robot. También tiene botones adicionales que podrían asignarse a diferentes tareas dentro del código del robot, como los controles de la cámara. Para los imanes, decidí seguir usando imanes D51-N52 porque había demostrado que usarlos para crear una banda magnética alrededor de una rueda era un método factible para crear una rueda magnética con mi primer prototipo.

4.3 Diseño asistido por computadora (CAD) del segundo prototipo

Después de decidir los materiales y componentes que usaría para hacer mi segundo ^nd prototipo, pasé a construir un dibujo CAD de mi prototipo, para poder construirlo con facilidad una vez que llegaran las piezas que especifiqué. Para hacer los dibujos CAD, utilicé un software llamado SketchUp, porque el software era gratuito, fácil de aprender por mi cuenta y fácil de usar. Usando medidas físicas y en línea (una vez que llegaron las partes) de las partes que planeaba usar para hacer mi 2 ° ^nd prototipo de robot, pude construir un dibujo CAD en 3D realista de mi prototipo de robot como se muestra en la Figura 3. Luego refiné aún más mi prototipo tomando en consideración las ubicaciones óptimas de los tornillos. Después de algunas iteraciones de agregar características de diseño y refinar los detalles, pude obtener un modelo 3D satisfactorio de mi robot. Esto sirvió para simplificar la parte de hardware de mi proyecto, ya que solo tenía que construir una copia física del modelo de computadora usando partes reales.

4.4 Prototipo 2a:chasis prefabricado

Construcción del prototipo 2a

Después de que todas mis piezas llegaron y mis dibujos CAD estuvieron terminados, construir mi robot fue un asunto simple. Cuando construí el robot, comencé perforando agujeros para montar la Raspberry Pi. Para trazar los puntos que perforaría en el chasis de plástico, sostuve el Pi en la parte superior del extremo posterior del chasis y usé un lápiz delgado para marcar el área debajo de cada orificio de tornillo en el chasis. Luego seleccioné una broca que era un poco más grande que los orificios de los tornillos en el Pi para perforar cada orificio. Luego, hice agujeros de manera similar en la parte frontal del chasis para acomodar la placa del controlador. Para montar la placa del controlador y Raspberry Pi, utilicé pernos y tuercas # 4-40. Después de montar ambas placas, utilicé los tornillos proporcionados para sujetar la rueda trasera y

motores para precortar agujeros en el chasis. El chasis, los motores y la rueda trasera se unieron con tuercas, pernos e instrucciones, por lo que conectar ambos componentes al chasis fue fácil.

Para este prototipo, utilicé cinta adhesiva de doble cara de alta resistencia para unir un tercer motor a la parte inferior del robot, directamente entre ambos motores de accionamiento. Luego tomé cuatro palitos de helado y los pegué a lo largo en juegos de dos. Como resultado, obtuve dos palitos de helado muy gruesos. Luego corté los palitos de helado por la mitad y dibujé el extremo del eje del motor en el extremo de cada medio palito de helado. Luego usé un taladro para hacer un agujero en cada uno de los nuevos palos que acomodarían el eje del motor. Como resultado, obtuve 4 palitos de helado perforados, gruesos y de media longitud. Luego elegí los dos palos que mejor encajaban y los coloqué en cada extremo del eje del motor central. Aseguré los palitos de helado con pegamento termofusible. El propósito de este artilugio motorizado era servir como un elevador que empujaría al robot fuera de la superficie en la que se encontraba una vez que se activara el motor. Este dispositivo fue diseñado para permitir que el robot se desprenda de una superficie ferrosa. También permitiría al robot elevar sus ruedas magnéticas principales del suelo para poder adherirse a una pared ferrosa desde otra superficie. Esta es una de las varias características de diseño únicas de este proyecto. El diseño de la rueda magnética es otra característica innovadora.

Después de conectar el tercer motor, utilicé cinta de suspensión de metal perforada para crear estructuras en forma de puente sobre la placa del controlador y la Raspberry Pi. La cinta de suspensión servía como superficie secundaria sobre la que se podían montar piezas adicionales. Debido a las perforaciones, fue fácil perforar agujeros en el chasis para colocar la cinta de suspensión de metal y asegurarlo con los pernos y tuercas sobrantes. En la parte superior del puente de cinta colgante en la parte delantera del robot, conecté una segunda placa de controlador para controlar el tercer motor, ya que cada placa solo puede controlar dos motores. Pude colocar la placa del controlador con cinta adhesiva de doble cara. Con más cinta adhesiva de doble cara, pude colocar un soporte de batería 4-AA en la parte superior del hangar de metal trasero para alimentar la placa del controlador principal. También coloqué dos portapilas 2-AA en la parte frontal de mi robot para alimentar la segunda placa del controlador.

Terminé este segundo prototipo pegando en caliente la cámara Raspberry Pi NoIR al frente del puente de cinta de suspensión de metal. Después de construir el robot, todo lo que quedaba era magnetizar las ruedas. Quité los neumáticos de las ruedas y coloqué una capa de cinta adhesiva de doble cara sobre cada rueda. Las ruedas de plástico y los motores se muestran en la Figura 4. Pegué los pequeños imanes circulares D51-N52 en un círculo alrededor de la llanta de cada rueda, de modo que había dos aros en cada rueda. Después de agregar todos los imanes, cubrí ambas ruedas con una sola capa de cinta adhesiva para proteger los imanes. Para magnetizar la rueda trasera, pegué imanes con pegamento caliente en un anillo alrededor de la rueda y luego los envolví en cinta adhesiva. La razón por la que se usó cinta adhesiva fue porque es lo suficientemente delgada como para no reducir la fuerza de tracción de manera significativa, pero lo suficientemente fuerte como para proteger los imanes.

Prototipo de cableado 2a

Después de conectar todos los componentes de mi robot, comencé a conectarlos. La energía para la Raspberry Pi llegó a través del puerto micro USB en su costado. Luego conecté los paquetes de baterías a sus respectivas placas de controlador. Los motores también se conectaron a las placas del controlador mediante cables que venían con los motores. Soldé los cables a los cables de alimentación del motor y los conecté con tornillos a la placa del controlador. Luego conecté los pines GPIO en el Pi a las placas del controlador. Los pines GPIO son pines de entrada / salida de uso general en la Raspberry Pi. Algunos pines se usan para tierra y energía, mientras que otros se pueden usar para enviar señales a través de un cable. Conecté GPIO 2 y 6 a una placa de controlador y 4 y 9 a la otra placa de controlador. Esos pines eran pines de 5 V y se usaban para permitir el movimiento y control del motor a través de las placas del controlador. Luego conecté los pines 11, 12, 13 y 15 a la primera placa del controlador, y conecté los pines 16 y 18 a la otra placa del controlador. Esos pines se utilizaron para enviar la señal de control del motor real. Cada motor

requería dos pines para el control, y dado que el robot usaba 3 motores, las placas del controlador requerían 6 pines GPIO de señal conectados para el control del motor, además de 5V y tierra por placa. Después de conectar los pines GPIO necesarios, conecté un cable Ethernet entre mi Pi y mi computadora portátil, para que mi computadora portátil pudiera tener una conexión de escritorio remota con mi Raspberry Pi, eliminando la necesidad de un monitor, teclado y mouse. También conecté un concentrador alimentado a través de USB a mi Pi. El concentrador estaba conectado a un controlador de Xbox, por lo que podría controlar el robot a través del controlador de Xbox.

Prototipo de programación 2a

La parte más difícil de diseñar mi segundo ^nd prototipo era el código. Con mi primer prototipo, era simplemente un modelo de hardware; no ejecutó ningún código. Mi razón es, con mi 1 ^st prototipo, por más que lo intenté, no pude hacer que los 4 motores se movieran simultáneamente con el código. El primer prototipo también se creó principalmente para probar el concepto de rueda magnética y ayudarme a encontrar un diseño ideal para futuros prototipos. En la Raspberry Pi, codifiqué con Python, porque era el único lenguaje de la Raspberry Pi que entendía. Pero incluso antes de comenzar con mi código, tuve que configurar mi robot para que fuera compatible con el escritorio remoto de mi computadora portátil.

Para configurar mi Pi, tuve que conectar temporalmente un monitor, teclado y mouse a la Raspberry Pi. Luego, arranqué el Pi y configuré una IP estática para él a través de Ethernet. Elegí 192.168.1.10 porque era una dirección sencilla y fácil. Para configurar la IP tuve que editar

/ect/dhcpcd.conf en mi Pi. El archivo dhpcd.conf controla la IP y la conexión de red del Pi; para establecer una IP estática tuve que agregar las líneas al principio del archivo:

interfaz eth0

dirección_ip estática =192.168.1.10 enrutadores estáticos =192.168.1.1

Después de configurar la IP estática del Pi, instalé el paquete de Linux tightvncserver. Tightvncserver es un paquete que permite configurar un servidor VNC (conexión de red virtual) en la Raspberry Pi. Las conexiones de escritorio remoto se ejecutan a través de servidores VNC. Después de configurar el servidor VNC, pude crear una conexión de escritorio remoto a mi Raspberry Pi a través de mi

ordenador portátil. Después de confirmar que podía acceder a mi Pi, desconecté mi monitor, teclado y mouse. Luego comencé a codificar el robot.

Primero, necesitaba una forma de averiguar qué pin GPIO correspondía a qué motor en mi Pi. Cada pin GPIO cuando se activa, hace girar un solo motor hacia adelante o hacia atrás a una velocidad constante. Por lo tanto, cada motor tiene dos pines GPIO correspondientes, un controlador de movimiento hacia adelante y un controlador de movimiento hacia atrás. Para averiguar a qué correspondía cada pin GPIO, escribí un programa que probaba individualmente cada pin GPIO, de modo que pudiera anotar qué pin GPIO hacía qué. Grabé mis observaciones a través de comentarios en mi programa:

importar RPi.GPIO como GPIO desde time import sleep

GPIO.setmode (GPIO.BOARD)

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

Salida GPIO (12, GPIO.ALTA)

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

dormir (1)

GPIO.output (11, GPIO.HIGH)

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

dormir (1)

Salida GPIO (13, GPIO.ALTA)

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

dormir (1)

Salida GPIO (15, GPIO.ALTA)

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

dormir (1)

Salida GPIO (16, GPIO.ALTA)

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

dormir (1)

Salida GPIO (18, GPIO.ALTA)

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

dormir (1)

A continuación, necesitaba un software o código que le permitiera a mi Raspberry Pi recibir y comprender las señales que le envía el controlador de Xbox. Xboxdrv es un controlador de controlador de Xbox para Linux. Lo instalé y lo usé para intentar conectar mi Pi a mi controlador Xbox. Normalmente, ejecutar el comando "sudo xboxdrv" en el símbolo del sistema mostrará las entradas del controlador Xbox conectado en la ventana del símbolo del sistema. Sin embargo, mi controlador Xbox no fue fabricado por Microsoft, por lo que xboxdrv no lo admite normalmente. Solucioné el problema ejecutando el comando:

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

Pude crear este comando después de investigar cómo usar xboxdrv y cómo modificar la función normal con código. Con este comando, identifiqué el controlador conectado como un controlador Xbox usando su ID de dispositivo, que era 1bad:f02e. Este comando me permitió ver las entradas del controlador en el símbolo del sistema. Necesitaba una forma de acceder a los valores de entrada desde 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