Projetando um robô de serviço. Declaração do problema, arquitetura da solução

Nós, com uma equipe (da qual você pode se juntar ) de pessoas com idéias semelhantes da Habr, estamos desenvolvendo um robô para coletar bolas de golfe no driving range .



Vladimir Goncharov Shadow_ru fala sobre coletar requisitos, formular tarefas para o trabalho, desenvolver uma arquitetura e criar um protótipo para a execução de software.



O projeto começou para mim, com a coleta de requisitos, generalização e subsequente decomposição das subtarefas. A tarefa do robô à primeira vista é simples, mas os erros no estágio de planejamento estragam muito o resultado do trabalho e nem sempre são visíveis imediatamente; portanto, pular esse estágio é o caminho para lugar nenhum.

Resumir os requisitos simplifica a comunicação com outros membros da equipe - é desenvolvido um entendimento comum do problema, a situação em que cada robô em sua cabeça não surge mais. Além disso, quando um novo membro entra na equipe, é suficiente ler um documento semelhante, o que reduz o tempo para a fase de entrada.

Sempre há um equilíbrio entre coletar requisitos e generalizações - quero descrever em mais detalhes, mas se você não é um advogado acostumado a trabalhar com centenas de parágrafos relacionados - isso não resolverá o problema de visão geral. Obviamente, existe a abordagem correta quando várias fatias de requisitos são feitas para diferentes membros da equipe e clientes e contratados externos. Mas, por enquanto, isso é claramente desnecessário, porque Cada alteração nos requisitos levará a um sério investimento de tempo para atualizar essas fatias, o que não afeta muito a produtividade da inicialização.

Decidi dividir em requisitos funcionais e não funcionais e colocar tudo em uma página A4. A primeira versão saiu assim:

Fase 1. Declaração do problema

Desafio: É necessário um desvio máximo contínuo de um campo de golfe de treinamento em condições climáticas difíceis para a coleta de bolas.

Problema: Um veículo terrestre não tripulado ( UGV ) é necessário para executar missões cíclicas para contornar o espaço definido pelo perímetro com as coordenadas dos pontos na notação WGS-84.

As missões devem incluir as seguintes operações:

1. Início normal a partir de uma posição inicial conhecida
2. Início de emergência a partir de uma posição desconhecida (início após operação WD, proteção de energia, etc.)
3. Evitar uma área com uma cobertura de pelo menos 98% do espaço para 1 ou mais corridas (é desnecessário começar a contornar o campo novamente depois de encher a caçamba após 15 minutos)
4. Volte à posição inicial para encher a tremonha, drenar a bateria, terminar o desvio
5. Corra na plataforma de lançamento para zerar as bolas, carregar as baterias

Versão simplificada do algoritmo



Além disso, a UGV deve atender aos seguintes requisitos:

1. Não deixe o perímetro especificado ao dirigir ao redor do perímetro especificado
2. A posição inicial pode estar fora do perímetro especificado.
3. Monitore o consumo da bateria e planeje um retorno com base na energia consumida. Mover uma tremonha cheia requer mais energia da bateria do que uma vazia.
4. Mantenha registros de telemetria, incluindo, mas não limitado a, coordenadas no plano, valores de 6 eixos de rotação, nível de sinal de telemetria e sensores externos.
5. Possuir três sistemas de posicionamento - GPS para obter coordenadas grosseiras, IMU para verificação e correção de coordenadas no avião, óptico para posicionamento preciso por marcadores.
6. Tenha dois sistemas Watch Dog - software e hardware. O software verifica o status
7. Possuir um canal de comunicação de emergência de longo alcance com fonte de alimentação separada, usada quando os parâmetros da missão excederem os parâmetros especificados (coordenadas, acidente, falha de energia, falha do equipamento)
8. Ter a capacidade de alterar os parâmetros da missão enquanto estiver em casa
9. Ter dois canais de comunicação - telemetria de baixa velocidade e alta velocidade para a transmissão de informações audiovisuais. A alta velocidade deve poder ativar / desativar pelo comando de telemetria.

Com base nesses requisitos, a seguinte arquitetura de solução foi escolhida:

A estrutura do complexo robótico inclui: um centro de controle (Ground Station Control) - a seguir GSC .

Permite que o usuário faça o seguinte:

• Definir perímetro
• Planejar missões com base na hora do dia e na carga da corte
• Ser capaz de monitorar robôs de golfe com leituras discretas de pelo menos 1 minuto
• Ter a capacidade de abortar uma missão

