Uuv_simulator: Implementar una simulación de sensor de sonda más realista

Oye, también estamos trabajando para realizar simulaciones de sensores en uuv_simulator . Actualmente, tenemos algo parecido a un barrido lateral, que nos da imágenes en cascada. Más importante aún, estamos trabajando hacia un buen sensor FLS aquí: https://github.com/smarc-project/smarc_simulations/blob/master/smarc_gazebo_plugins/smarc_gazebo_ros_plugins/src/gazebo_ros_image_sonar.cpp . Se basa en el simulador descrito en el documento "Un nuevo simulador de sonda basado en GPU para aplicaciones en tiempo real". Gazebo lo hace un poco difícil, por lo que se basa en abusar de una cámara de profundidad simulada, pero aún así es razonablemente eficiente.

Si todavía hay interés en esto, proporcionaré algunos ejemplos sobre cómo se ven los sonares y tal vez trabajaré para completar todo y crear un PR para este repositorio.

@nilsbore algunos ejemplos serían geniales. También estoy muy interesado en esto.

Hola @nilsbore , todas las contribuciones son bienvenidas :) Si quieres hacer una solicitud de extracción, estaré feliz de revisarla. Otra solución sería agregar información sobre la documentación del simulador UUV sobre cómo integrar sus complementos también, para que más personas puedan usarlo :)

Hola @musamarcusso , ¡y gracias por tu gran trabajo en este simulador! Veré cuánto se necesitaría para crear un PR limpio para este repositorio y seguir uno de los caminos propuestos, ¡gracias!

Hola @nilsbore ,

Espero ver su progreso en la adaptación de la sonda al simulador UUV. ¡Por favor déjanos saber! = D

¿Se logró algún progreso en el FLS? También estoy buscando utilizar.

¡Hola @nilsbore! Ha pasado un tiempo desde que se inició este hilo, sin embargo, ¿puedo saber cómo está el progreso en la simulación de FLS hasta ahora? Espero poder utilizar la simulación de sonda en la que estás trabajando en Gazebo también y espero que tengas más progreso después de eso.

* después de la última actualización que tuvo aquí.

Hola a todos, lamento no haber podido avanzar mucho en este tema. La simulación del sensor es de código abierto y está disponible aquí: https://github.com/smarc-project/smarc_simulations/tree/master/smarc_gazebo_plugins/smarc_gazebo_ros_plugins . Se llama gazebo_ros_image_sonar . Aunque estamos usando una versión algo anticuada de uuv_simulator, este complemento solo depende de gazebo y, por lo tanto, debería funcionar en todas partes. En uuv_simulator, puede incluirlo incluyendo esta urdf: https://github.com/smarc-project/smarc_simulations/blob/master/smarc_sensor_plugins/smarc_sensor_plugins_ros/urdf/sonar_snippets.xacro , y agregando algo como este fragmento en la urdf de su vehí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>

Entonces debería poder ver algo como esta imagen en un tema ros: video .

Cuando el tiempo lo permita (después de los plazos), intentaré dividir este sensor en su propio paquete que pueda ser utilizado por cualquiera que quiera usar el simulador FLS y nada más.

Mejor,
Nils

¡Notado @nilsbore ! Muchas gracias por la actualización. Intentaré hacer mejoras para este sensor también para que se pueda mejorar su rendimiento.

¡Realmente una gran actualización y progreso hasta ahora! ¡Esperamos más actualizaciones sobre este proyecto y muy buen trabajo @nilsbore!

Elegí cuidadosamente de @nilsbore para intentar obtener algo de FF del maestro. Parece que ambos han divergido de diferentes maneras.

Sería bueno que ustedes vieran y comenten / se comprometan para que otros puedan usar esto.

¡Perdón por la respuesta tardía @willcbaker ! Estoy divergiendo de @nilsbore ya que estoy tratando de implementar su código en mi propio proyecto, que parece tener diferentes parámetros en el entorno. Sin embargo, su código funciona perfectamente en mi entorno, aunque con algunas mejoras que podrían aplicarse para que se parezca más a la implementación mencionada en el documento "Un nuevo simulador de sonda basado en GPU para aplicaciones en tiempo real".

