Robot autónomo Wallace - Parte 4 - Agregar sensores de distancia IR y "Amp": 6 pasos

2024 Autor: John Day | [email protected]. Última modificación: 2024-01-30 08:43

Hola, hoy comenzamos la siguiente fase para mejorar las capacidades de Wallace. Específicamente, estamos tratando de mejorar su capacidad para detectar y evitar obstáculos usando sensores de distancia infrarrojos, y también aprovechar la capacidad del controlador de motor Roboclaw para monitorear la corriente y convertirla en un "sensor" virtual (software). Finalmente, veremos cómo navegar sin SLAM (ubicación y mapeo simultáneos) (por ahora), ya que el robot aún no tiene sensores IMU (unidad de medición de inercia) o ToF (tiempo de vuelo).

Por navegación, inicialmente solo serán dos objetivos principales:

1. evitar obstáculos
2. reconocer cuando está atascado en algún lugar y no progresa. ("progreso" significa que avanzó una distancia significativa)
3. un posible tercer objetivo podría ser que intente alinearse directamente con una pared.

Este proyecto comenzó con un kit de robot y consiguió que los movimientos básicos funcionaran mediante un teclado y una conexión ssh.

La segunda fase fue agregar suficientes circuitos de soporte para prepararse para la adición de muchos sensores.

En el Instructable anterior, agregamos varios sensores acústicos HCSR04 y el robot ahora puede evitar obstáculos mientras se mueve por el apartamento.

Si bien le va bien en la cocina y el pasillo con buenas superficies planas sólidas, es totalmente ciego cuando se acerca al comedor. No puede "ver" las patas de la mesa y la silla.

Una mejora puede ser realizar un seguimiento de las corrientes típicas del motor, y si los valores saltan, entonces el robot debe haber golpeado algo. Es un buen "plan B" o incluso C. Pero eso realmente no lo ayuda a navegar por el área del comedor.

(Actualización: en realidad, por ahora, el monitoreo de corriente es el plan A al dar marcha atrás, ya que eliminé temporalmente los sensores de la parte trasera).

El video de esta sección constituye la fase final de los sensores para evitar obstáculos.

Lo que ves en el video son seis sensores acústicos HCSR04 frontales y dos sensores IR de Sharp. Los sensores de infrarrojos no entraron mucho en juego en el video. Su fuerte es principalmente cuando el robot se encuentra en el comedor frente a las patas de la mesa y la silla.

Además de los sensores, el monitor de corriente entró en juego especialmente durante la marcha atrás, en caso de que chocara con algo.

Finalmente, utiliza el historial de los últimos 100 movimientos y un análisis básico para responder una pregunta:

"¿Ha habido recientemente un progreso real hacia adelante (o está atascado en algún baile que se repite)?"

Entonces, en el video, cuando ve un avance-retroceso repetido, luego gira, significa que reconoció el patrón de avance-retroceso, por lo tanto, intenta otra cosa.

El único objetivo programado de esta versión del software era tratar de hacer un progreso continuo hacia adelante y tratar de evitar obstáculos.

Paso 1: Agregar circuitos de soporte (MCP3008)

Antes de que podamos agregar los sensores de infrarrojos, necesitaremos los circuitos de interfaz entre ellos y la Raspberry Pi.

Agregaremos un convertidor analógico a digital MCP3008. Hay muchos recursos en línea sobre cómo conectar este chip a la Raspberry Pi, por lo que no profundizaré en eso aquí.

Básicamente, tenemos una opción. Si la versión de los sensores de infrarrojos funciona a 3 V, también puede hacerlo el MCP3008, y luego podemos conectarnos directamente a la Raspberry.

[Sensor de infrarrojos de 3 V] - [MCP3008] - [Raspberrry Pi]

En mi caso, sin embargo, estoy ejecutando principalmente 5V, lo que significa un cambiador de nivel bidireccional.

[Sensor de infrarrojos de 5 V] - [MCP3008] - [Bus bidireccional de 5 V a 3 V] - [Raspberry Pi]

