Uuv_simulator: Implementar uma simulação de sensor de sonar mais realista

Criado em 2 mai. 2017  ·  33Comentários  ·  Fonte: uuvsimulator/uuv_simulator

Atualmente, abusamos dos sensores a laser do Gazebo e os chamamos de sonar.

Uma simulação mais realista de sensores de sonar ( sonar de varredura lateral e multifeixe ) agregaria muito valor ao uuv_simulator e o tornaria mais interessante para uma nova comunidade maior.

enhancement help wanted

Comentários muito úteis

Ei, estamos trabalhando em simulações de sensor em uuv_simulator também. Atualmente, temos algo semelhante a uma varredura lateral, que nos dá imagens de cachoeiras. Mais importante, estamos trabalhando em um bom sensor FLS aqui: https://github.com/smarc-project/smarc_simulations/blob/master/smarc_gazebo_plugins/smarc_gazebo_ros_plugins/src/gazebo_ros_image_sonar.cpp . Ele se baseia no sim descrito no artigo "Um novo simulador de sonar baseado em GPU para aplicações em tempo real". O gazebo torna isso um pouco difícil, então ele depende do abuso de uma câmera de profundidade simulada, mas ainda é razoavelmente eficiente.

Se ainda houver interesse nisso, fornecerei alguns exemplos de como os sonares se parecem e talvez trabalhe para completar tudo e criar um PR para este repo.

Todos 33 comentários

Ei, estamos trabalhando em simulações de sensor em uuv_simulator também. Atualmente, temos algo semelhante a uma varredura lateral, que nos dá imagens de cachoeiras. Mais importante, estamos trabalhando em um bom sensor FLS aqui: https://github.com/smarc-project/smarc_simulations/blob/master/smarc_gazebo_plugins/smarc_gazebo_ros_plugins/src/gazebo_ros_image_sonar.cpp . Ele se baseia no sim descrito no artigo "Um novo simulador de sonar baseado em GPU para aplicações em tempo real". O gazebo torna isso um pouco difícil, então ele depende do abuso de uma câmera de profundidade simulada, mas ainda é razoavelmente eficiente.

Se ainda houver interesse nisso, fornecerei alguns exemplos de como os sonares se parecem e talvez trabalhe para completar tudo e criar um PR para este repo.

@nilsbore alguns exemplos seriam ótimos. Também estou muito interessado nisso.

Olá @nilsbore , todas as contribuições são bem-vindas :) Se você quiser fazer uma solicitação de pull, ficarei feliz em analisá-la. Outra solução seria adicionar informações sobre a documentação do simulador UUV como integrar seus plug-ins também, para que mais pessoas possam usá-lo :)

Olá @musamarcusso , e obrigado pelo seu excelente trabalho neste simulador! Vou ver quanto custaria para criar um PR limpo para este repo e seguir um dos caminhos propostos, obrigado!

Olá @nilsbore ,

Estou ansioso para ver seu progresso na adaptação do sonar ao simulador UUV. Por favor nos informe! = D

Houve algum progresso no FLS? Também estou procurando utilizar.

Olá @nilsbore! Já faz um tempo que este tópico foi iniciado, mas posso saber como está o progresso na simulação FLS até agora? Estou ansioso para utilizar a simulação de sonar em que você está trabalhando no Gazebo também e espero que você tenha mais progresso depois disso

* após a última atualização que você teve aqui.

Olá a todos, Lamento não ter conseguido progredir muito neste tópico. A simulação do sensor é de código aberto e está disponível aqui: https://github.com/smarc-project/smarc_simulations/tree/master/smarc_gazebo_plugins/smarc_gazebo_ros_plugins . É chamado de gazebo_ros_image_sonar . Embora estejamos usando uma versão um tanto desatualizada do uuv_simulator, este plugin depende apenas do gazebo e deve funcionar em qualquer lugar. No uuv_simulator, você pode incluí-lo incluindo este urdf: https://github.com/smarc-project/smarc_simulations/blob/master/smarc_sensor_plugins/smarc_sensor_plugins_ros/urdf/sonar_snippets.xacro e adicionando algo como este snippet no urdf do seu veículo :