Lamentablemente, no he avanzado mucho en la realización de mejoras en el código debido a otros problemas, pero me aseguraré de publicar actualizaciones cuando tenga tiempo para hacerlo.

En términos de la confirmación que hizo, puedo decir con seguridad que las adiciones que hizo son exactamente las mismas que hice para mi rama. Debería funcionar perfectamente con Gazebo ahora y puede obtener las imágenes de la sonda del tema "rexrov / depth / image_sonar".

Debo señalar que actualmente el nombre está estrechamente ligado al tema "/ profundidad" ya que la implementación del sensor requiere el uso de una cámara de profundidad por ahora. Deberíamos ver si esto se puede mejorar para evitar posibles confusiones y, con suerte, pronto se podrán realizar más actualizaciones.

Hola @NickSadjoli , ¿podrías vincular al repositorio donde se implementa este sonar, si hay uno?

@musamarcusso Disculpas por no proporcionar los enlaces antes. Tengo una rama de trabajo que tiene un ejemplo funcional de este sonar en el UUV de Rexrov, pero tenga en cuenta que esta rama contiene otro código experimental que no funciona y que intenté anteriormente para recrear el FLS mencionado en el documento mencionado. La rama está vinculada a continuación:

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

Otras cosas o cambios a tener en cuenta que se agregaron o de uso en esta rama:

• Un mundo de prueba personalizado llamado "test_turbid_water.world" que se basaba en gran medida en "subsea_bop_panel.world" que modifiqué para usar en mi proyecto de investigación.
• Un modelo de trabajo de rexrov que contiene la implementación de FLS de Niels se encuentra en el directorio "uuv_descriptions / robots / rexrov_test.xacro", inicialmente basado en el modelo "rexrov_sonar.xacro". El modelo comenta el anterior m450 o p900 fls y lo reemplaza con el fls sonar xacro que fue recomendado por Niels anteriormente.
• Una vista personalizada "rexrov_fls.rviz" que hace que Rviz se muestre directamente en los temas / rexrov / depth / image_raw_sonar y front default_camera.
• Se utiliza un archivo de inicio personalizado, "test_turbid_water.launch" para iniciar toda la combinación de cambios anteriores, haciendo referencia directamente al mundo personalizado y Rviz.

Si la organización de los archivos en la rama actual es demasiado confusa, por favor envíenme sus comentarios en este hilo, para que pueda hacer una versión más limpia de esta rama para que pueda hacer una extracción.

Gracias y esperamos sus comentarios / opiniones.

• NickSadjoli

EDITAR: Olvidé adjuntar el enlace del repositorio

Hola, @NickSadjoli
Estoy probando tu uuv_simulator-realista-sonar-sim-48. El primer error que obtuve fue "falta uuv_laser_to_sonar / launch" durante la instalación de catkin_make. Creé una carpeta de inicio vacía como solución temporal. Luego ejecuté "roslaunch uuv_gazebo_worlds test_turbid_water.launch" y obtuve varios errores, incluyendo

1. [Err] [gazebo_ros_image_sonar. cpp: 160 ] No tenemos clip.
2. gzserver: error de búsqueda de símbolo: /home/cchien/catkin_ws3/devel/lib/libimage_sonar_ros_plugin.so: símbolo indefinido: _ZN2cv3Mat6createEiPKii.
   así como una advertencia que incluye "No se admite la conversión del tipo de sensor [profundidad]".
   Como resultado, no se muestra ninguna imagen de sonda en rviz. ¿Estoy perdiendo algo? ¿Algún comentario o sugerencia? Estoy probando su código en ubuntu 16.04, ROS kinetic y opencv 3.4. Gracias. C. Chien

Hola, @NickSadjoli
Después de rastrear los errores, resulta que las librerías opencv no estaban vinculadas correctamente. Como solución temporal, agregué las librerías opencv requeridas explícitamente a image_sonar_ros_plugin. Por favor, avíseme si hay mejores formas de corregir el error original.

También noto que my_frame (y mapa) no está definido o no recibe tf del mundo. ¿Alguna idea de cómo solucionar el problema? Gracias por tu aporte. C. Chien