Nota: solo hay una salida de señal del sensor de infrarrojos. Va directamente a una de las líneas de señal analógica de entrada del MCP3008. Desde el MCP3008, hay 4 líneas de datos que necesitamos conectar (a través del bus bidireccional) a la Raspberry Pi.

Por el momento, nuestro robot se ejecutará con solo dos sensores de infrarrojos, pero podríamos agregar fácilmente más. El MCP3008 ocho canales de entrada analógica.

Paso 2: monte los sensores de infrarrojos

Sharp fabrica varios sensores IR diferentes y tienen diferentes rangos y áreas de cobertura. Por casualidad ordené el modelo GP2Y0A60SZLF. El modelo que elija afectará la ubicación y orientación del sensor. Desafortunadamente para mí, realmente no investigué exactamente qué sensores obtener. Fue más una decisión de "cuáles puedo conseguir a un tiempo y precio razonables de una fuente confiable, fuera de los que ofrecen".

(Actualización: Sin embargo, eso puede no importar, ya que estos sensores parecen confundirse con la iluminación ambiental interior. Todavía estoy explorando ese problema)

Hay al menos tres formas de montar estos sensores en el robot.

1. Colóquelos en una posición fija, en la parte delantera, ligeramente alejados uno del otro.
2. Colóquelos en un servo, en la parte delantera, ligeramente alejados uno del otro.
3. Colóquelos en una posición fija, en la parte delantera, pero en las esquinas más a la izquierda y a la derecha, en ángulo entre sí.

Al comparar la opción n. ° 1 con la opción n. ° 3, creo que la n. ° 3 cubrirá una mayor parte del área de colisión. Si observa las imágenes, la opción n. ° 3 se puede hacer no solo para que los campos del sensor se superpongan, sino que también puedan cubrir el centro y más allá del ancho exterior del robot.

Con la opción n. ° 1, cuanto más separados estén los sensores entre sí, mayor será el punto ciego en el centro.

Podríamos hacer el # 2, (agregué algunas imágenes con servo como una posibilidad) y hacer que hagan un barrido, y obviamente esto puede cubrir la mayor parte del área. Sin embargo, quiero retrasar el uso de un servo tanto como sea posible, por al menos dos razones:

• Usaremos uno de los canales de comunicación PWM en la Raspberry Pi. (Es posible mejorar esto, pero aún así …)
• El consumo de corriente con el servo puede ser significativo
• Agrega más a hardware y software

Me gustaría dejar la opción de servo para más adelante cuando agregue sensores más importantes, como Time-of-Flight (ToF), o quizás una cámara.

Existe otra posible ventaja con la opción # 2 que no está disponible con las otras dos opciones. Estos sensores de infrarrojos pueden confundirse, según la iluminación. Podría ser que el robot obtenga una lectura de un objeto que está inminentemente cerca cuando en realidad no hay ningún objeto cercano. Con la opción 3, dado que sus campos pueden superponerse, ambos sensores pueden registrar el mismo objeto (desde diferentes ángulos).

Así que vamos con la opción de ubicación n. ° 3.

Paso 3: Hora de realizar la prueba

Una vez que hayamos realizado todas las conexiones entre la Raspberry Pi, el ADC MCP3008 y los sensores IR de Sharp, es hora de realizar la prueba. Solo una prueba simple para asegurarse de que el sistema esté funcionando con los nuevos sensores.

Como en los Instructables anteriores, utilizo la biblioteca WiringPi C tanto como sea posible. Facilita las cosas. Algo que no es muy obvio al revisar el sitio web del cableado de Pi, es que hay soporte directo para el MCP3004 / 3008.

Incluso sin eso, podría usar la extensión SPI. Pero no es necesario. Si observa de cerca el repositorio git de Gordon para cableadoPi, encontrará una lista de chips compatibles, de los cuales uno de ellos es para MCP3004 / 3008.

Decidí adjuntar el código como un archivo porque no pude hacer que se mostrara correctamente en esta página.

Paso 4: Un sensor virtual - AmpSensor

Cuantas más formas diferentes pueda hacer que el robot reciba información sobre el mundo exterior, mejor.

