Diseño de un robot de servicio. Planteamiento del problema, arquitectura de la solución

Con un equipo (al que puedes unirte ) de personas con ideas afines de Habr, estamos desarrollando un robot para recoger pelotas de golf en el campo de prácticas .



Vladimir Goncharov Shadow_ru habla sobre la recopilación de requisitos, la formulación de tareas para el trabajo, el desarrollo de una arquitectura y la creación de un prototipo para ejecutar software.



El proyecto comenzó para mí, con la recopilación de requisitos, la generalización y la posterior descomposición de las subtareas. La tarea para el robot a primera vista es simple, pero los errores en la etapa de planificación arruinan en gran medida el resultado del trabajo y no siempre son visibles de inmediato, por lo que omitir esta etapa es el camino a ninguna parte.

Resumir los requisitos simplifica la comunicación con otros miembros del equipo: se desarrolla una comprensión común del problema, la situación cuando cada robot en su cabeza ya no surge. Además, cuando un nuevo miembro ingresa al equipo, es suficiente leer un documento similar, lo que reduce el tiempo para la fase de ingreso.

Siempre hay un equilibrio entre la recopilación de requisitos y generalizaciones. Quiero describirlo con más detalle, pero si no es un abogado que está acostumbrado a trabajar con cientos de párrafos relacionados, esto no resolverá el problema de visión general. Por supuesto, existe el enfoque correcto cuando se hacen varios segmentos de requisitos para diferentes miembros del equipo y clientes y contratistas externos. Pero por ahora esto es claramente innecesario, porque Cada cambio en los requisitos conducirá a una seria inversión de tiempo para actualizar dichos segmentos, lo que no afecta demasiado bien la productividad de inicio.

Por mi parte, decidí dividirme en requisitos funcionales y no funcionales y ponerlo todo en una página A4. La primera versión salió así:

Fase 1. Declaración del problema.

Desafío: se requiere un desvío máximo continuo de un campo de golf de entrenamiento en condiciones climáticas difíciles para recoger pelotas.

Problema: Se requiere un vehículo terrestre no tripulado ( UGV ) para realizar misiones cíclicas para evitar el espacio definido por el perímetro con las coordenadas de los puntos en la notación WGS-84.

Las misiones deben incluir las siguientes operaciones:

1. Inicio normal desde una posición inicial conocida
2. Arranque de emergencia desde una posición desconocida de antemano (arranque después de la operación WD, protección de energía, etc.)
3. Evitar un área con una cobertura de al menos el 98% del espacio para 1 o más carreras (no es necesario volver a saltear el campo después de llenar la tolva después de 15 minutos)
4. Vuelva a la posición inicial para llenar la tolva, drene la batería y finalice el desvío.
5. Corre en la plataforma de lanzamiento para reiniciar las bolas, carga las baterías

Versión simplificada del algoritmo.



Además, UGV debe cumplir los siguientes requisitos:

1. No deje el perímetro especificado cuando conduzca alrededor del perímetro especificado.
2. La posición inicial puede estar fuera del perímetro especificado.
3. Monitoree el consumo de batería y planifique un retorno basado en la energía usada. Mover una tolva llena requiere más energía de la batería que una vacía.
4. Mantenga registros de telemetría que incluyen, entre otros, coordenadas en el plano, valores de 6 ejes de rotación, nivel de señal de telemetría y sensores externos.
5. Para tener tres sistemas de posicionamiento: GPS para obtener coordenadas gruesas, IMU para verificación y corrección de coordenadas en el plano, ópticas para posicionamiento preciso por marcadores.
6. Tenga dos sistemas Watch Dog: software y hardware. El software verifica el estado
7. Tenga un canal de comunicación de emergencia de largo alcance con fuente de alimentación separada, que se utiliza cuando los parámetros de la misión exceden los parámetros especificados (coordenadas, accidente, falla de energía, falla del equipo)
8. Tener la capacidad de cambiar los parámetros de la misión mientras estás en casa
9. Tener dos canales de comunicación: telemétrico de baja velocidad y alta velocidad para la transmisión de información audiovisual. La alta velocidad debería poder habilitarse / deshabilitarse mediante un comando de telemetría.

En base a estos requisitos, se eligió la siguiente arquitectura de solución:

La estructura del complejo robótico incluye: un centro de control (Ground Station Control), en adelante GSC .

Permite al usuario hacer lo siguiente:

• Establecer perímetro
• Planifique misiones basadas en la hora del día y la carga de la corte
• Ser capaz de monitorear robots de golf con lecturas discretas de al menos 1 minuto
• Tener la capacidad de abortar una misión.