¡Hola @ chyphen777!

Disculpe que esta sea una respuesta muy tardía a su consulta.

El error en el archivo de inicio faltante probablemente se debió a que incluí varios directorios que de todos modos no se iban a utilizar en la simulación de FLS, lo que provocó CMake-s desordenados. He actualizado mi rama para limpiar esto, lo que debería solucionar estos errores ahora. Sin embargo, desafortunadamente, parece que he eliminado accidentalmente algunos archivos necesarios en esta rama, lo que hace que la GUI de Gazebo se inicie con errores y fallas de segmentación. Sin embargo, tenga en cuenta que los temas reales de la glorieta aún se lanzan y que RViz aún puede iniciarse ocasionalmente correctamente, por lo que aún no está completamente roto.

Intentaré solucionar este problema con la rama y revertirlo a la confirmación anterior si el problema persiste. Sin embargo, tenga en cuenta que esto puede llevar un tiempo, ya que también me ocupo de otras cosas en mi trabajo, por lo que es posible que no tenga mucho tiempo.

En cuanto a los errores "No tenemos clip" y "Conversión del tipo de sensor [profundidad] no admitida", no estoy seguro de si esas son las posibles causas de que la imagen de la sonda no se muestre en RViz, ya que aún pude tener la imagen mostrada en mi RViz incluso con esos errores apareciendo. Creo que lo más probable es que se atribuya al error de búsqueda de símbolos que, lamentablemente, aún no he encontrado en mi repositorio local.

En una nota relacionada, no estoy seguro de si las librerías opencv también deben estar vinculadas explícitamente a las CMakeLists, ya que pude lanzar el mundo sin problemas sin necesidad de hacerlo. Sin embargo, intentaré ver esto también. Gracias por proporcionar el error de curita también a otros usuarios que podrían estar experimentando un problema similar.

Hola @ chyphen777 ,

Acabo de realizar algunas modificaciones menores en la rama actual y parece que ahora funciona bien en mi máquina, por lo que debería poder simplemente cambiar a esta rama y hacer que todo se compile con catkin_make install.

Sin embargo, debe tenerse en cuenta que la rama parece ser inestable a veces y es posible que encuentre el siguiente tipo de error:

En caso de que encuentre tales errores, debería poder cerrar y volver a iniciar el archivo de inicio para que Gazebo y RViz estén en funcionamiento (al menos eso es lo que pude hacer). Esta inestabilidad es definitivamente molesta y trataré de investigar las causas de esto más a fondo para que la rama pueda ser más estable.

Además, desafortunadamente tampoco he examinado más de cerca el my_frame y el mapa para no estar definido o no actualizarse desde el tf del mundo. Sospecho que podría deberse a un residuo de mis intentos anteriores de usar otra solución FLS que aún no tuvo éxito. Nuevamente, intentaré investigar esto una vez que tenga más tiempo y volveré a usted una vez que tenga más actualizaciones.

Saludos y gracias por tus comentarios C. Chien! - Nicholas S.

Hola, @NickSadjoli :

Gracias por la respuesta, las correcciones y la información útil. Puedo ejecutar su simulador de sonda. Lo siento por la respuesta tardía. Me desviaron hacia otros proyectos. Manténganos informados sobre cualquier actualización.
Saludos, C. Chien.

@NickSadjoli
En primer lugar, un gran trabajo con esta implementación de FLS para el simulador UUV, ¡es un gran activo para la comunidad! Tengo un par de preguntas ya que planeo hacer algunos cambios leves para que el FLS coincida con el hardware que normalmente implementaría en el campo.

1. ¿Cómo puedo agregar otro sonar, por ejemplo, uno mirando hacia adelante y otro mirando hacia atrás? Parece que hay mucha interdependencia en la cámara con respecto a la generación de imágenes FLS, buscando su guía.

2. ¿En qué se basa el sonar y cuál es su apertura vertical? Si quisiera, ¿cómo cambiaría la apertura vertical de la sonda?

3. ¿Cuál es el rango máximo del sensor y cómo lo cambiaría si quisiera?

4. En el archivo rexrov_test.xacro, en el bloque para iniciar el FLS, ¿a qué se refiere "samples = 100"?