El robot tiene actualmente ocho sensores de sonda acústica HCSR04 (no son el foco de este Instructable), y ahora tiene dos sensores de distancia Sharp IR. Como se dijo anteriormente, podemos aprovechar algo más: la función de detección de corrientes de motor del Roboclaw.

Podemos envolver esa llamada de consulta al controlador de motor en una clase C ++ y llamarla AmpSensor.

Al agregar algunos "conocimientos" al software, podemos monitorear y ajustar el consumo de corriente típico durante el movimiento recto (hacia adelante, hacia atrás) y también los movimientos de rotación (izquierda, derecha). Una vez que conocemos esos rangos de amperios, podemos seleccionar un valor crítico, de modo que si el AmpSensor obtiene una lectura de corriente del controlador del motor que excede este valor, sepamos que los motores probablemente se han detenido, y eso generalmente indica que el robot ha golpeado. involucrado en algo.

Si agregamos algo de flexibilidad al software (argumentos de línea de comandos y / o entrada de teclado durante la operación), entonces podemos aumentar / disminuir el umbral de "amperios críticos" mientras experimentamos simplemente dejando que el robot se mueva y choque con objetos, ambos directamente hacia adentro o mientras gira.

Dado que nuestra parte de navegación del software conoce la dirección del movimiento, podemos usar toda esa información para, quizás, detener el movimiento e intentar revertir el movimiento durante un período corto antes de intentar otra cosa.

Paso 5: Navegación

Actualmente, el robot está limitado en la retroalimentación del mundo real. Tiene algunos sensores de corta distancia para evitar obstáculos, y tiene una técnica de retroceso para monitorear el consumo de corriente en caso de que los sensores de distancia pierdan un obstáculo.

No tiene motores con codificadores y no tiene IMU (unidad de medida inercial), por lo que es más difícil saber si realmente se está moviendo o girando, y en qué medida.

Si bien uno puede obtener algún tipo de indicación de distancia con los sensores que se encuentran actualmente en el robot, su campo de visión es amplio y hay imprevisibilidad. Es posible que la sonda acústica no se refleje correctamente; el infrarrojo puede confundirse con otra iluminación o incluso con múltiples superficies reflectantes. No estoy seguro de que valga la pena tratar de rastrear el cambio en la distancia como una técnica para saber si el robot se está moviendo y cuánto y en qué dirección.

Elegí deliberadamente NO usar un microcontrolador como un Arduino porque a) no me gusta el entorno psuedo-C ++, b) y que demasiado desarrollo desgastará la memoria de lectura y escritura (?), Y que yo necesitaría una computadora host para desarrollarse (?). O tal vez simplemente sucede como la Raspberry Pi.

Sin embargo, el Pi que ejecuta Raspbian no es un sistema operativo en tiempo real, por lo que entre las inestabilidades de estos sensores y el sistema operativo que no lee exactamente todas las veces, sentí que el propósito de estos sensores era más adecuado para evitar obstáculos y no medición de distancia real.

Ese enfoque parecía complicado y con poco beneficio, cuando podemos usar mejores sensores ToF (tiempo de vuelo) (más tarde) para ese propósito (SLAM).

Un enfoque que podemos utilizar es mantener algún tipo de seguimiento de los comandos de movimiento que se han emitido en los últimos X segundos o comandos.

Como ejemplo, digamos que el robot está atascado frente a una esquina en diagonal. Un conjunto de sensores le dice que está demasiado cerca de una pared, por lo que gira, pero luego el otro conjunto de sensores le dice que está demasiado cerca de la otra pared. Termina simplemente repitiendo un patrón de lado a lado.

El ejemplo anterior es solo un caso muy simple. Agregar algo de inteligencia puede simplemente elevar el patrón repetido a un nuevo nivel, pero el robot permanece atascado en la esquina.

Por ejemplo, en lugar de girar hacia adelante y hacia atrás en su lugar, gira en un sentido, hace retroceso momentáneo (que luego borra las indicaciones de distancia crítica), e incluso si gira en la otra dirección, todavía avanza en algún ángulo hacia la esquina., repitiendo un patrón más complicado de esencialmente lo mismo.

Eso significa que realmente podríamos usar un historial de comandos y ver cómo explotar y usar esa información.