El software GSC debería planificar las acciones de los robots de golf, mientras que los robots deberían ser bastante simples. La solución no es muy flexible, por supuesto, pero las soluciones autoconsistentes y las redes de malla no son algo que se pueda resolver en poco tiempo e incluso barato. Además, este es un enfoque típico y, por lo tanto, problemas bien conocidos. Uno o más robots de golf (Golf rover) - en lo sucesivo denominados GR .

Realiza las siguientes acciones típicas:

• Obtiene una misión cuando está a menos de 10 metros de una estación terrestre
• Cumple una misión
• En el caso de una misión típica, informa sobre un canal de telemetría con una frecuencia de al menos 1 vez por minuto.
• Regresa a la estación terrestre.
• En espera de una nueva misión
• Cada misión debe ser interrumpida por los siguientes eventos:
  
  
  • Llenado de la tolva de bolas
  • Accidente nutricional
  • Imposibilidad de movimiento (golpe de estado, obstáculo repentino)
  • Reinicio de emergencia
  • Interrupción manual de la misión.
• Cada interrupción de la misión debe transmitirse a través de telemetría convencional y canal de respaldo
• Después de la interrupción: GR regresa a la estación terrestre, si su condición lo permite

Porque puede haber 1 estaciones terrestres, pero hay muchos GR: llenar la tolva de bolas es una emergencia. Esto resuelve dos problemas a la vez: el GSC sabe con un alto grado de certeza que el robot fue a la estación y a menudo probó el canal de respaldo. También se supone que el llenado de las bolas debe tener lugar durante la misión, y si esto no es así, el GSC en algún lugar cometió un error en la planificación y esto debería solucionarse. Intuitivamente, quiero liberar el robot en un campo limpio, y cuando recoja las bolas, volverá. Pero aquí entra en juego la economía, si 1-2 personas están involucradas, es mejor que el robot se pare en la estación y comience a moverse cuando las bolas ya se han acumulado. Menos consumo de recursos y energía.

Una o más estaciones terrestres (estación terrestre) - en adelante GS.

• Carga
• Tolva de bolas
• Comunicación con GR

El esquema de todo el complejo es así:

La segunda fase es una evaluación de los riesgos y posibles problemas de todo este complejo.

Para bien, debe dar una tabla de riesgos y sus evaluaciones, pero me temo que tres hojas A4 solo causarán bostezos. Solo daré un apretón interesante:

El principal problema de todos los rovers autónomos es la tarea de obtener su posición exacta. Además, la posición debe ser realmente precisa, preferiblemente dentro de 10-15 cm. Precisamente porque este problema no puede resolverse realmente en una pequeña plataforma móvil, no hay drones agrícolas / de transporte / militares baratos y masivos.

Aunque parece que hay soluciones para los drones voladores, reutilice todo en el suelo. Pero esto en el aire 10-15 metros a la izquierda o derecha en un giro en U no resuelve casi nada, pero en el suelo dará lugar a accidentes y desastres. Además, las piedras no cambian su lugar en el aire, los animales no cruzan la carretera. Pájaros, sí, pero hay mucho más espacio en el aire.

El posicionamiento se realiza mediante el módulo GPS / GLONASS, lo que conlleva inmediatamente dos consecuencias: la precisión de posicionamiento no es demasiado grande y la velocidad de obtención de coordenadas. Coordenadas para el módulo uBlox M8N para pruebas estacionarias: 2-3 metros en buenas condiciones de recepción, 7-10 en malas condiciones climáticas y visibilidad. En general, tales errores para la tarea de recoger pelotas son incluso buenos: un rover para varias misiones capturará las pelotas más que conducir sobre rieles. Sin embargo, en este caso resulta que es imposible conducirlo cerca de obstáculos como paredes o piedras grandes y en estas áreas las bolas se acumularán. Se analizaron los sistemas de navegación óptica y ultrasónica, pero resultó que se necesitaba una gran cantidad de balizas / cámaras con geometría de campo compleja, hubo problemas con las zonas de visibilidad (el campo no siempre es tan plano como el piso en el hangar) y la estabilidad de dichos sistemas en condiciones climáticas difíciles ( lluvia, niebla). Entonces, por ahora, nuestro GPS lo es todo, pero con reservas. Además, puede aumentar la precisión del GPS de forma bastante económica: RTK, pero no resolverá el problema de la pared.

Quedó claro que el enfoque elegido, cuando el rover se arrastra a lo largo de los puntos cargados con una precisión de 5-10 metros de izquierda a derecha, requiere verificación. Subir a un tren llamado SLAM con piernas para una tarea simple parece innecesario. Si entrar en la estación a través de objetos ópticamente brillantes (Código Aruco) es claro, y cuánto requiere recursos también, entonces resolver el problema de clasificar todos los objetos posibles en el campo o encontrar los límites es una tarea completamente diferente.