<xacro:forward_looking_sonar
      namespace="${namespace}"
      suffix="down"
      parent_link="${namespace}/base_link"
      topic="forward_sonar"
      mass="0.015"
      update_rate="10"
      samples="100"
      fov="1.54719755"
      width="260"
      height="120">
      <inertia ixx="0.00001" ixy="0.0" ixz="0.0" iyy="0.00001" iyz="0.0" izz="0.00001" />
      <origin xyz="0.83 0 -0.22" rpy="0 ${0.2*pi} 0" />
      <visual>
      </visual>
    </xacro:forward_looking_sonar>

Você deverá então ser capaz de ver algo como esta imagem em um tópico ros: vídeo .

Quando o tempo permitir (após os prazos), tentarei dividir esse sensor em um pacote próprio que possa ser usado por qualquer pessoa que queira usar o sim FLS e nada mais.

Melhor,
Nils

Notado @nilsbore ! Muito obrigado pela atualização. Vou tentar fazer melhorias neste sensor também para que seu desempenho possa ser melhorado.

Realmente uma ótima atualização e progresso até agora! Ansioso por novas atualizações sobre este projeto e um trabalho realmente bom @nilsbore!

Eu escolhi @NickSadjoli e @nilsbore para tentar obter algum FF do mestre. Parece que vocês dois divergem de maneiras diferentes.

Seria bom se vocês dessem uma olhada e comentassem / cometeriam para que isso pudesse ser usado por outros.

Desculpe pela resposta tardia @willcbaker ! Estou divergindo de @nilsbore, pois estou tentando implementar seu código em meu próprio projeto, que parece ter parâmetros diferentes no ambiente. Seu código está funcionando perfeitamente em meu ambiente, entretanto, embora com algumas melhorias que poderiam ser aplicadas para torná-lo mais parecido com a implementação mencionada no artigo "Um novo simulador de sonar baseado em GPU para aplicativos em tempo real".

FLS upgraded-turbidwater

Infelizmente, não fiz muito progresso ao fazer melhorias no código devido a outros problemas, mas farei questão de postar atualizações quando tiver tempo para fazê-lo.

Em termos do commit que você fez, posso dizer com segurança que as adições que você fez são exatamente as mesmas que fiz para o meu branch. Deve funcionar perfeitamente com o Gazebo agora e você pode obter as imagens do sonar do tópico "rexrov / depth / image_sonar".

Devo observar que atualmente o nome está intimamente ligado ao tópico "/ profundidade", uma vez que a implementação do sensor requer o uso de uma câmera de profundidade por enquanto. Devemos ver se isso pode ser melhorado para evitar possíveis confusões e esperamos que mais atualizações possam vir em breve.

Olá @NickSadjoli , você poderia fazer um link para o repositório onde este sonar está implementado, se houver um?

@musamarcusso Desculpas por não fornecer os links antes. Eu tenho um branch funcional que tem um exemplo funcional deste sonar no UUV Rexrov, mas observe que este branch contém outro código experimental não funcional que tentei recriar anteriormente o FLS mencionado no artigo referido. A filial está ligada abaixo:

https://github.com/NickSadjoli/uuv_simulator/tree/realistic-sonar-sim-48

Outras coisas ou alterações a serem observadas que foram adicionadas ou de uso neste ramo:

  • Um mundo de teste personalizado chamado "test_turbid_water.world" que foi fortemente baseado no "subsea_bop_panel.world" que modifiquei para uso em meu projeto de pesquisa.
  • Um modelo de trabalho rexrov contendo a implementação FLS da Niels está no diretório "uuv_descriptions / robots / rexrov_test.xacro", inicialmente baseado no modelo "rexrov_sonar.xacro". O modelo comenta os fls m450 ou p900 anteriores e os substitui pelo sonar xacro fls recomendado por Niels acima.
  • Uma visão "rexrov_fls.rviz" customizada que faz com que o Rviz seja exibido diretamente nos tópicos / rexrov / depth / image_raw_sonar e front default_camera.
  • Um arquivo de inicialização personalizado, "test_turbid_water.launch" é usado para iniciar todas as combinações de mudanças acima, referenciando diretamente o mundo personalizado e Rviz

