Inicialmente, o OMower foi projetado para as interfaces de controle simples pfodApp e Modbus. O primeiro é um protocolo de texto de alto nível no qual os menus e comandos de controle são transmitidos, e o segundo é uma coisa bem conhecida, mas não muito conveniente, neste aplicativo, pois requer que o programa de controle pesquise constantemente o status de todos os sensores usados "manualmente". Portanto, foi decidido mudar gradualmente para o ROS (Robot OS), uma estrutura amplamente usada para controlar vários robôs.
No momento, o suporte ao ROS está em um estágio inicial, incluindo apenas a transmissão de informações de sensores na forma de matrizes simples (sem o uso de formatos de mensagens especializados oferecidos por muitas bibliotecas ROS), logs de depuração e controle do fluxo de comandos no formato pfodApp / Modbus, sem a possibilidade realmente controla o robô com ferramentas ROS padrão. Ou seja, para mover o robô de seu lugar ou alterar qualquer configuração interna do robô, você precisará enviar um comando de texto no formato pfodApp. Mas mesmo de forma truncada - você pode transmitir e gravar facilmente o que está acontecendo com o robô, visualizando seus movimentos nas ferramentas ROS (rviz) padrão, além de adicionar serviços para funções adicionais. Por exemplo, a oportunidade de andar na direção do modelo visual (tabuleiro de damas) fornecido pelo omower_seeker.py, para uma chegada precisa ao estacionamento.
A imagem mostra fluxos de dados no robô. Os principais serviços do ROS são executados no Orange PI Zero, preso em um slot especial na placa do robô (em uma máquina de teste, o Raspberry PI3 é usado para isso, conectado de maneira semelhante - via porta serial). Por meio da interface rosserial, o robô transmite mensagens de sensores (como / imu / orientação ou / motores / PWM), seu log de depuração no formato de texto e a saída de menus / mensagens no formato pfodApp ou Modbus para o kernel ROS, recebendo um fluxo de comandos de texto ou Modbus -queries. Dois Raspberry PI Zero adicionais vêm com fluxos de imagens das câmeras, mas, como a prática demonstrou, é impossível obter sincronização normal para o processamento de imagens estéreo com esse esquema (a qualidade é visível na imagem abaixo); portanto, uma câmera estéreo normal será substituída em breve.
O grau de integração do ROS no OMower se expandirá gradualmente, até fornecer acesso total a todas as variáveis internas do robô e a capacidade de gerenciá-lo por meio de ferramentas ROS padrão (como mensagens cmd_vel que especificam a velocidade necessária).
Vou falar um pouco mais sobre o módulo omower_seeker.py, como um exemplo do uso do ROS para adicionar funções ao OMower. Seu objetivo é bastante simples - seguir na direção do tabuleiro de xadrez, ajustando sua rota em tempo real. Esta funcionalidade será utilizada para conduzir o corta-relvas para a estação de estacionamento, onde pode carregar rapidamente as baterias. Analisando a imagem de uma das câmeras, o módulo calcula dois ângulos (o ângulo de desvio da placa do centro da câmera e o ângulo de rotação da placa em relação à perpendicular) e os transmite como um comando de texto para o módulo buscador interno (omower-seeker.h / cpp no OMower SDK).
Externamente, isso parece uma tarefa bastante simples, mas na vida real há um problema sério - a velocidade do processamento de imagens no microcomputador incorporado no robô. Como mostra a prática, a velocidade de busca de padrões em opencv na imagem ao usar o PI laranja e Raspberry Pi de potência relativamente baixa é muito baixa e instável, levando de dezenas a centenas de milissegundos a uma resolução de 640x480, que durante a condução se transforma em desvios da rota necessária, uma vez que o robô , mesmo com sua baixa velocidade, consegue girar um ângulo substancial ou percorrer uma distância relativamente grande durante esse período. Na verdade, é por isso que um tabuleiro de xadrez com um mínimo de células foi escolhido, já que outros modelos levam ainda mais tempo.
Para compensar o longo tempo de pesquisa do modelo visual, é usado um esquema de bússola - o microcontrolador robô armazena seus valores a cada 100 milissegundos, armazenando cinco amostras no último meio segundo (análises mais longas são simplesmente descartadas, pois são de pouca utilidade para uma navegação precisa). Os ângulos calculados de omower_seeker.py (que também transmite o tempo de pesquisa do modelo para o microcontrolador) são recalculados para o ângulo de rotação real usando o valor da bússola salvo, que não passa de 100 milissegundos do tempo de pesquisa, e o robô viaja nesse ângulo. Isso permite que você vá com mais ou menos precisão na direção do tabuleiro de xadrez em uma linha reta. Ou, se for ligeiramente girado em relação à perpendicular - ao longo de um arco, corrigindo o ângulo de aproximação para que fique o mais próximo possível do eixo do gabarito, pois precisamos não apenas dirigir até a placa, mas também entrar nos trilhos de guia e conectar-se aos contatos de carregamento.
O algoritmo completo de chegada à estação é implementado em três etapas. Dois pontos são definidos no campo GPS - o ponto inicial (em algum lugar no meio da área de trabalho) e o ponto em frente à estação, bem como o ângulo de rotação da estação. Depois que o robô chega do ponto inicial ao segundo e gira no ângulo desejado em direção ao tabuleiro de damas na estação, o módulo buscador entra em ação, ajustando a velocidade dos motores através do controlador PID. Se alguma das etapas falhar, ou os ângulos de desvio excederem os valores definidos, o robô cancelará a corrida e retornará ao ponto de partida novamente.
Links e vídeo:
→
OMower SDK, biblioteca para Arduino IDE e layout da placa de circuito→
Firmware pronto usando o SDK que implementa o pfodApp / Modbus e a conexão ao ROS→
pacote omower_gateway para ROS