Finalmente, publicamos el SDK prometido para el proyecto OMower (una plataforma abierta de software y hardware para robots con ruedas basada en el controlador ATSAM3X8E de 32 bits con soporte de desarrollo en Arduino IDE). El nivel de finalización del software no es muy bueno (por ejemplo, no hay clases para sensores de parachoques, lluvia y hierba, algunas funciones no están completamente depuradas), pero incluso en su forma actual, el robot puede conducir con alta precisión a través de RTK GPS, admite casi todo lo que se necesita para cortacéspedes: sonares, perímetro con cable, brújula y navegación GPS, carga desde una estación de carga o panel solar.
Mi artículo anterior sobre el proyecto OMowerEl código SDK y los archivos Kicad con el circuito y el cableado de la placa se
encuentran en el github .
Actualmente solo se admiten dos plataformas: la placa OMower v3 con controladores de motor MC33926 duales Polulu y un grupo de controladores de motor Arduino Due + IHM12A1 (máquina de prueba en un pequeño chasis de cuatro ruedas). Se puede agregar soporte Ardumower basado en Arduino Due. Es altamente deseable tener una placa IMU GY-80, sin ella, la navegación no funciona de manera simple (aunque puede hacer que un simple cortacésped maneje accidentalmente dentro del perímetro del cable).
En la nueva cuarta versión de la placa, se planea instalar una IMU MPU9250 y agregar un chip FRAM para guardar la configuración del usuario que no está en el flash interno del controlador (que se restablece cuando se recarga el firmware), bueno, se pueden almacenar todo tipo de tarjetas. Además, probablemente aumentaré los tamaños de los conjuntos de resistencia y condensador, soldar el 0402 "en la rodilla" con un secador de pelo fue un placer por debajo del promedio, y aumentar el espacio para los conectores para que pueda colocarlos con abrazaderas, no solo clavijas.
El código API está escrito en forma de un puñado de clases (archivos omower - *. H) que debe incluir como objetos en su software (y, opcionalmente, incluirlos a todos, puede tomar solo los que sean necesarios, excepto los básicos). Para simplificar la comprensión y las pruebas, se
escribió OMower_Simple, que ejecuta un conjunto bastante grande de comandos emitidos a través de pfodApp desde cualquier teléfono inteligente.
El SDK toma el control de todas las funciones de bajo nivel y funciona principalmente en las interrupciones, lo que le da al programador de software final la capacidad de escribir software independientemente de los detalles específicos de un robot en particular, y de una manera muy libre (puede escribir una máquina de estado, o simplemente puede llamar a la función de arranque del controlador y espere a que el robot alcance el punto deseado). Solo los procedimientos para llamar a las funciones de inicialización y control del viaje del robot recaen en los hombros del programador (instrucciones sobre dónde, de hecho, ir y procesar las operaciones de los sonares y otros sensores).
Para conectar dispositivos externos adicionales en la placa (y soporte en el SDK, por supuesto), hay muchos conectores externos. Por ejemplo, los servoaccionamientos estándar con una entrada PPM pueden conectar hasta cuatro piezas (o incluso seis si rechaza dos motores). Hay muchos sensores "estándar" para el cortacésped, hay hasta seis de estos sonares y cuatro de los sensores perimetrales. Por supuesto, en la mayoría de los casos, no se necesita mucho y parte de sus conectores se pueden usar para conectar algunos otros dispositivos (casi todas las salidas del microcontrolador son de salida). La parte intelectual (procesamiento RTK GPS, conectividad con wifi) es realizada por Orange PI Zero, que se instala en un conector especial.
Me disculpo de antemano por la curva y el código inacabado en algunos lugares, tuve que profundizar en otros proyectos, y surgieron muchas dificultades de todo tipo que apenas podía hacer frente. Pero aprendí muchas cosas nuevas, por ejemplo, que la curvatura de la elipse de la Tierra en nuestros lugares es de casi 40 metros, y los polos magnéticos de la Tierra deambulan decenas de kilómetros de año en año (sin tener esto en cuenta, el robot viajó de punto a punto con líneas muy curvas). A veces, parecía que estaba lanzando un cohete espacial, y no un cortacésped. :)
Bueno, como beneficio adicional, también presenté las fuentes de mi firmware para el arduino con Decawave DW1000, que organiza una mini red de estos dispositivos y permite que el robot determine su ubicación en interiores o donde RTK GPS simplemente no puede determinar sus coordenadas (con soporte para una cantidad casi infinita) etiquetas y dividir en habitaciones). Este
firmware todavía
es muy, muy crudo, pero puede ser útil para alguien.
Actualización, decidí complementar el artículo con una historia de cómo está organizado en su interior:
El usuario del SDK debe determinar todos los objetos que necesita, llamar a la función begin () para todos (inicialización de hardware, solo una vez), luego establecer los valores de sus parámetros (después de leerlos desde el flash o simplemente los valores predeterminados), llamar a init () para todos (la función puede se usa para restablecer el dispositivo del que es responsable el objeto), establezca funciones de enlace para poll10 / poll20 / poll50 (10, 20 y 50 veces por segundo) desde las cuales se deben llamar las funciones poll * () correspondientes de todos los objetos utilizados. Teóricamente, fue posible automatizar todo esto en el código del SDK, pero decidí no hacerlo debido al consumo adicional de recursos del controlador. Un ejemplo de uso debe verse en OMower_Simple.ino
Una de las clases principales es el objeto de motores (omower-motors.h), que controla los controladores de motor desde su función poll10 (). El usuario simplemente llama a roll / move (girar y andar sin navegación) o rollCourse / moveCourse (andar con navegación / corrección basado en datos de algún objeto hijo de la clase navThing que, a través de las funciones readCourseError (), proporciona el valor de la desviación de la dirección de conducción deseada )
Los derivados de navThing son objetos de las clases imu y gps (omower-imu.h y omower-gps.h), el primero es responsable de leer y convertir los datos de la brújula / acelerómetro / giroscopio en una forma conveniente (proporciona los valores de brújula e inclinación en grados en dos ejes ) El segundo: procesa los datos del GPS y dirige el objeto del motor en la dirección correcta si necesita conducir por coordenadas GPS o RTK GPS (para este último, la corrección se calcula cuando la antena no se coloca en el centro del cuerpo del robot y la corrección a corto plazo mediante sensores de odómetro). El programa de usuario es responsable de la comunicación con el receptor GPS y transmite cadenas NMEA o coordenadas listas al objeto gps.
El objeto de corte (omower-mow.h) es responsable del motor de corte y su elevador de actuador con un motor paso a paso (si lo hay). El usuario dice a qué velocidad rotar y qué altura de corte configurar.
El objeto pwmServo (omower-pwmservo.h) controla las salidas PWM-A / B / C / D / E / F / G / H (esto no puede hacerse a través de otras bibliotecas debido a posibles conflictos con los temporizadores).
El objeto de potencia (omower-power.h) es responsable de controlar los reguladores de carga y convertir los valores de ADC en voltios y amperios que todos entienden. El programa de usuario debe detectar la aparición de voltaje en los electrodos de carga y llamar a la función de encender la carga, luego recogerá los ciclos PWM de los reguladores para que coincidan con la corriente de carga.
Dado que el uso de objetos Arduin Serial * estándar puede interrumpir el manejo de interrupciones (ver más abajo), existe un objeto en serie (omower-serial.h) para leer y transmitir puertos en serie. Desafortunadamente, el mismo problema existe con los buses I2C, deben usarse usando las funciones definidas en due-i2c-block.h.
Las funciones de otros objetos son claras a partir de sus nombres, solo puede ver los comentarios en los archivos de encabezado (omower-sonars.h, omower-rtc.h, omower-current * .h, omower-odometry.h, etc.).
Ahora sobre las interrupciones en el nivel más bajo. El objeto del chasis (omower-chassis.h) configura TIM7 a 100 interrupciones por segundo. En cada interrupción, se leen 12 canales del chip MAX11617 ADC (ingresados en una matriz especial, desde donde los objetos OMower SDK leen sus valores: max11617-adc-scan.h). En cada segundo, se genera una interrupción suave para el enlace de la función poll50 (), en cada quinto - poll20 (), en cada décimo - poll10 (). Todos funcionan de forma asíncrona (lo cual es conveniente, pero impone restricciones en el uso del bus I2C, luego planeo agregar algunas transacciones / semáforos allí).
El temporizador TIM5 también está configurado para generar interrupciones con una frecuencia de 38462 hertzios. A partir de esta interrupción, todos los canales del controlador ADC interno se leen e ingresan en una matriz especial (también admite ingresar cada valor recibido para el búfer seleccionado en el búfer en anillo, lo que se hace, por ejemplo, por la clase de perímetro, filtrando estas muestras más tarde usando la transformada de Fourier).
Para generar información de depuración, existe una función de depuración () con una prioridad mínima para mostrar mensajes (es decir, mientras no se realiza la depuración, no se generará nada en la consola, pero en cualquier momento puede habilitar al menos el nivel máximo, se enviará correo no deseado). En los formatos de valores de depuración (* formato printf), se admiten números de punto flotante (a diferencia de las funciones estándar de Arduin).
Actualización: la nueva cuarta versión de la placa OMower, hasta ahora solo un circuito (esperando la fabricación de la PCB). Además incluye una brújula / acelerómetro MPU9250, 128 kilobytes de F-RAM para guardar configuraciones, mapas, puntos de referencia y otras cosas, todos los conectores con pestillos (Molex 22-11-20x3 / 10-11-20x3, compatible con la versión anterior de un 2.54- pines), traductores de nivel lógico 74HC4050 para sonares y odómetros, convertidores de potencia de 3.3 / 5 voltios más potentes (hasta tres amperios), dos salidas PWM / PPM más en conectores, líneas separadas para control independiente del segundo controlador de motor paso a paso, más condensadores de amortiguación para mayor estabilidad Grandes elementos SMD para un fácil montaje. enmiendas menores.