O software GSC deve planejar as ações dos robôs de golfe, enquanto os próprios robôs devem ser bastante simples. A solução não é muito flexível, é claro, mas soluções autoconsistentes e redes de malha não são algo que pode ser resolvido em pouco tempo e até barato. Plus - esta é uma abordagem típica e, portanto, problemas bem conhecidos. Um ou mais robôs de golfe (Golf rover) - a seguir denominado GR .

Executa as seguintes ações típicas:

• Obtém uma missão quando a 10 metros de uma estação terrestre
• Cumpre uma missão
• No caso de uma missão típica, informa um canal de telemetria com uma frequência de pelo menos 1 vez por minuto
• Retorna à estação terrestre
• Aguardando nova missão
• Cada missão deve ser interrompida pelos seguintes eventos:
  
  
  • Enchimento do funil de esferas
  • Acidente de nutrição
  • Impossibilidade de movimento (golpe, obstáculo repentino)
  • Reinício de emergência
  • Interrupção manual da missão
• Cada interrupção de missão deve ser transmitida via canal convencional de telemetria e backup
• Após a interrupção - GR retorna à estação terrestre, se sua condição permitir

Porque pode haver 1 estação terrestre, mas existem muitos GRs - encher o depósito de bolas é uma emergência. Isso resolve dois problemas ao mesmo tempo - o GSC sabe com um alto grau de certeza que o robô foi à estação e frequentemente testou o canal de backup. Supõe-se também que o preenchimento das bolas deve ocorrer durante a missão e, se não for assim, o GSC em algum lugar cometeu um erro no planejamento e isso deve ser corrigido. Intuitivamente, quero liberar o robô em um campo limpo e, quando ele recolhe as bolas, ele retorna. Mas aqui a economia entra em jogo: se houver 1-2 pessoas envolvidas, é melhor o robô ficar na estação e começar a se mover quando as bolas já estiverem acumuladas. Menos consumo de recursos e energia.

Uma ou mais estações terrestres (Estação Terrestre) - a seguir GS.

• A carregar
• Tremonha de esferas
• Comunicação com GR

O esquema de todo o complexo é assim:

A segunda fase é uma avaliação dos riscos e possíveis problemas de todo esse complexo.

Para sempre, você precisa fornecer uma tabela de riscos e suas avaliações, mas receio que três folhas A4 causem apenas bocejos. Vou dar apenas um aperto interessante:

O principal problema de todos os rovers autônomos é a tarefa de obter sua posição exata. Além disso, a posição deve ser realmente precisa - de preferência entre 10 e 15 cm. Precisamente porque esse problema não pode ser realmente resolvido em uma pequena plataforma móvel, não há drones agrícolas / de transporte / militares baratos e maciços.

Embora pareça que existem soluções para drones voadores, reutilize tudo no chão. Mas isso no ar, de 10 a 15 metros para a esquerda ou direita, em uma inversão de marcha, não resolve quase nada, mas no solo isso leva a acidentes e desastres. Além disso, as pedras não mudam de lugar no ar, os animais não atravessam a rua. Pássaros, sim, mas há muito mais espaço no ar.

O posicionamento é realizado pelo módulo GPS / GLONASS, o que imediatamente leva a duas consequências: a precisão do posicionamento não é muito grande e a velocidade de obtenção de coordenadas. Coordenadas do módulo uBlox M8N para testes estacionários: 2-3 metros em boas condições de recepção, 7 a 10 em más condições climáticas e visibilidade. Em geral, esses erros para a tarefa de coletar bolas são até bons - um rover para várias missões capturará as bolas mais do que dirigir sobre trilhos. No entanto, neste caso, é impossível conduzi-lo perto de obstáculos, como paredes ou pedras grandes, e nessas áreas as bolas se acumulam. Os sistemas de navegação óptica e ultrassônica foram analisados, mas descobriu-se que era necessário um grande número de faróis / câmeras com geometria de campo complexa, havia problemas com zonas de visibilidade (o campo nem sempre é tão plano quanto o piso do hangar) e a estabilidade de tais sistemas em condições climáticas difíceis ( chuva, nevoeiro). Por enquanto, nosso GPS é tudo, mas com reservas. Além disso, você pode aumentar a precisão do GPS de forma barata - RTK, mas isso não resolverá o problema da parede.

Tornou-se claro que a abordagem escolhida, quando o veículo espacial se arrasta ao longo dos pontos carregados com uma precisão de 5 a 10 metros esquerda-direita, requer verificação. Subir em um trem chamado SLAM com pernas para uma tarefa simples parece desnecessário. Se a entrada na estação através de objetos opticamente brilhantes (Código Aruco) é clara e quanto requer recursos também, resolver o problema de classificar todos os objetos possíveis no campo ou encontrar os limites é uma tarefa completamente diferente.