Se a organização dos arquivos no branch atual é muito confusa, por favor, dê-me seus comentários neste tópico, para que eu possa fazer uma versão mais limpa deste branch para você fazer um pull.

Obrigado e aguardamos seus comentários / opiniões

  • NickSadjoli

EDIT: Esqueci de anexar o link do repositório

Oi @NickSadjoli
Estou testando seu uuv_simulator-realistic-sonar-sim-48. O primeiro erro que recebi foi "faltando uuv_laser_to_sonar / launch" durante a instalação do catkin_make. Criei uma pasta de inicialização vazia como uma solução alternativa. Então eu executei "roslaunch uuv_gazebo_worlds test_turbid_water.launch" e recebi vários erros, incluindo

  1. [Err] [gazebo_ros_image_sonar. cpp: 160 ] Não temos clipe.
  2. gzserver: erro de pesquisa de símbolo: /home/cchien/catkin_ws3/devel/lib/libimage_sonar_ros_plugin.so: símbolo indefinido: _ZN2cv3Mat6createEiPKii.
    bem como alguns avisos incluindo "Conversão de tipo de sensor [profundidade] não suportada".
    Como resultado, nenhuma imagem de sonar é mostrada em rviz. Estou mandando mensagem? Algum comentário ou sugestão? Estou testando seu código no ubuntu 16.04, ROS kinetic e opencv 3.4. Obrigado. C. Chien

Oi @NickSadjoli
Depois de rastrear erros, descobriu-se que as libs opencv não estavam devidamente vinculadas. Como uma solução alternativa, adicionei as libs opencv necessárias explicitamente a image_sonar_ros_plugin. Informe-nos se houver maneiras melhores de corrigir o erro original.

Também noto que my_frame (e map) não está definido ou não está recebendo tf do mundo. Alguma ideia de como consertar o problema? Obrigado pela sua contribuição. C. Chien

Olá @ chyphen777!

Lamentamos que esta seja uma resposta muito tardia à sua pergunta.

O erro no arquivo de inicialização ausente provavelmente foi causado por eu incluir vários diretórios que não seriam usados ​​na simulação FLS de qualquer maneira, causando CMake-s confusos. Eu atualizei meu branch para limpar isso, o que deve corrigir esses erros agora. No entanto, infelizmente, parece que eu acidentalmente apaguei alguns arquivos necessários neste branch, o que faz com que as GUIs do Gazebo sejam iniciadas com erros e falhas de segmentação. Observe, entretanto, que os tópicos reais do gazebo ainda são iniciados e que o RViz ainda pode ser iniciado de vez em quando de forma adequada, portanto, ainda não está totalmente quebrado.

Vou tentar consertar esse problema com o branch e reverter para o commit anterior se o problema ainda persistir. Observe que isso pode demorar um pouco, pois também estou cuidando de outras coisas no meu trabalho, então posso não ter muito tempo.

Quanto aos erros "Não temos clipe" e "Conversão do tipo de sensor [profundidade] não suportada", não tenho certeza se essas são as possíveis causas para a imagem do sonar não aparecer no RViz, pois ainda consegui tenho a imagem mostrada no meu RViz mesmo com esses erros aparecendo. Acho que provavelmente é atribuído ao erro de pesquisa de símbolo que, infelizmente, ainda não encontrei em meu repositório local.

Em uma nota relacionada, não tenho certeza se as libs opencv precisam ser explicitamente vinculadas às CMakeLists, já que fui capaz de lançar o mundo muito bem sem exigir isso. No entanto, tentarei ver isso também. Obrigado por fornecer o erro band-aid também para outros usuários que podem estar enfrentando um problema semelhante.