Puedo pensar en dos formas muy básicas (rudimentarias) de usar la historia del movimiento.

• para los últimos X movimientos, ¿coinciden con el patrón Y? Un ejemplo simple podría ser (y esto sucedió) "HACIA ADELANTE, HACIA ATRÁS, HACIA ADELANTE, HACIA ATRÁS,…..". Entonces, existe esta función de coincidencia que devuelve VERDADERO (patrón encontrado) o FALSO (no encontrado). Si es VERDADERO, en la parte de navegación del programa, intente otras secuencias de movimiento.
• para el último número X de movimientos, ¿hay un movimiento hacia adelante general o neto? ¿Cómo se puede determinar qué es un movimiento de avance real? Bueno … una comparación fácil es que para los últimos X movimientos, "ADELANTE" ocurre más que "REVERSE". Pero ese no tiene por qué ser el único. Qué tal esto: "DERECHA, DERECHA, IZQUIERDA, DERECHA". En ese caso, el robot tiene que hacer giros a la derecha para salir de una esquina o porque se acercó a la pared en un ángulo, eso podría considerarse un avance real. Por otro lado, "IZQUIERDA, DERECHA, IZQUIERDA, DERECHA …" podría no considerarse un avance real. Por lo tanto, si "DERECHA" ocurre más que "IZQUIERDA", o "IZQUIERDA ocurre más que" DERECHA ", entonces eso podría ser un progreso real.

Al comienzo de este Instructable, mencioné que un posible tercer objetivo podría ser cuadrar o alinear a una pared. Para eso, sin embargo, necesitamos más que "estamos cerca de algún objeto". Por ejemplo, si podemos obtener dos sensores acústicos orientados hacia adelante (no el tema central de este artículo) para dar respuestas razonablemente buenas y estables con respecto a la distancia, obviamente si uno informa un valor muy diferente al otro, el robot se ha acercado a la pared. en ángulo, y podría intentar maniobrar para ver si esos valores se acercan entre sí (de cara a la pared de frente).

Paso 6: Pensamientos finales, siguiente fase …

Espero que este Instructable haya dado algunas ideas.

Agregar más sensores presenta algunas ventajas y desafíos.

En el caso anterior, todos los sensores acústicos funcionaron bien juntos y fue bastante sencillo con el software.

Una vez que se introdujeron los sensores de infrarrojos en la mezcla, se volvió un poco más desafiante. La razón es que algunos de sus campos de visión se superponen con los de los sensores acústicos. Los sensores de infrarrojos parecían un poco sensibles e impredecibles con las condiciones cambiantes de la luz ambiental, mientras que, por supuesto, los sensores acústicos no se ven afectados por la iluminación.

Entonces, el desafío estaba en qué hacer si un sensor acústico nos dice que no hay ningún obstáculo, pero el sensor de infrarrojos sí.

Por ahora, después de prueba y error, las cosas terminaron en esta prioridad:

1. sensor de amplificador
2. Detección de infrarrojos
3. detección acústica

Y lo que hice fue reducir la sensibilidad de los sensores de infrarrojos, para que solo detectaran objetos muy cercanos (como patas de sillas inminentes)

Hasta ahora, no ha habido necesidad de hacer ningún software de subprocesos múltiples o controlado por interrupciones, aunque ocasionalmente encuentro una pérdida de control entre la Raspberry Pi y el controlador de motor Roboclaw (pérdida de comunicaciones en serie).

Aquí es donde el circuito de parada de emergencia (ver Instructables anteriores) normalmente entraría en uso. Sin embargo, dado que no quiero (todavía) tener que lidiar con tener que reiniciar el Roboclaw durante el desarrollo, y el robot no va tan rápido, y estoy presente para monitorearlo y apagarlo, no lo he hecho. conectado la parada de emergencia.

Con el tiempo, lo más probable es que sea necesario utilizar varios subprocesos.

Próximos pasos…

Gracias por llegar tan lejos.

Obtuve algunos sensores ToF (tiempo de vuelo) láser IR VL53L1X, por lo que es muy probable que ese sea el tema del próximo Instructable, junto con un servo.