Chegou a hora da fase 3 - Prova de conceito

É necessário fazer um modelo do sistema, testá-lo em ação no campo e avaliar sua aplicabilidade. De acordo com os requisitos desenvolvidos, as coisas foram muito mais divertidas:

Como um software rover, Ardurover foi escolhido - um software em desenvolvimento ativo que inicia como firmware para quadcopters no Arduino. No entanto, até o momento, ele suporta placas Linux com um núcleo RTL e está aberto a melhorias. No futuro, eu tinha que terminar, aliás, mas acelerar o trabalho, se necessário.

Como o cérebro do veículo espacial , foi escolhido o BeagleBone Blue - um sistema altamente integrado para robótica.


Uma característica distintiva é o uso dos chips TI Sitara / Octavo, em comparação com o mesmo Raspberry existente na Unidade de Tempo Real Programável - PRU. Estes são dois núcleos separados de 200 MHz que podem controlar o ferro em tempo real sem distrair o núcleo principal com interrupções, threads e outras tecno-mágicas.

Além disso, a plataforma possui Wi-Fi, Bluetooth, um conector soldado para um cabo de balanceamento, um controlador para carregar baterias Li-Po, conectores USB para conectar telemetria e um computador, conectores para servomotores, estabilizadores de potência de 5 e 3,3 volts, o ADC termina imediatamente com um canal por bateria, UART múltiplo. Em geral, pegue e faça um robô.

Ardurover chegou lá sem problemas - o uso da PRU do software no momento é possível apenas com o kernel 4.4 LTS. Nos kernels mais recentes, a programação de PRUs a partir do software do usuário leva a uma falha do SIGBUS. Depois de conversar com os desenvolvedores do ramo ardublue, pedi um adaptador JTAG, verei qual é o motivo. Este veículo espacial não interfere na vida, mas quero uma compreensão clara de qual é o problema.

O software permite que você cumpra quase todos os requisitos, exceto o posicionamento na chegada à base, aqui eu uso a câmera JeVois-A33. Ele não enviará um sinal de alarme referente a eventos, mas esta é uma tarefa para um módulo separado com fonte de alimentação separada, como O módulo de energia pode não sobreviver a uma falha de energia ou a um bom golpe.

Resta comprar um receptor GPS, um transmissor de rádio telemétrico, um sensor de distância ultrassônico e conectar uma câmera de visão por computador. Após a solda, conectando os conectores e um teste, ficou assim:


Como centro de controle, o Mission Planner é usado .


O software não é indiscutível, uma interface da Web decente em vez de uma faca suíça com mais de 100500 botões para fãs de helicópteros deve ser feita, mas, para fins de depuração, é mais do que adequada. Para se comunicar com o rover, o protocolo MAVLINK de adaptadores e software aplicativo para Java / JS é usado, muito foi escrito. Obviamente, eu gostaria de ter pacotes menores no protocolo e manter uma referência de parâmetro padrão, mas isso seria bom demais.

Como base do rover, uma máquina modelo de escala 1/18 foi usada com receptor e controlador de motor separados.

O receptor foi jogado fora, os conectores do servo e do controlador do motor foram conectados diretamente ao BeagleBone Blue, assim como a bateria.

Pelo engraçado - lembrei-me de que, quando criança, eu não conseguia soldar, o ranho de estanho pendia o tempo todo nos locais de solda e peguei o ferro de soldar sem trepidação interna. No entanto, assim que a faca, o fio e o ferro de soldar caíram em minhas mãos, costurei bem o ferrão, cortei o isolamento sem tocar no núcleo interno, minhas mãos torceram as extremidades do cabo, irradiaram-nos e selaram a conexão. Lembrei-me de que comecei a trabalhar como desenvolvedor incorporado e, por alguns meses, entrei em contato com um ferro de soldar. Uma bela ilustração do ditado "você não bebe experiência", na minha opinião.

No momento, o estande fica assim:


Como você pode ver - o controlador sem caixa e parafusos. Infelizmente, pedi uma pseudohermobox para ser impressa com nylon em uma impressora 3D SLS, e eles ainda não conseguiram fazê-lo. Para trazer o veículo espacial em um campo puro sem casco - um Viking assim pode andar por meia hora ao ar livre. Então a corrosão eletroquímica termina ou, após um golpe de golpe, será completamente emitida. Portanto, aguardamos a carcaça, as vedações de pressão e os prendedores, de acordo com todas as regras de amortecimento de choques e vibrações.