Olá @ chyphen777 ,

Acabei de fazer algumas pequenas modificações no branch atual e parece estar funcionando bem na minha máquina agora, então você deve ser capaz de mudar para este branch e ter tudo compilado com catkin_make install.

No entanto, deve-se observar que o branch parece instável às vezes e você pode encontrar o seguinte tipo de erro:

current_branch_not_stable

Caso encontre esses erros, você deve conseguir apenas fechar e reiniciar o arquivo de inicialização para colocar o Gazebo e o RViz em funcionamento (pelo menos foi o que consegui fazer). Essa instabilidade é definitivamente irritante e tentarei investigar o que causa isso mais adiante, para que o branch possa ser mais estável.

Além disso, infelizmente também não olhei mais de perto no que diz respeito ao my_frame e map para não ser definido ou não ser atualizado do tf do mundo. Suspeito que pode ser devido a uma sobra de minhas tentativas anteriores de usar outra solução FLS que ainda não foi bem-sucedida. Mais uma vez, tentarei examinar isso assim que tiver mais tempo e volto para você quando tiver mais atualizações.

Saudações e obrigado pelo seu feedback C. Chien! - Nicholas S.

Olá, @NickSadjoli :

Obrigado pela resposta, correções e informações úteis. Consigo rodar seu simulador de sonar. Desculpe pela resposta tardia. Fui desviado para outros projetos. Por favor, mantenha-nos informados sobre qualquer atualização.
Atenciosamente, C. Chien.

@NickSadjoli
Em primeiro lugar, ótimo trabalho com esta implementação de FLS para o simulador UUV, é um grande trunfo para a comunidade! Tenho algumas perguntas sobre isso, pois pretendo fazer algumas pequenas alterações para que o FLS corresponda ao hardware que eu normalmente implantaria em campo.

  1. Como posso adicionar outro sonar, por exemplo, um voltado para a frente e outro voltado para a popa? Parece que há muita interdependência na câmera em relação à geração de imagens FLS, procurando sua orientação.

  2. Em que é o sonar que se baseia e qual é a sua abertura vertical? Se eu quisesse, como alteraria a abertura vertical do sonar?

  3. Qual é o alcance máximo do sensor e como eu mudaria isso se quisesse?

  4. No arquivo rexrov_test.xacro, no bloco para iniciar o FLS, a que "samples = 100" se refere?

João

@NickSadjoli
Procuro citar isso apropriadamente em algum trabalho futuro. Vou usar a citação do simulador UUV, mas há outros trabalhos que precisam ser citados? Talvez "Um novo simulador de sonar baseado em GPU para aplicações em tempo real?"

@ jake3991 Pelo menos minha implementação original é baseada no artigo ao qual você está se referindo. Não sei se @NickSadjoli adicionou algum conceito de outros trabalhos.

Bom trabalho!

@nilsbore Estou tentando entender sua implementação e a formação da imagem do sonar de imagem. Você poderia me indicar as equações que foram usadas para implementar ConstructSonarImage e ConstructScanImage ? Por exemplo, por que SNR é calculado como cv::Mat SNR = SL - 2.0*TL - (NL-DI) + TS; ?

