Inicialmente, OMower fue diseñado para las simples interfaces de control pfodApp y Modbus. El primero es un protocolo de texto de alto nivel en el que se transmiten menús y comandos de control, y el segundo es una cosa bien conocida, pero no muy conveniente en esta aplicación, ya que requiere que el programa de control sondee constantemente el estado de todos los sensores usados "manualmente". Por lo tanto, se decidió cambiar gradualmente a ROS (Robot OS), un marco ampliamente utilizado para controlar varios robots.
Por el momento, el soporte de ROS se encuentra en una etapa inicial, que incluye solo la transmisión de información desde sensores en forma de matrices simples (sin usar formatos de mensaje especializados ofrecidos por muchas bibliotecas ROS), registros de depuración y flujo de control de comandos en formato pfodApp / Modbus, sin la posibilidad Realmente controle el robot con herramientas ROS estándar. Es decir, para mover el robot de su lugar o cambiar cualquier configuración interna del robot, deberá enviarle un comando de texto en formato pfodApp. Pero incluso en una forma tan truncada: puede transmitir y grabar fácilmente lo que está sucediendo con el robot, visualizando sus movimientos en herramientas estándar ROS (rviz), así como agregando servicios para funciones adicionales. Tal, por ejemplo, la oportunidad de viajar en la dirección de la plantilla visual (tablero de ajedrez) proporcionada por omower_seeker.py, para una llegada precisa a la estación de estacionamiento.
La imagen muestra flujos de datos en el robot. Los principales servicios ROS se ejecutan en Orange PI Zero, atascado en una ranura especial en la placa del robot (en una máquina de prueba se utiliza Raspberry PI3 para esto, conectado de manera similar, a través del puerto serie). A través de la interfaz rosserial, el robot transmite mensajes desde sensores (como / imu / orientación o / motors / PWM), su registro de depuración en formato de texto y la salida de menús / mensajes en formato pfodApp o Modbus al núcleo ROS, recibiendo una secuencia de comandos de texto o Modbus -consultas. Dos Raspberry PI Zero adicionales vienen con secuencias de imágenes de las cámaras, pero como lo ha demostrado la práctica, es imposible obtener una sincronización normal para procesar imágenes estéreo con este esquema (la calidad es visible en la imagen a continuación), por lo que pronto se reemplazará una cámara estéreo normal.
El grado de integración de ROS en OMower se ampliará gradualmente, hasta proporcionar acceso completo a todas las variables internas del robot y la capacidad de administrarlo a través de herramientas ROS estándar (como mensajes cmd_vel que especifican la velocidad requerida).
Te contaré un poco más sobre el módulo omower_seeker.py, como un ejemplo del uso de ROS para agregar funciones a OMower. Su propósito es bastante simple: ir hacia el tablero de ajedrez, ajustando su ruta en tiempo real. Esta característica se utilizará para conducir el cortacésped a la estación de estacionamiento, donde puede cargar rápidamente sus baterías. Analizando la imagen de una de las cámaras, el módulo calcula dos ángulos (el ángulo de desviación de la placa desde el centro de la cámara y el ángulo de rotación de la placa en relación con la perpendicular) y los transmite como un comando de texto al módulo buscador interno (omower-seeker.h / cpp en el OMower SDK).
Exteriormente, esto parece una tarea bastante simple, pero en la vida real hay un problema grave: la velocidad del procesamiento de imágenes en un microordenador integrado en el robot. Como muestra la práctica, la velocidad de búsqueda de patrones en opencv en la imagen cuando se utiliza Orange PI y Raspberry Pi de baja potencia es muy baja e inestable, y toma de decenas a cientos de milisegundos a una resolución de 640x480, que durante la conducción se convierte en desviaciones de la ruta necesaria, ya que el robot , incluso con su baja velocidad, logra girar un ángulo considerable o recorrer una distancia relativamente grande durante este tiempo. En realidad, es por eso que se eligió un tablero de ajedrez con un mínimo de celdas, ya que otras plantillas toman aún más tiempo.
Para compensar el largo tiempo de búsqueda de la plantilla visual, se utiliza un esquema de brújula: el microcontrolador robot almacena sus valores cada 100 milisegundos, almacenando cinco muestras en el último medio segundo (los análisis más largos simplemente se descartan, ya que son de poca utilidad para una navegación precisa). Los ángulos calculados de omower_seeker.py (que también transmite el tiempo de búsqueda de la plantilla al microcontrolador) se recalculan al ángulo de rotación real utilizando el valor de la brújula guardado, que no está a más de 100 milisegundos del tiempo de búsqueda, y el robot viaja a lo largo de este ángulo. Esto le permite ir con mayor o menor precisión en la dirección del tablero de ajedrez en línea recta. O, si está ligeramente girado en relación con la perpendicular, a lo largo de un arco que corrige el ángulo de aproximación para que esté lo más cerca posible del eje de la plantilla, ya que no solo debemos conducir hasta el tablero, sino también entrar en los rieles de guía y conectarnos a los contactos de carga.
El algoritmo completo de llegada a la estación se implementa en tres etapas. Se establecen dos puntos en el campo GPS: el punto de inicio (en algún lugar en el medio del área de trabajo) y el punto frente a la estación, así como el ángulo de rotación hacia la estación. Después de que el robot llega desde el punto de partida al segundo y gira al ángulo deseado hacia el tablero de ajedrez en la estación, el módulo buscador entra en acción, ajustando la velocidad de los motores a través del controlador PID. Si alguno de los pasos falla, o los ángulos de desviación exceden los valores establecidos, el robot cancela la carrera y regresa al punto de partida nuevamente.
Enlaces y video:
→
OMower SDK, biblioteca para Arduino IDE y diseño de placa de circuito→
Firmware listo para usar usando el SDK que implementa pfodApp / Modbus y conexión a ROS→
paquete omower_gateway para ROS