Finalmente, publicamos o prometido SDK para o projeto OMower (uma plataforma aberta de software e hardware para robôs de rodas baseada no controlador ATSAM3X8E de 32 bits com suporte ao desenvolvimento no Arduino IDE). O nível de conclusão do software não é muito bom (por exemplo, não há classes para sensores de pára-choques, chuva e grama, algumas funções não são totalmente depuradas), mas mesmo em sua forma atual, o robô pode dirigir com alta precisão via RTK GPS, suporta quase tudo o que é necessário para cortadores de grama - sonares, perímetro com fio, bússola e navegação por GPS, carregamento de uma estação de carregamento ou painel solar.
Meu artigo anterior sobre o projeto OMowerO código SDK e os arquivos Kicad com o circuito e a fiação da placa
estão no github .
Atualmente, apenas duas plataformas são suportadas - OMower board v3 com drivers de motor Polulu MC33926 duplo e vários drivers de motor Arduino Due + IHM12A1 (máquina de teste em um pequeno chassi de quatro rodas). Suporte ao Ardumower baseado no Arduino Due pode ser adicionado. É altamente desejável ter uma placa IMU GY-80, sem ela, a navegação não funciona de maneira simples (embora você possa fazer um cortador de grama simples que acidentalmente conduz dentro do perímetro do fio).
Na nova quarta versão da placa, está planejado instalar uma IMU MPU9250 nela e adicionar um chip FRAM para salvar as configurações do usuário não no flash interno do controlador (que é redefinido quando o firmware é recarregado), bem, todos os tipos de placas podem ser armazenados nela. Além disso, provavelmente aumentarei o tamanho dos conjuntos de resistores e capacitores, soldar o 0402 “no joelho” com um secador de cabelo foi um prazer abaixo da média e aumentarei o espaço dos conectores para que você possa colocar aqueles com grampos, e não apenas com pinos.
O código da API é gravado na forma de um punhado de classes (arquivos omower - *. H) que você precisa incluir como objetos em seu software (e, opcionalmente, incluir todos eles, você pode usar apenas aqueles que são necessários, exceto os básicos). Para simplificar a compreensão e o teste, foi
escrito o OMower_Simple, que executa um conjunto bastante grande de comandos emitidos via pfodApp a partir de qualquer smartphone.
O SDK controla todas as funções de baixo nível e trabalha principalmente com interrupções, o que dá ao programador final de software a capacidade de escrever software independentemente dos detalhes específicos de um robô em particular e de maneira muito livre (você pode escrever uma máquina de estado ou simplesmente chamar a função de acionamento de partida) e aguarde o robô atingir o ponto desejado). Somente os procedimentos para chamar as funções de inicializar e controlar o percurso do robô caem sobre os ombros do programador (instruções sobre onde, de fato, ir e processar as operações de sonares e outros sensores).
Para conectar dispositivos externos adicionais na placa (e suporte no SDK, é claro) - existem muitos conectores externos. Por exemplo, servoconversores padrão com uma entrada PPM podem conectar até quatro peças (ou até seis, se você recusar dois motores). Existem muitos sensores "padrão" para o cortador de grama; existem seis desses sonares e quatro dos sensores de perímetro. Obviamente, na maioria dos casos, não é necessário muito e parte de seus conectores pode ser usada para conectar outros dispositivos (quase todas as saídas do microcontrolador são produzidas). A parte intelectual (processamento de RTK GPS, conectividade com wifi) é realizada pelo Orange PI Zero, que é instalado em um conector especial.
Peço desculpas antecipadamente pela curva e pelo código inacabado em alguns lugares, tive que cavar em outros projetos e surgiram muitas dificuldades de todos os tipos que mal conseguia lidar. Mas eu aprendi muitas coisas novas, por exemplo, que a curvatura da elipse da Terra em nossos lugares é quase 40 metros, e os pólos magnéticos da Terra vagam dezenas de quilômetros de ano para ano (sem levar isso em conta, o robô viajava de um ponto a outro com linhas muito curvas). Às vezes, parecia que eu estava lançando um foguete espacial, e não um gramado. :)
Bem, como bônus, também expus as fontes do meu firmware para o arduino com o Decawave DW1000, que organiza uma mini-rede desses dispositivos e permite que o robô determine sua localização em ambientes fechados ou onde o RTK GPS simplesmente não pode determinar suas coordenadas (com suporte para uma quantidade quase infinita) etiquetas e dividir em salas). Este
firmware ainda
é muito, muito cru, mas pode ser útil para alguém.
Atualização, decidi complementar o artigo com uma história de como ele é organizado dentro:
O usuário do SDK deve determinar todos os objetos de que precisa, chamar a função begin () para todos (inicialização de hardware, apenas uma vez) e definir os valores de seus parâmetros (depois de lê-los a partir do flash ou apenas os valores padrão), chamar init () para todos (a função pode usado para redefinir o dispositivo pelo qual o objeto é responsável), defina as funções de gancho para poll10 / poll20 / poll50 (10, 20 e 50 vezes por segundo) a partir do qual as funções poll * () correspondentes de todos os objetos usados devem ser chamadas. Teoricamente, era possível automatizar tudo isso no código do SDK, mas decidi não fazer isso por causa do consumo adicional de recursos do controlador. Um exemplo do uso que você precisa olhar para OMower_Simple.ino
Uma das principais classes é o objeto motores (omower-motors.h), que controla os drivers de motor a partir de sua função poll10 (). O usuário simplesmente chama o roll / move (rodar e rodar sem navegação) ou rollCourse / moveCourse (rodar com navegação / correção com base nos dados de algum objeto filho da classe navThing que, através das funções readCourseError (), fornece o valor do desvio da direção de direção desejada )
Derivadas do navThing são objetos das classes imu e gps (omower-imu.he omower-gps.h), o primeiro é responsável pela leitura e conversão dos dados da bússola / acelerômetro / giroscópio em uma forma conveniente (fornece valores de bússola e inclinação em graus em dois eixos) ) O segundo - processa os dados do GPS e direciona o objeto dos motores na direção certa, se você precisar dirigir pelas coordenadas GPS ou RTK GPS (para o último, a correção é calculada quando a antena é colocada não no centro do corpo do robô e a correção a curto prazo por sensores odométricos). O programa do usuário é responsável pela comunicação com o próprio receptor GPS e transmite seqüências NMEA ou coordenadas prontas para o objeto gps.
O objeto de corte (omower-mow.h) é responsável pelo motor de cisalhamento e seu atuador com um motor de passo (se houver). O usuário diz em que velocidade girar e qual altura de corte definir.
O objeto pwmServo (omower-pwmservo.h) controla as saídas PWM-A / B / C / D / E / F / G / H (isso não pode ser feito por outras bibliotecas devido a possíveis conflitos com temporizadores).
O objeto de energia (omower-power.h) é responsável por controlar os reguladores de carga e converter os valores ADC em volts e amperes que todos entendem. O programa do usuário deve detectar a ocorrência de tensão nos eletrodos de carregamento e chamar a função de ligar o carregamento. Em seguida, ele seleciona os ciclos PWM dos reguladores para corresponder à corrente de carregamento.
Como o uso de objetos padrão do Arduin Serial * pode interromper o tratamento de interrupções (veja abaixo), existe um objeto serial (omower-serial.h) para ler e transmitir portas seriais. Infelizmente, o mesmo problema existe com os barramentos I2C, eles devem ser usados usando as funções definidas em due-i2c-blocking.h.
As funções de outros objetos são claras a partir de seus nomes; você pode apenas assistir os comentários nos arquivos de cabeçalho (omower-sonars.h, omower-rtc.h, omower-current * .h, omower-odometry.h, etc.).
Agora, sobre interrupções no nível mais baixo. O objeto do chassi (omower-chassis.h) configura o TIM7 a 100 interrupções por segundo. A cada interrupção, 12 canais do chip MAX11617 ADC são lidos (inseridos em uma matriz especial, de onde os objetos do OMower SDK leem seus valores - max11617-adc-scan.h). A cada segundo - é gerada uma interrupção suave para o gancho da função poll50 (), a cada quinta - poll20 (), a cada décima - poll10 (). Todos eles funcionam de forma assíncrona (o que é conveniente, mas impõe restrições ao uso do barramento I2C, mais tarde pretendo adicionar algumas transações / semáforos).
O timer TIM5 também está configurado para gerar interrupções com uma frequência de 38462 hertz. A partir dessa interrupção, todos os canais do controlador ADC interno são lidos e inseridos em uma matriz especial (também suporta a inserção de cada valor recebido para o buffer selecionado no buffer de anel, o que é feito, por exemplo, pela classe de perímetro, filtrando essas amostras posteriormente usando a transformada de Fourier).
Para gerar informações de depuração, existe uma função debug () com prioridade mínima para a exibição de mensagens (ou seja, enquanto a depuração não é executada, nada será gerado no console, mas a qualquer momento você pode ativar pelo menos o nível máximo, será enviado um spam). Nos formatos dos valores de depuração (* formato printf), os números de ponto flutuante são suportados (ao contrário das funções padrão do Arduin).
Atualização: A nova quarta versão da placa OMower, até agora apenas um circuito (aguardando a fabricação do PCB). Além disso, inclui uma bússola / acelerômetro MPU9250, 128 kilobytes de F-RAM para salvar configurações, mapas, waypoints e outras coisas, todos os conectores com travas (Molex 22-11-20x3 / 10-11-20x3, compatível com a versão antiga da versão 2.54- pinos), tradutores de nível lógico 74HC4050 para sonares e odômetros, conversores de potência de 3,3 / 5 volts mais potentes (até três amperes), mais duas saídas PWM / PPM nos conectores, linhas separadas para controle independente do segundo driver do motor de passo, mais capacitores de buffer para estabilidade Elementos SMD grandes para facilitar a montagem pequenas alterações.
