Uma transcrição detalhada de outro relatório da reunião Yandex.Zhelezo - sobre o desenvolvimento de dispositivos para UAVs.
- Olá pessoal, meu nome é Vitaly Podkolzin, sou o chefe do desenvolvimento de sistemas embarcados para o projeto de veículos não tripulados. E hoje eu gostaria de conversar com você sobre o que é um carro não tripulado, quais componentes estão incluídos em sua composição, como fazer o carro se mover e como o piloto automático e seus componentes funcionam dependem dos dispositivos usados.
Para entender para onde ir a seguir, uma pessoa precisa primeiro descobrir onde está. Um carro não tripulado também. Por isso, o subsistema de localização é responsável por nós. Então você precisa entender o que está acontecendo ao nosso redor. O sistema de percepção ou percepção é responsável por nossa visão, percepção do mundo. Com base nos dados de localização, sobre objetos à nossa volta, podemos fazer previsões sobre a situação da estrada, seu desenvolvimento, o comportamento dos usuários da estrada. E escolha a melhor rota de movimento, trajetória, transformando-a ainda mais em uma ação de controle.
Mas todos os itens acima são, no caso geral, algoritmos. E você poderia executar esses algoritmos no seu computador, se fossem poderosos o suficiente. Obviamente, isso não faria um carro não tripulado de um computador. Faltam duas coisas importantes.
O primeiro é um conjunto bastante rico de sensores, os principais listados no slide. E, claro, precisamos de uma plataforma que execute nossos comandos. Você precisa interagir com ela.
Vamos nos concentrar na questão da interação com o carro. O piloto automático, como uma pessoa, precisa fazer coisas simples para dirigir um carro: girar o volante, acelerar, diminuir a velocidade. Uma solução lógica pode parecer usar atuadores para controlar esses corpos.
Mas essa abordagem tem várias dificuldades significativas. O desenvolvimento de um veículo não tripulado ainda implica a presença de um motorista em determinadas etapas - você precisa levar o carro para um serviço ou monitorar o piloto automático quando testamos vários recursos, especialmente nos estágios iniciais. Esses dispositivos complicam significativamente a vida do motorista.
Obviamente, todo o sistema é complexo e, em geral, essa mecânica pode introduzir atrasos desagradáveis nos controles. Isso afeta negativamente o circuito de controle do veículo.
Sim, ainda precisávamos de uma plataforma simples no início do projeto, mas precisávamos de outra abordagem para interagir com essa plataforma. E começamos a cavar fundo no carro.
Tendo estudado os recursos de diferentes plataformas, descobrimos que muitos carros modernos têm a capacidade de controlar seus próprios órgãos. Por exemplo, um assistente controla o volante durante o estacionamento. O controle de cruzeiro afeta a aceleração do carro, o controle de cruzeiro adaptativo ou um sistema de limite de velocidade pode afetar o sistema de freios.
Todos esses sistemas, em regra, estão fechados em carros. E para interagir com eles, foi necessário o desenvolvimento de vários dispositivos especializados. Além de interagir com o carro, o sistema precisava fornecer uma interface conveniente e fácil de usar para dirigir o carro. E, é claro, o sistema deveria ter sido simples, direto e muito flexível.
Chegamos a uma plataforma em que, dependendo do carro, são desenvolvidas pequenas placas de controle que interagem com um nó específico. A composição e a funcionalidade dessas placas diferem de plataforma para plataforma, mas todas se reúnem em uma rede, onde há uma unidade principal, que convencionalmente chamamos de gateway. Ele monitora esses dispositivos. Além disso, o gateway fornece uma interface para o piloto automático em dispositivos convenientes. Aqui vemos a Ethernet, conveniente para nossa infraestrutura, e CAN, a interface automotiva mais popular. Além disso, nossa unidade principal interage constantemente com o carro, monitora o status de componentes e montagens. Se algum desvio for detectado, então, dependendo de sua natureza, juntamente com o piloto automático, uma decisão será tomada em outras etapas.
Decidimos implementar a placa em microcontroladores bastante populares e comprovados. Pegamos eles com uma margem de desempenho e escolhemos aqueles que suportam as interfaces necessárias para o trabalho: CAN, Ethernet e entradas / saídas digitais analógicas.
Temos uma solução que realmente se mostrou flexível para nós e que nos permitiu mudar de plataforma para plataforma com menos problemas.
Vamos falar sobre sensores. Cada veículo não tripulado possui um rico conjunto de sensores. Cada veículo não tripulado Yandex possui quatro lidares no teto e três na frente, seis câmeras colocadas no teto e seis radares: dois na traseira e quatro na frente, dois dos quais localizados nas laterais.
Tomamos radares, lidares, câmeras, conectamos, dirigimos para o computador. Mas não é tão simples. É muito importante garantir que os dados do sensor sejam adequados e de alta qualidade. Realizamos um grande número de experimentos para entender onde colocar os sensores, para que possamos ver o mundo melhor e mais claramente.
Além disso, nossos projetistas tiveram que trabalhar duro para garantir que todas as alterações no carro relacionadas aos sensores atendessem aos requisitos dos organismos de certificação.
Aqui está o que aconteceu. Seis câmeras no teto oferecem uma boa visão de 360 graus com sobreposição significativa - áreas escuras são marcadas no slide. Essas câmeras também oferecem uma boa visão vertical. A câmera é o único sensor que vê semáforos, pois eles podem estar localizados em diferentes partes, dependendo do cruzamento e outras coisas.
Os radares são outro sensor importante para todos os carros. Eles são interessantes por terem um ângulo de visão não muito amplo, mas uma boa variedade. Dois radares frontais desempenham a função de monitorar o que está acontecendo à frente; os radares traseiros em nossos algoritmos são usados, regra geral, na reconstrução, ultrapassagens e manobras semelhantes. Os radares que olham de lado são necessários para atravessar cruzamentos bastante complexos, onde as informações dos sensores podem não ser suficientes.
Provavelmente o sensor mais interessante é o lidar. Ele está interessado nas informações que vêm dele. Aqui está uma nuvem de pontos, nuvem de pontos, são dados de lidares. Eles mostram pedestres, carros, a estrada, até as bordas da estrada e outros objetos. As caixas já são o resultado do trabalho de nossos algoritmos de reconhecimento.
No total, todos os sensores apresentam aproximadamente a mesma imagem. Como você pode ver, é impossível não notar nada ao redor do carro com esse conjunto de sensores.
Gostaria de me debruçar sobre dois exemplos que encontramos quando precisávamos desenvolver hardware. Vou começar com o caso de localização.
A principal fonte são os cartões de alta definição. A cada momento, um veículo não tripulado compara os dados dos lidares com esses cartões. Com base nessa comparação, ele obtém sua localização com precisão de centímetros. O GPS, Glonass ou qualquer outra navegação por satélite simplesmente não é adequado para trabalhar com um veículo não tripulado devido à sua baixa estabilidade, alta dependência de condições externas, clima, ruído, interferência. Na cidade, tudo isso é significativamente complicado por sobreposições de sinal, reflexões de prédios etc. Mas onde conseguimos esses cartões? Nós mesmos construímos mapas, usando nossos veículos não tripulados com um conjunto de sensores.
Para construir esses mapas, precisamos de lidares e algum tipo de referência no terreno. Você precisa de alguma forma obter sua coordenada. O GPS poderia inicialmente fornecer uma coordenada, mas sua precisão não é muito alta. Como eu disse, a precisão do GPS é afetada pelas condições atmosféricas, interferências e na cidade também há reflexos.
A tecnologia cinemática em tempo real vem em socorro. A linha inferior é: em algum lugar no solo, uma estação base fixa é instalada com o mesmo dispositivo receptor que um carro. Se a distância entre o carro e a estação base não exceder 30 km (em alguns casos 50 km), os dados de satélite recebidos pelo carro e pela estação base serão aproximadamente semelhantes. Mas a estação base, sabendo sua coordenada exata (é estacionária) e calculando a coordenada de acordo com os dados do satélite, recebe, condicionalmente, um erro de cálculo. Com base nesse erro, são desenvolvidas alterações que são enviadas via carro para o carro via Internet. O carro, levando em consideração as correções recebidas ao calcular as coordenadas por satélites, obtém sua coordenada com precisão centimétrica. Obviamente, para trabalhar com este sistema, você precisa de um bom canal na Internet e de um bom clima para que o sinal do GPS seja estável.
Para obter um dispositivo operacional com suporte a RTK em um carro ou estação base, você precisa de um software. Bibliotecas que fornecem recursos RTK RTKLib estão disponíveis ao público. Existem diferentes variações com diferentes recursos. As bibliotecas normalmente exigem um ambiente Linux e módulos de navegação por satélite que fornecem dados brutos.
Após realizar algumas experiências, criar protótipos de algumas coisas, obtivemos um diagrama de blocos do bloco de localização, que chamamos de GeoHub.
Além do módulo de navegação por satélite especificado, há também um módulo de medições inerciais, que usamos no sistema de localização. A Internet está chegando agora através da interface Ethernet, conveniente para nossa infraestrutura.
Aqui está o segundo dispositivo, sua segunda geração e as principais características técnicas.
Substituímos o módulo de medição inercial e o módulo de sinal de satélite. Como resultado, nos permitiu realizar uma série de experimentos em um carro e escolher o módulo de medição inercial ideal do ponto de vista de vários parâmetros, e quanto ao módulo de sinal de satélite, fomos capazes de mudar para um receptor de banda dupla no processo, o que melhorou significativamente a qualidade da determinação da localização.
Por que desenvolver seu dispositivo quando você certamente pode ir ao mercado e comprar algo semelhante? A resposta é que, para nós, um dos parâmetros mais importantes é a flexibilidade do dispositivo. Devido às mudanças rápidas nos requisitos do projeto, novas funcionalidades emergentes, precisamos ser capazes de responder rapidamente a isso. Tendo apenas dentro do projeto, internamente, o desenvolvimento de hardware e software, obtemos uma velocidade muito alta de desenvolvimento dessas mudanças.
Outro sensor interessante do ponto de vista de um veículo não tripulado é a câmera. Ok, há uma câmera em todos os telefones e laptops. O que poderia ser complicado aqui? Mas vamos ver quais problemas você pode encontrar ao usar a câmera em um drone.
O primeiro problema é a oscilação das fontes de luz LED. A maioria dos semáforos são apenas essas fontes. O vídeo parou no momento em que, devido à tremulação, o sinal vermelho quase desapareceu.
Para esse problema, existem soluções de hardware embutidas no sensor, mas para funcionar bem e com alta qualidade, você precisa poder interagir ativamente com o sensor.
O segundo requisito para as câmeras é uma alta faixa dinâmica, ou seja, a capacidade de trabalhar em qualquer condição de luz, tanto à noite quanto sob o sol forte. A presença de HDR também é importante, ou seja, a possibilidade de combinar quadros com iluminação diferente em um para obter uma imagem melhor.
À esquerda é um exemplo de uma imagem em que a função HDR é usada e à direita - onde está desabilitada.
Além disso, é claro que precisamos tirar uma foto com uma resolução suficiente e uma taxa de quadros suficiente. No slide, mais alguns pontos são destacados, inerentes a veículos não tripulados, inclusive. A câmera deve produzir um fluxo de vídeo não compactado, preferencialmente no formato RGB888, porque nossas redes, os algoritmos funcionam com esse formato, e desejam receber quadros nesse formato.
A maioria das câmeras, soluções prontas no mercado, fornece dados compactados - H264, MPEG. Os problemas aqui são simples: perdemos qualidade durante a compactação e introduzimos um atraso na compactação e descompactação. O atraso pode ser não determinístico, especialmente em altas cargas do sistema. Uma câmera com resolução Full HD e uma frequência de 30 quadros por segundo com uma taxa de bits de 16 bits por pixel produz um fluxo de cerca de gigabits por segundo de dados de vídeo puros.
Além disso, as câmeras geralmente estão localizadas a uma distância do dispositivo receptor e, no carro, especialmente durante algumas experiências, elas podem estar localizadas geralmente na outra extremidade do carro. Precisávamos de câmeras que permitissem transmitir todo o fluxo de vídeo não compactado a uma distância de 6 a 8 metros, levando em consideração o cabeamento. Para uma câmera Full HD com 16 bits por pixel, o fluxo de vídeo é de 1 gigabit, o que não permite mais o uso de gigabit Ethernet, pois vários dados de serviço etc. estão envolvidos na transferência. A Ethernet de dez gigabit não é totalmente apropriada. É caro, alto consumo de energia, alta dissipação de calor, maior complexidade da infraestrutura de rede.
Sim, existem outras interfaces interessantes. Eu gostaria de falar sobre dois deles com os quais trabalhamos. Eles são fornecidos pela Maxim Integrated e Texas Instruments. A peculiaridade é que o fluxo de vídeo é serializado em dados que passam em um nível físico simples, neste caso através de um cabo coaxial, a uma velocidade de 3-4, às vezes 6 gigabits por segundo. Além disso, essa interface permite que você use o canal de retorno para controlar a câmera no mesmo cabo coaxial. E nele a energia da câmera pode ir. Todas as opções acima tornam essa interface muito atraente.
Quando começamos, encontramos uma solução no mercado que basicamente atendia à maioria dos requisitos. Nós o usamos por algum tempo no início do projeto.
O diagrama de blocos da solução está à sua frente. Este é um sensor a partir do qual os dados são serializados na interface GMSL / FPD-Link. Na parte receptora, que pode ser removida até 15 metros, os dados são desserializados e transmitidos ao receptor. Em nossa solução, esse receptor forneceu dados via interface USB 3.0.
Mas, ao começar a usar essa solução, encontramos vários problemas desagradáveis. O principal problema - a solução funcionou extremamente instável, "caiu" no processo, as câmeras não começaram bem quando o piloto automático começou. Além disso, a solução não permitiu ajustar os parâmetros dos próprios sensores para melhorar a qualidade da imagem. Também houve vários problemas. Por exemplo, era difícil obter o registro de data e hora exato da câmera, o tempo de gravação, o que é bastante importante, porque a uma velocidade de 15 m / s com um atraso de 100 ms, o carro já viaja um metro e meio e isso pode afetar negativamente os algoritmos de percepção.
Havia outro ponto interessante. A interface de saída da solução selecionada era USB 3.0 e descobrimos que era extremamente barulhenta. Como entendemos isso? Tínhamos dois carros não conectados a nada. Em um deles, eles lançaram a câmera; em ambos, o sinal de navegação por satélite afundou muito. Então começamos a estudar o que estava acontecendo.
Tendo analisado todas essas deficiências em geral, estudado o diagrama estrutural à sua frente e assim por diante, chegamos à conclusão de que o problema está na parte receptora. Então eles começaram a pensar no que fazer com isso. Examinamos o que há no mercado, soluções de outras equipes e chegamos à conclusão de que precisamos criar nosso próprio dispositivo receptor que funcionará com a câmera por meio da interface GMSL ou FPD-Link.
Pegamos desserializadores, que, em regra, têm saída de interface MIPI CSI2 e começamos a procurar por um módulo ou processador que pudesse suportar essa interface. E encontramos uma solução interessante com seis interfaces MIPI CSI2, além de periféricos avançados e de alto desempenho. Isso nos permitiu, eventualmente, usar a interface Ethernet de 10 gigabits que é conveniente para nossa infraestrutura de rede como a interface de saída deste dispositivo. Depois de receber dados GMSL / FPD-Link de 6 câmeras (ou, em alguns casos, de 12 câmeras), depois de processá-los, o dispositivo transfere o fluxo de vídeo já processado para o computador via Ethernet de 10 gigabits.
Aqui está a solução em si e suas principais características. Tendo desenvolvido isso, aprendemos não apenas como trabalhar de maneira confiável com 6 ou 12 câmeras, mas também tivemos a oportunidade de ajustar as câmeras. Isso possibilitou melhorar a qualidade da imagem, o que afetou positivamente a operação dos algoritmos de percepção. Também entendemos claramente o tempo necessário para fotografar o quadro e aprendemos a gerenciar esse tempo. E CPUs de alto desempenho, o poder computacional do módulo nos permitiu executar o processamento de vídeo inicial com atrasos mínimos diretamente no módulo.
O codec de hardware deste módulo também permitiu compactar dados de vídeo para armazenamento subsequente nos logs.
Tivemos que trabalhar não apenas com sensores e câmeras de localização. Tivemos que desenvolver soluções de hardware para quase todos os sensores que usamos. Tudo isso foi feito para resolver o aumento da confiabilidade e qualidade dos dados dos quais os algoritmos de detecção e percepção dependem. E depende deles o quão ótima será a solução emitida pelo piloto automático.
Aprendemos como dirigir um carro, trabalhamos com sensores, posicionamos-os bem, ensinamos a nos dar uma imagem de alta qualidade. Que outro trabalho os engenheiros de sistemas embarcados, trabalhadores de hardware em nosso projeto? Monitoramos não apenas o desenvolvimento de sensores que se tornaram rotineiros, mas também fontes alternativas de informação. Estamos constantemente explorando aceleradores alternativos de redes neurais e outros algoritmos, incluindo aqueles que usam FPGAs. E é difícil imaginar o desenvolvimento do projeto sem interação com uma montadora experiente.
A nova plataforma é sempre um desafio para desenvolvedores, designers e desenvolvedores de software de alto nível.O campo de veículos não tripulados está atualmente em um estágio muito ativo de desenvolvimento. Como engenheiro, estou muito satisfeito em observar isso, mas é muito mais agradável participar. E não muito longe é o momento em que será bastante comum entrarmos em um carro e, indo para o lugar de que precisamos, conduzir nossos negócios com conforto e segurança. Só isso, obrigado pela atenção.