Es hora de la fase 3 - Prueba de concepto

Es necesario hacer un modelo del sistema, probarlo en acción en el campo y evaluar su aplicabilidad. De acuerdo con los requisitos desarrollados, las cosas fueron mucho más divertidas:

Como rover de software, se eligió Ardurover , un software de desarrollo activo que comienza como firmware para quadcopters en Arduino. Sin embargo, hasta la fecha, admite placas Linux con un núcleo RTL, y está abierto a mejoras. En el futuro, tuve que terminarlo, por cierto, pero más bien para acelerar el trabajo que si fuera necesario.

Como cerebro del rover, se eligió BeagleBone Blue , un sistema altamente integrado para la robótica.


Una característica distintiva es el uso de chips TI Sitara / Octavo, en comparación con la misma Raspberry que hay Unidad Programable en Tiempo Real - PRU. Estos son dos núcleos separados de 200 MHz que pueden controlar el hierro en tiempo real sin distraer el núcleo principal con interrupciones, hilos y otras técnicas de magia.

Además, la plataforma cuenta inmediatamente con WiFi, Bluetooth, un conector soldado para un cable de equilibrio, un controlador para cargar baterías Li-Po, conectores USB para conectar telemetría y una computadora, conectores para servomotores, estabilizadores de potencia de 5 y 3,3 voltios, el ADC terminó inmediatamente con un canal por batería, UART múltiple. En general, toma y crea un robot.

Ardurover llegó allí no sin problemas: el uso de PRU del software en este momento solo es posible con el kernel 4.4 LTS. En los núcleos más nuevos, la programación de las PRU desde el software del usuario conduce a un error SIGBUS, después de hablar con los desarrolladores de la rama ardublue pedí un adaptador JTAG, veré cuál es la razón. Este rover no interfiere en absoluto con la vida, pero quiero una comprensión clara de cuál es el problema.

El software le permite hacer casi todos los requisitos, excepto el posicionamiento a la llegada a la base, aquí uso la cámara JeVois-A33. No enviará una señal de alarma con respecto a los eventos, pero esta es una tarea para un módulo separado con una fuente de alimentación separada, como El módulo de alimentación puede no sobrevivir a un fallo de alimentación o un buen golpe.

Queda por comprar un receptor GPS, un transmisor de radio telemétrico, un sensor de distancia ultrasónico y conectar una cámara de visión artificial. Después de soldar, conectar los conectores y una prueba de funcionamiento, resultó así:


Como centro de control, se utiliza Mission Planner .


El software no es indiscutible, debe hacerse una interfaz web decente en lugar de un cuchillo suizo con más de 100500 botones para los fanáticos de los helicópteros, pero para fines de depuración es más que adecuado. Para comunicarse con el móvil, se utiliza mucho el protocolo MAVLINK de adaptadores y software de aplicación para Java / JS. Por supuesto, me gustaría tener paquetes más pequeños en el protocolo y mantener una referencia de parámetros estándar, pero eso sería demasiado bueno.

Como base del rover, se utilizó una máquina modelo de escala 1/18 con receptor y controlador de motor separados.

Se arrojó el receptor, los conectores del servo y del controlador del motor se cablearon directamente a BeagleBone Blue, al igual que la batería.

Desde lo ridículo, recordé que cuando era niño no podía soldar nada, los mocos de estaño colgaban todo el tiempo en los sitios de soldadura y tomé el soldador no sin temor interno. Sin embargo, tan pronto como el cuchillo, el alambre y el soldador cayeron en mis manos, cosí bien la picadura, corté el aislamiento sin tocar el núcleo interno, mis manos torcieron los extremos del cable, los irradiaron y sellaron la conexión. Y luego recordé que comencé a trabajar como desarrollador integrado y durante un par de meses me puse en contacto con un soldador. Una hermosa ilustración del dicho "no beberás experiencia", en mi opinión.

Por el momento, el stand se ve así:


Como puede ver, el controlador sin carcasa y sujetadores. Desafortunadamente, ordené que se imprimiera un pseudohermobox con nylon en una impresora 3D SLS, y aún no lo han logrado. Para sacar el rover en un campo puro sin casco, un vikingo así puede caminar durante media hora al aire libre. Entonces, ya sea que termine la corrosión electroquímica, o después de un golpe de estado, se emitirá por completo. Por lo tanto, estamos esperando que la carcasa, los sellos de presión y los sujetadores cumplan con todas las reglas de amortiguación de golpes y vibraciones.