cv::Mat GazeboRosImageSonar::ConstructSonarImage(cv::Mat& depth, cv::Mat& normals)
{
  std::vector<cv::Mat> images(3);
  cv::split(normals, images);

  float intensity = 100.; // target strength
  float SL = 200.; // source level
  float NL = 30; // noise level
  float DI = 0.0; // directivity index

  if (dist_matrix_.empty()) {
    // Compute dist_matrix_ once
    // ...
  }

  cv::Mat TS = intensity*images[2]; // target strength, probably dir should be DI

  cv::Mat TL = 5*depth; // transmission loss
  cv::multiply(TL, dist_matrix_, TL);

  cv::Mat SNR = SL - 2.0*TL - (NL-DI) + TS;
  SNR.setTo(0., SNR < 0.);

  // ...

@witignite Este código é de algum tempo atrás e não me lembro exatamente de onde obtive essas equações. Para ser honesto, o foco ao implementar isso foi mais na criação de uma imagem de aparência realista, em vez de um modelo de sonar completamente correto. Um bom começo é provavelmente olhar para o artigo que @ jake3991 fez referência.

Para aqueles que estão interessados ​​no Multibeam Sonar no Gazebo, eu construí um plug-in de sonar Multibeam no projeto Dave que incorpora uuv_simulator também. Ele usa a biblioteca Nvidia Cuda e calcula os dados de intensidade / alcance de até 10 Hz de taxa de atualização com frequência de 900 kHz e alcance de 10 m. Para obter mais detalhes, https://github.com/Field-Robotics-Lab/dave/wiki/Multibeam-Forward-Looking-Sonar
image

Olá, sinto muito por responder a este tópico depois de muito tempo, pois estou lidando com outra grande parte / componente do meu projeto.

Isso também significa que não estou mais trabalhando totalmente no desenvolvimento do simulador, pois entreguei essa carga de trabalho a um colega meu que está cuidando dela desde o ano passado. Infelizmente, esqueci de mencionar esse tópico para ele, caso haja perguntas postadas sobre qualquer desenvolvimento.

Também para esclarecimento: durante o manuseio do modelo de sonar, não fiz nenhum código de nível inferior (ou seja, os códigos-fonte C) escrito por @nilsbore para o sonar. No entanto, meu colega pode ter feito alguns pequenos ajustes para mudar alguns de seu comportamento para simular de forma mais realista os comportamentos FLS em ambientes subaquáticos turvos.

@ jake3991 Para responder às suas perguntas:

  1. Pelo que entendi, meu colega até agora só conseguiu 'girar' o sonar ajustando alguns parâmetros URDF dele. Vou tentar perguntar a ele como isso é feito com mais detalhes, se você ainda estiver interessado.
  2. Inicialmente, o sonar ainda era baseado no sonar Blueview que sonar Blueview M750D . Acredito que ele conseguiu fazer isso adicionando alguns parâmetros à chamada xacro, mas novamente vou precisar pedir a ele mais detalhes para essa implementação.
  3. Mesma resposta que 2
  4. Não consegui brincar com o software para ter respostas definitivas sobre isso, infelizmente. Precisa perguntar a um colega sobre este.

Observe também que meu colega está planejando publicar um artigo sobre o simulador baseado em uuv_simulator no qual ele está trabalhando. Portanto, mais detalhes sobre a implementação atual de nosso projeto precisarão ser encaminhados a ele. Vou tentar fazer com que ele seja conectado a este tópico, se necessário, para responder a quaisquer outras perguntas sobre a implementação do nosso projeto.

Com relação a um modelo de sonar realmente "preciso", no entanto, parece que o trabalho vinculado por @ woensug-choi pode ser um modelo mais "preciso", pois está usando uma implementação mais direta de rastreamento de raios. Embora eu mesmo não esteja completamente certo de como isso é melhor para o desenvolvimento baseado em simulação em geral.

Vou pedir ao meu colega que verifique a implementação e veja se ela pode ser bem integrada ao simulador do meu projeto.

Mais uma vez, grandes desculpas a todos na resposta tardia a este tópico.

@ jake3991 Também para esclarecimento sobre a citação do simulador de nosso projeto: Como não obtivemos uma publicação de artigo real bem-sucedida no simulador, sugiro que você ainda use o artigo que você vinculou, bem como @nilsbore para a citação adequada.

Uma vez que nossa publicação na publicação seja aceita ou concluída, a citação para nosso artigo também pode ser usada.

Para quem estiver interessado, por favor, verifique https://github.com/Field-Robotics-Lab/dave/wiki/Multibeam-Forward-Looking-Sonar .

Observe que estou usando https://github.com/uuvsimulator/uuv_simulator de @musamarcusso que já integrou o módulo de sonar de @nilsbore .
Para esclarecer @NickSadjoli na pergunta @ jake3991 :

  1. Adicionamos um URDF para o próprio sonar. então, adicionando outro URDF e remapeando os nomes dos parâmetros, você pode ter 2 sonares em seu simulador.

2.Como de @NickSadjoli disse, estávamos
Para tweetar o VFOV do sonar:
No arquivo URDF xacro do sonar, é necessário especificar o HFOV, a largura e a altura da imagem. Gazebo do que calcular a base do comprimento focal na largura da imagem e HFOV. Usando o mesmo comprimento focal, eles calculam inversamente o VFOV usando a altura da imagem. Portanto, para especificar o VFOV desejado, você precisará calcular a altura da imagem.

Comprimento focal = (Largura / 2) / tan (deg2rad (HFOV) / 2) ou Comprimento focal = (Altura / 2) / tan (deg2rad (VFOV) / 2)

3.Você deve twittar o código C ++ do sonar. No código C ++ do sonar de @nilsbore , adicionei um assinante ao valor "Range" em vez de ter um Range constante como o trabalho original de @nilsbore . Desta forma, posso jogar com o alcance máximo do visor do sonar como a maioria dos sonares.

  1. No xacro de "FLS", o parâmetro "samples" não é usado. No xacro para "Multibeam", ele usa o ponto de laser do mirante para conter o multifeixe. Portanto, consulte: http://gazebosim.org/tutorials?tut=ros_gzplugins em "Laser GPU".

Espero que isto ajude.

@nilsbore e @NickSadjoli , Hii, acabei de experimentar o plugin fls fornecido em uuv_sensor_ros_plugin. Tenho algumas perguntas relacionadas a isso: 1. Tentei configurar o tópico em sonar_snippets.xacro. Quando o robô foi simulado, por que não existe o tópico que defini antes? Acabei de ver este tipo de tópico: "/ rexroth / depth / sonar raw_image".

  1. Em sonar_snippets.xacro, o que $ {width} e $ {height} significam? está relacionado com a largura e altura do sonar de imagem gerado? Em caso afirmativo, tentei definir o valor de $ {largura} e $ {altura} e, em seguida, imprimo o valor da altura e largura do tópico da imagem do sonar. Mas esses valores eram diferentes. Você poderia me explicar, por que isso acontece?
  2. É possível obter o alcance estendido do sonar, para que eu possa ver o obstáculo mais distante na imagem do sonar?

@Jenanaputra Por favor, refira-se ao meu comentário acima .....

  1. Como você definiu o assunto? Você mudou os parâmetros de{$ topic}em um arquivo xacro? Ou você modificou o código C ++ para um tópico específico que gostaria de ter? (para mim, modificar o código parece mais apetitoso)
  2. O sonar é na verdade uma modificação da câmera de profundidade do gazebo, em um plugin de câmera do gazebo o $ {largura} e $ {altura} afeta o VFOV e HFOV do sensor (equação mencionada no meu post anterior). Normalmente, a largura da câmera é 1280 e a altura 720. Para o sonar, defino a largura como 1280 e calculo a altura usando a fórmula. Dessa forma eu obtenho o VFOV do sensor que eu queria.
  3. Como mencionei antes em meu post anterior, a modificação do intervalo requer que você modifique o código C ++. O intervalo é atualmente um valor fixo codificado.
    Finalmente, não se esqueça de limpar e fazer a limpeza depois de modificar o código C ++ (assumindo que você usa o pacote ROS)

@ loguna123 Obrigado pelo seu replay. Você sabe como obter / saber o valor de profundidade usado neste plugin fls?

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

ccs-ros picture ccs-ros  ·  10Comentários

dbcesar picture dbcesar  ·  5Comentários

Timple picture Timple  ·  7Comentários

tve picture tve  ·  17Comentários

HashirZahir picture HashirZahir  ·  10Comentários