John

@NickSadjoli
Buscando citar esto apropiadamente en algún trabajo próximo. Usaré la cita del simulador UUV, pero ¿hay otros trabajos que deban citarse? Quizás "¿Un nuevo simulador de sonda basado en GPU para aplicaciones en tiempo real?"

@ jake3991 Al menos mi implementación original se basa en el documento al que te refieres. No sé si @NickSadjoli ha agregado algún concepto de otros trabajos.

¡Gran trabajo!

@nilsbore Estoy tratando de comprender su implementación y la formación de imágenes del sonar de imágenes. ¿Podría indicarme las ecuaciones que se utilizaron para implementar ConstructSonarImage y ConstructScanImage ? Por ejemplo, ¿por qué SNR se calcula 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 es de hace bastante tiempo y no recuerdo exactamente dónde obtuve esas ecuaciones. Honestamente, el enfoque al implementar esto fue más en crear una imagen de aspecto realista que en un modelo de sonda completamente correcto. Un buen comienzo probablemente sea mirar el documento al que hace referencia

Para aquellos que estén interesados ​​en la sonda multihaz en Gazebo, he creado un complemento de sonda multihaz en el proyecto Dave que también incorpora uuv_simulator. Utiliza la biblioteca Nvidia Cuda y calcula los datos de intensidad / rango hasta una frecuencia de actualización de 10 Hz con una frecuencia de 900 kHz, rango de 10 m. Para obtener más detalles, https://github.com/Field-Robotics-Lab/dave/wiki/Multibeam-Forward-Looking-Sonar

Hola, lamento mucho solo responder a este hilo después de tanto tiempo, ya que estoy abordando otra parte / componente masivo para mi proyecto.

Efectivamente, esto también significa que ya no estoy trabajando completamente en el desarrollo del simulador, ya que entregué esta carga de trabajo a un colega que lo ha estado manejando desde el año pasado. Desafortunadamente, olvidé mencionarle este hilo en caso de que haya preguntas publicadas sobre algún desarrollo.

También para aclarar: durante mi manejo del modelo de sonda, no hice ningún código de nivel inferior (es decir, los códigos fuente C) escrito por @nilsbore para la sonda. Sin embargo, mi collague puede haberle hecho algunos pequeños ajustes para cambiar parte de su comportamiento y simular de manera más realista los comportamientos de FLS en entornos submarinos turbios.

@ jake3991 Para responder a sus preguntas:

1. Por lo que tengo entendido, mi colega hasta ahora solo ha logrado 'rotar' la sonda ajustando algunos parámetros URDF de la misma. Intentaré preguntarle cómo se hace con más detalle si todavía estás interesado.
2. Inicialmente, el sonar todavía se basaba en el sonar Blueview que usaba sonda Blueview M750D . Creo que se las arregló para hacerlo agregando algunos parámetros en la llamada xacro, pero nuevamente tendré que pedirle más detalles para esa implementación.
3. Misma respuesta que 2
4. Desafortunadamente, no logré jugar con el software para tener respuestas definitivas sobre esto. Necesito preguntarle a un colega sobre este.

Tenga en cuenta también que mi colega planea publicar un artículo sobre el simulador basado en uuv_simulator en el que ha estado trabajando. Por lo tanto, será necesario que le comuniquemos más detalles sobre la implementación actual de nuestro proyecto. Intentaré que esté conectado a este hilo si es necesario para responder cualquier pregunta adicional sobre la implementación de nuestro proyecto.

Sin embargo, con respecto a un modelo de sonda realmente "preciso", parece que el trabajo vinculado por @ woensug-choi podría ser un modelo más "preciso" ya que utiliza una implementación de trazado de rayos más directa. Aunque no estoy completamente seguro de si esto es mucho mejor para el desarrollo basado en simulación en general.

Hará que mi colega revise la implementación y vea qué tan bien se puede integrar al simulador de mi proyecto.

Nuevamente, grandes disculpas a todos por la respuesta tardía a este hilo.

@ jake3991 También para aclarar con respecto a la cita del simulador de nuestro proyecto: dado que no hemos obtenido una publicación en papel con éxito real en el simulador, le sugiero que aún use el documento que vinculó, así como @nilsbore para la cita adecuada.