Video de detección de código de Aruco Rover



Como resultado, pasé la prueba de pokatushki en casa en control manual. Resultó que la base fue elegida no del todo bien - acelera demasiado rápido, tuve que aprender la programación del controlador del motor chino. La segunda marcha atrás en este milagro del pensamiento chino se enciende mediante dos señales de "marcha atrás": la primera activa el frenado, la segunda ya activa el retroceso. Y puede ignorarse si la señal es demasiado rápida: ahorra recursos de engranajes y motor. Tuve que terminar ardurover, tk. tales trucos no se tuvieron en cuenta en él.

Las siguientes acciones: revierta la ruta de 5 a 7 veces, elimine los registros de telemetría y las rutas GPS de las rutas. Encontré un estadio de fútbol con un campo climatizado, así que si nieva, está bien. El rover obviamente no perforará ventisqueros, de lo contrario, Faina Ranevskaya debería agregar el golf a lo largo de los ventisqueros a la lista de perversiones además del hockey sobre césped y el ballet sobre hielo. No es el entretenimiento más barato, por supuesto, pero en otro lugar de Rusia, y en noviembre, puedes encontrar hierba verde. También se ha comenzado a trabajar en la implementación del chasis con orugas, donde las velocidades son mucho más bajas (el modelo actual acelera a 20 km / h en 15 segundos) y hay un giro en U en lugar de triángulos en un parche. Lo más probable es que, en un par de semanas, ambos chasis se pongan en funcionamiento al mismo tiempo, para probar el funcionamiento del detector de obstáculos y los algoritmos de desvío.

Al final, quiero señalar que verificar soluciones en modelos a gran escala es muy rápido y económico. Muchos problemas se detectaron mucho antes y, además, hay tiempo para hacer cambios en el diseño de un robot grande mientras aún está en la etapa de diseño o prototipo. Entonces será más caro, más largo, y algo romperá algo en los nodos de enlace. Además, en tales modelos, casi todo el software necesario para las tareas se desarrolla y verifica fácilmente. Idealmente, todo lo que necesita para cambiar a otro modelo es reemplazar el protocolo del controlador del motor por uno nuevo. Bueno, es posible cambiar el modelo dinámico.

Además, el uso de soluciones especializadas y probadas ahorra mucho tiempo y energía. Inventar su propia placa de circuito de alta densidad, su propio protocolo de comunicación, software en tierra y software móvil, depurar algoritmos para evitar obstáculos y comunicarse con los controladores de motores chinos es ciertamente muy emocionante, pero en este caso puede agregar inmediatamente medio año a un camino largo y lleno de baches. Ya pasó por alguien.

Necesito tu ayuda

• Si está listo para trabajar en la versión ROS.
• Requiere la preparación de la placa de conexión del módulo para las versiones raspberry pi y orange pi
• Ayuda con las pruebas de campo de práctica, especialmente si vives en un país donde juegas activamente al golf;
• Asuntos legales, exportación del robot del país, ley de patentes, requisitos de diseño legislativo;
• Necesita ayuda con el empaque de inicio, búsqueda de inversiones. Nos estamos desarrollando bien y sin inversión, tenemos un plan de acción, se está formando un equipo. En lugar del dinero de los inversores, necesitamos más experiencia y competencia para desarrollar un proyecto comercialmente exitoso.

Estado actual del proyecto.

Estamos preparando la segunda versión del cuerpo. Dentro de una semana, el caso estará listo por moldeo al vacío, sobre esto escribiremos una publicación separada.



La parte inferior del cuerpo se hace moliendo un material compuesto.



El cuerpo y la mecánica están diseñados por NikitaKhvoryk . Hemos estado esperando durante mucho tiempo para pagar los módulos de conexión para las versiones raspberry pi y orange pi de n12eq3 . Versión con Ardupilot Vladimir Goncharov Shadow_ru

Agradecemos a Process0169 , Trif , tersuren , vasimv , vovaekb90 , Vyacheslav Soldatov, Levon Zakaryan, Sergey Pomazkin, Vladi Kuban, Karen Musaelyan, Alexey Platonov por la ayuda y el asesoramiento ofrecidos. Si quieres ayudar, escríbeme en LAN o VK , FB .

Planes:

Tenemos acuerdos preliminares sobre la colocación de un robot para pruebas en palos de golf en Rusia, Alemania, América Latina y Nueva Zelanda. En un futuro próximo, finalizaremos los algoritmos y el diseño, realizaremos pruebas en Moscú y realizaremos mejoras. Crea 5 robots y colócalos de forma gratuita en palos de golf para largas pruebas para la nueva temporada.



Gracias por leer, preguntar y criticarnos por completo.