Vídeo de detecção do Aruco Code Rover



Como resultado, passei o teste pokatushki em casa no controle manual. Aconteceu que a base foi escolhida incorretamente - ela acelera muito rapidamente, tive que aprender a programação do controlador de motor chinês. A segunda - marcha à ré neste milagre do pensamento chinês é ativada por dois sinais de retorno - a primeira aciona a frenagem, a segunda já aciona a marcha à ré. E pode ser ignorado se o sinal for muito rápido - economiza o recurso de marchas e motor. Eu tive que terminar ardurover, tk. tais truques não foram levados em consideração.

As ações a seguir - reverter a rota de 5 a 7 vezes, remover registros de telemetria e rastreamentos de rotas GPS. Eu encontrei um estádio de futebol com um campo aquecido, então se neva, tudo bem. Rover obviamente não estará perfurando montes de neve, caso contrário Faina Ranevskaya teria acrescentado golfe ao longo dos montes à lista de perversões, além de hóquei em campo e balé de gelo. Não é o entretenimento mais barato, é claro, mas onde mais na Rússia e em novembro você pode encontrar grama verde. Também começaram os trabalhos de implementação de chassis rastreados, onde as velocidades são muito mais baixas (o modelo atual acelera para 20 km / h em 15 segundos) e há uma inversão de marcha no lugar, em vez de triângulos em um patch. Provavelmente, em algumas semanas, os dois chassis serão executados ao mesmo tempo, para testar a operação do algoritmo do detector de obstáculos e do desvio.

No final, quero observar que a verificação de soluções em modelos em larga escala é muito rápida e barata. Muitos problemas foram detectados muito antes e, além disso, há tempo para fazer alterações no design de um robô grande enquanto ele ainda está no estágio ou no protótipo do design. Então, será mais caro, mais longo, e algo quebrará algo nos nós de ligação. Além disso, nesses modelos, quase todo o software necessário para tarefas é facilmente desenvolvido e verificado. Idealmente, tudo o que você precisa para mudar para outro modelo é substituir o protocolo do controlador do mecanismo por um novo. Bem, é possível mudar o modelo dinâmico.

Além disso, o uso de soluções especializadas e comprovadas economiza muito tempo e energia. Inventar sua própria placa de circuito de alta densidade, seu próprio protocolo de comunicação, software baseado em terra e software rover, depurar algoritmos de prevenção de obstáculos e comunicação com controladores de motores chineses é certamente muito emocionante, mas nesse caso você pode adicionar imediatamente meio ano a um caminho longo e acidentado. Já passou por alguém.

Preciso da sua ajuda:

• Se você estiver pronto para trabalhar na versão ROS.
• Requer preparação da placa de conexão do módulo para as versões raspberry pi e orange pi
• Ajuda nos testes do driving range, especialmente se você mora em um país onde joga ativamente golfe;
• Questões legais, exportação do robô do país, lei de patentes, requisitos de projeto legislativo;
• Precisa de ajuda com o empacotamento de inicialização, pesquisa de investimento. Estamos desenvolvendo bem e sem investimento, temos um plano de ação, uma equipe está sendo formada. Em vez de dinheiro do investidor, precisamos de mais experiência e competência no desenvolvimento de um projeto comercialmente bem-sucedido.

Status atual do projeto

Estamos preparando a segunda versão do corpo. Dentro de uma semana, o gabinete estará pronto por moldagem a vácuo; sobre isso, escreveremos um post separado.



A parte inferior do corpo é feita fresando um material compósito.



O corpo e a mecânica são projetados por NikitaKhvoryk . Estamos aguardando há muito tempo para pagar os módulos de conexão para as versões raspberry pi e orange pi da n12eq3 . Versão com Ardupilot Vladimir Goncharov Shadow_ru

Agradecemos a Process0169 , Trif , Tersuren , Vasimv , vovaekb90 , Vyacheslav Soldatov, Levon Zakaryan, Sergey Pomazkin, Vladi Kuban, Karen Musaelyan, Alexey Platonov e Karen oferecido pela ajuda. Se você quiser ajudar - por favor escreva-me na LAN ou VK , FB .

Planos:

Temos acordos preliminares sobre a colocação de um robô para testes em tacos de golfe na Rússia, Alemanha, América Latina e Nova Zelândia. Em um futuro próximo, finalizaremos os algoritmos e o design, realizaremos testes em Moscou e faremos melhorias. Crie 5 robôs e coloque-os gratuitamente em tacos de golfe para longos testes para a nova temporada.



Obrigado pela leitura, pergunte e nos critique completamente.