Una vez que nuestra publicación sobre la publicación sea aceptada o hecha, entonces quizás también se pueda usar la cita para nuestro artículo.

Para aquellos que estén interesados, consulte https://github.com/Field-Robotics-Lab/dave/wiki/Multibeam-Forward-Looking-Sonar .

Tenga en cuenta que estoy usando https://github.com/uuvsimulator/uuv_simulator de @musamarcusso que ya ha integrado el módulo de sonda de @nilsbore .
Para aclarar a @NickSadjoli en la pregunta de @ jake3991 :

1. Agregamos un URDF para la propia sonda. por lo que al agregar otro URDF y reasignar los nombres de los parámetros, puede tener 2 sonares en su simulador.

Como dijo @NickSadjoli , estábamos haciendo referencia desde un sonar Blueprint.
Para tuitear el VFOV de la sonda:
En el archivo xacro URDF de la sonda, debe especificar el HFOV, el ancho y el alto de la imagen. Gazebo que calcula la base de la distancia focal en el ancho de la imagen y HFOV. Utilizando la misma distancia focal, calculan a la inversa el VFOV utilizando la altura de la imagen. Entonces, para especificar el VFOV que deseaba, deberá calcular la altura de la imagen.

Longitud focal = (Ancho / 2) / tan (deg2rad (HFOV) / 2) o Longitud focal = (Altura / 2) / tan (deg2rad (VFOV) / 2)

3. Debes tuitear el código C ++ de la sonda. En el código C ++ de la sonda de @nilsbore , agregué un suscriptor al valor de "Rango" en lugar de tener un Rango constante como el trabajo original de

1. En el xacro de "FLS", el parámetro "samples" no se utiliza. En el xacro de "Multihaz", utiliza el punto láser de la glorieta para conectar el multihaz. Por lo tanto, consulte esto: http://gazebosim.org/tutorials?tut=ros_gzplugins en "GPU láser".

Espero que esto ayude.

@nilsbore y @NickSadjoli , Hii, acabo de probar el complemento fls proporcionado en uuv_sensor_ros_plugin. Tengo algunas preguntas relacionadas con él: 1. Intenté configurar el tema en sonar_snippets.xacro. Cuando se simuló el robot, ¿por qué no aparece el tema que establecí antes? Acabo de ver este tipo de tema: "/ rexroth / depth / sonar raw_image".

1. En sonar_snippets.xacro, ¿qué significan $ {ancho} y $ {alto}? ¿Se relaciona con el ancho y alto del sonar de imagen generada? Si es así, traté de configurar el valor de $ {ancho} y $ {alto} y luego imprimo el valor de alto y ancho del tema de la imagen de la sonda. Pero esos valores eran diferentes. ¿Podrías explicarme por qué sucede?
2. ¿Es posible obtener el rango extendido de la sonda, de modo que pueda ver el obstáculo de pedos en la imagen de la sonda?

@Jenanaputra Por

1. ¿Cómo estableciste el tema? ¿Cambiaste los parámetros de{$ topic}en un archivo xacro? ¿O modificó el código C ++ a un tema específico que le gustaría tener? (para mí modificar el código suena más apetecible)
2. El sonar es en realidad una modificación de la cámara de profundidad de la glorieta, en un complemento de cámara de la glorieta el $ {ancho} y $ {alto} afectan el VFOV y HFOV del sensor (mención de la ecuación en mi publicación anterior). Por lo general, para la cámara, el ancho es de 1280 y la altura es de 720. Para la sonda, establezco el ancho en 1280 y calculo la altura usando la fórmula. De esta manera obtengo el VFOV del sensor que quería.
3. Como mencioné antes en mi publicación anterior, la modificación del rango requiere que modifique el código C ++. El rango es actualmente un valor fijo codificado de forma rígida.
   Finalmente, no se olvide de limpiar y hacer después de modificar el código C ++ (suponiendo que use el paquete ROS)

@ loguna123 Gracias por tu repetición. ¿Sabe cómo obtener / conocer el valor de profundidad utilizado en este complemento de fls?