srmainwaring / asv_wave_sim Goto Github PK

The waves visual plugin is sensitive to the plugin load order when running on an arm64 mac. It is not clear why the issue is not present on an amd64 mac or linux, but the same issue is potentially present.

The problem is that the ogre2 render engine plugin must be loaded and initialised before the waves visual plugin is loaded for the model. The waves visual plugin links directly against the ogre2 render engine plugin library. This library (libgz-rendering7-ogre2.dylib) is installed into two locations (./install/lib and ./install/lib/gz-rendering-7/engine-plugins).

On arm64 macs the libraries are loaded twice, once from each location. The library linked to the visual plugin is loaded first and the render engine is initialised second. This appears to cause dynamic casts of the scene pointer to fail when the scene is being initialised.

Suggested fix

A fix requires better control over the order in which the extensions to the ogre2 render engine that are embedded in the waves visual plugin are loaded.

Currently there is no mechanism in gz-rendering to define custom extensions to the render engine interface and implement these for specific render systems. The waves visual plugin (a system plugin) works around this by defining the extensions directly and hoping that the render engine is available at the point the visual is initialised. This is not robust.

The proposal is add a class for render engine extensions and a manager to load and store them, analogous to the classes for the main render engine. This will allow the loader to check the base render engine plugin is present before loading the extension.

The visual plugin should be written in terms of render engine extension interface classes - rather than depending directly on a specific render engine. This allows the direct linkage to specific render engines to be broken.

Hi Rhys,

I have downloaded the new version of the wave sim and I encountered the following errors when I try to use the trochoid_waves wave model. I should note that the regular waves model works fine.

libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
Warning [Utils.cc:130] [/sdf/plugin[@name="gz::sim::systems::WavesVisual"]::L1]: XML Element[plugin], child of element[sdf], not defined in SDF. Copying[plugin] as children of [sdf].
Warning [Utils.cc:130] [/sdf/plugin[@name="gz::sim::systems::WavesVisual"]::L1]: XML Element[plugin], child of element[sdf], not defined in SDF. Copying[plugin] as children of [sdf].
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
[GUI] [Err] [VisualizeLidar.cc:251] Lidar pointer is not set
gz sim server: /usr/include/eigen3/Eigen/src/Core/DenseBase.h:261: void Eigen::DenseBase::resize(Eigen::Index, Eigen::Index) [with Derived = Eigen::Ref<Eigen::Array<double, -1, -1> >; Eigen::Index = long int]: Assertion rows == this->rows() && cols == this->cols() && "DenseBase::resize() does not actually allow one to resize."' failed. Stack trace (most recent call last) in thread 11477: #17 Object "[0xffffffffffffffff]", at 0xffffffffffffffff, in #16 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195de09ff, in #15 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195d4eb42, in #14 Object "/lib/x86_64-linux-gnu/libstdc++.so.6", at 0x7fe191e062b2, in #13 Object "/usr/lib/x86_64-linux-gnu/gz-sim-7/plugins/libgz-sim-sensors-system.so", at 0x7fe0dd0ab757, in gz::sim::v7::systems::SensorsPrivate::RenderThread() #12 Object "/usr/lib/x86_64-linux-gnu/gz-sim-7/plugins/libgz-sim-sensors-system.so", at 0x7fe0dd0aa126, in gz::sim::v7::systems::SensorsPrivate::RunOnce() #11 Object "/lib/x86_64-linux-gnu/libgz-sim7-rendering.so.7", at 0x7fe0dcffd469, in gz::sim::v7::RenderUtil::Update() #10 Object "/lib/x86_64-linux-gnu/libgz-sim7-rendering.so.7", at 0x7fe0dd0130fc, in #9 Object "/home/connor/colcon_ws/install/gz-waves1/lib/libgz-waves1-waves-visual-system.so", at 0x7fe0dc19136f, in gz::sim::v7::systems::WavesVisualPrivate::OnUpdate() #8 Object "/home/connor/colcon_ws/install/gz-waves1/lib/libgz-waves1.so.1", at 0x7fe0dc46950f, in gz::waves::OceanTilePrivate<gz::math::v7::Vector3<double> >::UpdateMesh(double, gz::common::Mesh*) #7 Object "/home/connor/colcon_ws/install/gz-waves1/lib/libgz-waves1.so.1", at 0x7fe0dc46a0c0, in gz::waves::OceanTilePrivate<gz::math::v7::Vector3<double> >::UpdateVertices(double) #6 Object "/home/connor/colcon_ws/install/gz-waves1/lib/libgz-waves1.so.1", at 0x7fe0dc4bcf35, in gz::waves::TrochoidIrregularWaveSimulation::DisplacementAndDerivAt(Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >) const #5 Object "/home/connor/colcon_ws/install/gz-waves1/lib/libgz-waves1.so.1", at 0x7fe0dc4bbb01, in gz::waves::TrochoidIrregularWaveSimulation::Impl::ElevationAt(Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >) #4 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195cf3e95, in __assert_fail #3 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195ce271a, in #2 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195ce27f2, in abort #1 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195cfc475, in raise #0 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195d50a7c, in pthread_kill Aborted (Signal sent by tkill() 11410 1000) gz sim gui: /usr/include/eigen3/Eigen/src/Core/DenseBase.h:261: void Eigen::DenseBase<Derived>::resize(Eigen::Index, Eigen::Index) [with Derived = Eigen::Ref<Eigen::Array<double, -1, -1> >; Eigen::Index = long int]: Assertion rows == this->rows() && cols == this->cols() && "DenseBase::resize() does not actually allow one to resize."' failed.
Stack trace (most recent call last) in thread 11641:
#31 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195d4eb42, in
#30 Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7fe1901beca0, in
#29 Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7fe1901bdaf1, in QThread::exec()
#28 Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7fe1903aa75a, in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag)
#27 Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7fe1904050b7, in QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag)
#26 Object "/lib/x86_64-linux-gnu/libglib-2.0.so.0", at 0x7fe18df953e2, in g_main_context_iteration
#25 Object "/lib/x86_64-linux-gnu/libglib-2.0.so.0", at 0x7fe18dfec6c7, in
#24 Object "/lib/x86_64-linux-gnu/libglib-2.0.so.0", at 0x7fe18df97d3a, in g_main_context_dispatch
#23 Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7fe190405a66, in
#22 Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7fe1903aef26, in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
#21 Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7fe1903abe39, in QCoreApplication::notifyInternal2(QObject*, QEvent*)
#20 Object "/lib/x86_64-linux-gnu/libQt5Widgets.so.5", at 0x7fe18fb05712, in QApplicationPrivate::notify_helper(QObject*, QEvent*)
#19 Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7fe1903d941d, in QObject::event(QEvent*)
#18 Object "/usr/lib/x86_64-linux-gnu/gz-gui-7/plugins/libMinimalScene.so", at 0x7fe1605566f8, in gz::gui::plugins::RenderThread::RenderNext(gz::gui::plugins::RenderSync*)
#17 Object "/usr/lib/x86_64-linux-gnu/gz-gui-7/plugins/libMinimalScene.so", at 0x7fe1605643c7, in gz::gui::plugins::RenderThreadRhiOpenGL::RenderNext(gz::gui::plugins::RenderSync*)
#16 Object "/usr/lib/x86_64-linux-gnu/gz-gui-7/plugins/libMinimalScene.so", at 0x7fe16055bb77, in gz::gui::plugins::GzRenderer::Render(gz::gui::plugins::RenderSync*)
#15 Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7fe1903abe39, in QCoreApplication::notifyInternal2(QObject*, QEvent*)
#14 Object "/lib/x86_64-linux-gnu/libQt5Widgets.so.5", at 0x7fe18fb05701, in QApplicationPrivate::notify_helper(QObject*, QEvent*)
#13 Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7fe1903abb99, in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*)
#12 Object "/usr/lib/x86_64-linux-gnu/gz-sim-7/plugins/gui/libGzSceneManager.so", at 0x7fe1580f2680, in gz::sim::v7::GzSceneManager::eventFilter(QObject*, QEvent*)
#11 Object "/lib/x86_64-linux-gnu/libgz-sim7-rendering.so.7", at 0x7fe12949b469, in gz::sim::v7::RenderUtil::Update()
#10 Object "/lib/x86_64-linux-gnu/libgz-sim7-rendering.so.7", at 0x7fe1294b10fc, in
#9 Object "/home/connor/colcon_ws/install/gz-waves1/lib/libgz-waves1-waves-visual-system.so", at 0x7fe084b3e36f, in gz::sim::v7::systems::WavesVisualPrivate::OnUpdate()
#8 Object "/home/connor/colcon_ws/install/gz-waves1/lib/libgz-waves1.so.1", at 0x7fe0821db50f, in gz::waves::OceanTilePrivate<gz::math::v7::Vector3 >::UpdateMesh(double, gz::common::Mesh*)
#7 Object "/home/connor/colcon_ws/install/gz-waves1/lib/libgz-waves1.so.1", at 0x7fe0821dc0c0, in gz::waves::OceanTilePrivate<gz::math::v7::Vector3 >::UpdateVertices(double)
#6 Object "/home/connor/colcon_ws/install/gz-waves1/lib/libgz-waves1.so.1", at 0x7fe08222ef35, in gz::waves::TrochoidIrregularWaveSimulation::DisplacementAndDerivAt(Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >, Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >) const
#5 Object "/home/connor/colcon_ws/install/gz-waves1/lib/libgz-waves1.so.1", at 0x7fe08222db01, in gz::waves::TrochoidIrregularWaveSimulation::Impl::ElevationAt(Eigen::Ref<Eigen::Array<double, -1, -1, 0, -1, -1>, 0, Eigen::OuterStride<-1> >)
#4 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195cf3e95, in __assert_fail
#3 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195ce271a, in
#2 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195ce27f2, in abort
#1 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195cfc475, in raise
#0 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe195d50a7c, in pthread_kill
Aborted (Signal sent by tkill() 11411 1000)

Then I get these errors when I try to use the ocean waves model (weirdly enough the "waves" model works properly.)
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
libEGL warning: egl: failed to create dri2 screen
[GUI] [Err] [VisualizeLidar.cc:251] Lidar pointer is not set
libEGL warning: egl: failed to create dri2 screen
Warning [Utils.cc:130] [/sdf/plugin[@name="gz::sim::systems::WavesVisual"]::L1]: XML Element[plugin], child of element[sdf], not defined in SDF. Copying[plugin] as children of [sdf].
Warning [Utils.cc:130] [/sdf/plugin[@name="gz::sim::systems::WavesVisual"]::L1]: XML Element[plugin], child of element[sdf], not defined in SDF. Copying[plugin] as children of [sdf].
Warning [Utils.cc:130] [/sdf/plugin[@name="gz::sim::systems::WavesVisual"]::L1]: XML Element[plugin], child of element[sdf], not defined in SDF. Copying[plugin] as children of [sdf].
Warning [Utils.cc:130] [/sdf/plugin[@name="gz::sim::systems::WavesVisual"]::L1]: XML Element[plugin], child of element[sdf], not defined in SDF. Copying[plugin] as children of [sdf].
[GUI] [Err] [VisualizeLidar.cc:251] Lidar pointer is not set
terminate called after throwing an instance of 'Ogre::ItemIdentityException'
what(): OGRE EXCEPTION(4:ItemIdentityException): A texture with name 'HeightMapTex(6)' already exists. (Real tex name: 'HeightMapTex(6)') in TextureGpuManager::createTexture at ./OgreMain/src/OgreTextureGpuManager.cpp (line 385)
Stack trace (most recent call last) in thread 11897:
#10 Object "[0xffffffffffffffff]", at 0xffffffffffffffff, in
#9 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f684a11d9ff, in
#8 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f684a08bb42, in
#7 Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7f68444c099d, in
#6 Object "/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7f68444bef90, in qTerminate()
#5 Object "/lib/x86_64-linux-gnu/libstdc++.so.6", at 0x7f68461152b6, in std::terminate()
#4 Object "/lib/x86_64-linux-gnu/libstdc++.so.6", at 0x7f684611524b, in
#3 Object "/lib/x86_64-linux-gnu/libstdc++.so.6", at 0x7f6846109bbd, in
#2 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f684a01f7f2, in abort
#1 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f684a039475, in raise
#0 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f684a08da7c, in pthread_kill
Aborted (Signal sent by tkill() 11716 1000)

I havent modified these scripts in any way, so I am not sure why they wouldn't work.

Cheers,

Connor

Hi Rhys,

I have started up a VM in Ubuntu 20.04 to try and get Gazebo Garden working with ROS2 and this simulation. I got Gazebo Garden installed properly, however when I add asv_sim to the workspace which Garden in it, the package will not build and gives me the following errors.

/home/connort/gazebo_garden/src/asv_wave_sim/gz-waves/src/SubMeshWithTangents.cc:60:1: error: function ‘gz::common::SubMeshWithTangents::SubMeshWithTangents(gz::common::SubMeshWithTangents&&)’ defaulted on its redeclaration with an exception-specification that differs from the implicit exception-specification ‘’
   60 | SubMeshWithTangents::SubMeshWithTangents(SubMeshWithTangents &&_submesh)
      | ^~~~~~~~~~~~~~~~~~~
/home/connort/gazebo_garden/src/asv_wave_sim/gz-waves/src/SubMeshWithTangents.cc:79:22: error: function ‘gz::common::SubMeshWithTangents& gz::common::SubMeshWithTangents::operator=(gz::common::SubMeshWithTangents&&)’ defaulted on its redeclaration with an exception-specification that differs from the implicit exception-specification ‘’
   79 | SubMeshWithTangents &SubMeshWithTangents::operator=(SubMeshWithTangents &&_submesh)
      |                      ^~~~~~~~~~~~~~~~~~~
make[2]: *** [src/CMakeFiles/gz-waves1.dir/build.make:167: src/CMakeFiles/gz-waves1.dir/SubMeshWithTangents.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:428: src/CMakeFiles/gz-waves1.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
---
Failed   <<< gz-waves1 [51.8s, exited with code 2]

What would be the reason for this error?

Cheers,

Connor

The hydrodynamics plugin currently applies buoyancy and drag forces to all links in a model. The proposal is to allow the user to specify which links should be included / excluded from the calculation. For example the contribution from sensor links is likely to be small and these could be safely excluded without a material impact to the physical behaviour.

See the gz-sim-buoyancy-system plugin and the graded_buoyancy.sdf for an example where certain models and links have the calculation enabled.

<plugin
  filename="gz-marine1-hydrodynamics-system"
  name="gz::sim::systems::Hydrodynamics">

   <!-- Hydrodynamics -->
   <hydrodynamics>
    <damping_on>1</damping_on>
    <viscous_drag_on>1</viscous_drag_on>
    <pressure_drag_on>1</pressure_drag_on>

    <!-- Linear and Angular Damping -->  
    <cDampL1>1.0E-6</cDampL1>
    <cDampL2>1.0E-6</cDampL2>
    <cDampR1>1.0E-6</cDampR1>
    <cDampR2>1.0E-6</cDampR2>

    <!-- 'Pressure' Drag -->
    <cPDrag1>1.0E+2</cPDrag1>
    <cPDrag2>1.0E+2</cPDrag2>
    <fPDrag>0.4</fPDrag>
    <cSDrag1>1.0E+2</cSDrag1>
    <cSDrag2>1.0E+2</cSDrag2>
    <fSDrag>0.4</fSDrag>
    <vRDrag>1.0</vRDrag>

    <!-- Either: enable specific links -->
    <enable>base_link</enable>
    <enable>left_hull</enable>
    <enable>right_hull</enable>

    <!-- Or: disable specific links -->
    <disable>imu_sensor_link</disable>

  </hydrodynamics>
</plugin>

Hey Rhys,

I've taken a closer look at this package, and taken a look at the article by Jacques Kerner, which describes the method for simulating buoyancy you've applied and the approximations, simplifications and limitations it comes with. He also describes the quite arbitrary constants he uses for the damping of the system. These are reflected in your code as cDampL1, cDampL2, cDampR1, cDampR2 for linear and angular drag, and cPDrag1, cPDrag2, fPDrag, cSDrag1, cSDrag2, fSDrag and vRDrag for 'pressure' drag (probably the most dubious of all).

Since most of these variables have no direct link to physical processes, what did you to to find the standard values for the variables? And how would I go about determining what values would be right for my simulation? Did you eyeball the values until the behaviour seemed appropriate, or is there more thought behind them?

Kind regards,

Julius

The wave model currently assumes that the pose of the wave field is at the origin. Setting the pose to another value will move the visuals but the physics is not affected.

Desired behaviour

• The position components of the wave model <pose> translate both physics and visual.

The hydrodynamics plugin assumes that all links of a model have a valid collision mesh. If the mesh is missing the plugin fails to load correctly but does not supply a very helpful warning.

Suggested behaviour:

1. Either - ignore links with missing collision meshes
2. Or - emit a better error and report which link(s) are missing collision meshes

It may also be worth emitting warnings when the collision mesh contains a large number of vertices or near degenerate triangles which will give rise to poor numerical behaviour.

The waves model segfaults on exit. This occurs for both the client and server.

server

% gz sim -v4 -s -r waves.sdf 
...
[Msg] Publishing dynamic pose messages on [/world/waves/dynamic_pose/info]
^C[Dbg] [SignalHandler.cc:141] Received signal[2].
[Dbg] [ServerPrivate.cc:110] Server received signal[2]
[Dbg] [Sensors.cc:420] SensorsPrivate::Stop
[Dbg] [Sensors.cc:263] Rendering Thread initialized
[Dbg] [Sensors.cc:406] SensorsPrivate::RenderThread stopped
[Dbg] [gz.cc:356] Shutting down gz-sim-server
[Dbg] [SimulationRunner.cc:521] [Dbg] [SimulationRunner.cc:521] [Dbg] [SimulationRunner.cc:521] [Dbg] [SimulationRunner.cc:521] Exiting postupdate worker thread (Exiting postupdate worker thread (Exiting postupdate worker thread ()
20)
)
Stack trace (most recent call last):
#25   Object "ruby", at 0x108d82f09, in main + 99
#24   Object "libruby.3.0.dylib", at 0x108dfc573, in ruby_run_node + 86
#23   Object "libruby.3.0.dylib", at 0x108dfc6df, in rb_ec_exec_node + 288
#22   Object "libruby.3.0.dylib", at 0x108f3bcc0, in rb_vm_exec + 1907
#21   Object "libruby.3.0.dylib", at 0x108f2caa5, in vm_exec_core + 7454
#20   Object "libruby.3.0.dylib", at 0x108f3facd, in vm_sendish + 1292
#19   Object "libruby.3.0.dylib", at 0x108f457ff, in vm_call_cfunc_with_frame + 345
#18   Object "fiddle.bundle", at 0x10a5cc71a, in function_call + 1486
#17   Object "libruby.3.0.dylib", at 0x108f07da4, in rb_nogvl + 178
#16   Object "fiddle.bundle", at 0x10a5ccd0f, in nogvl_ffi_call + 26
#15   Object "libffi.dylib", at 0x7fff2d95c22c, in ffi_call_int + 698
#14   Object "libffi.dylib", at 0x7fff2d95c8f5, in ffi_call_unix64 + 85
#13   Object "libgz-sim7-gz.7.0.0~pre1.dylib", at 0x10a6143bc, in runServer + 4220
#12   Object "libgz-sim7.7.dylib", at 0x10aac3fad, in gz::sim::v7::Server::~Server() + 29
#11   Object "libgz-sim7.7.dylib", at 0x10aaccc10, in gz::sim::v7::ServerPrivate::~ServerPrivate() + 592
#10   Object "libgz-sim7.7.dylib", at 0x10aadcaae, in gz::sim::v7::SimulationRunner::~SimulationRunner() + 14
#9    Object "libgz-sim7.7.dylib", at 0x10aadc82c, in gz::sim::v7::SimulationRunner::~SimulationRunner() + 1196
#8    Object "libgz-sim7.7.dylib", at 0x10aae231f, in gz::sim::v7::SystemManager::~SystemManager() + 303
#7    Object "libgz-sim7.7.dylib", at 0x10aaf0492, in gz::plugin::detail::ComposePlugin<gz::plugin::SpecializedPlugin<gz::sim::v7::System>, gz::plugin::SpecializedPlugin<gz::sim::v7::ISystemConfigure, gz::sim::v7::ISystemPreUpdate, gz::sim::v7::ISystemUpdate, gz::sim::v7::ISystemPostUpdate> >::~ComposePlugin() + 18
#6    Object "libgz-plugin2.2.dylib", at 0x10b405fa2, in gz::plugin::Plugin::~Plugin() + 114
#5    Object "libgz-plugin2.2.dylib", at 0x10b40682e, in gz::plugin::PluginWithDlHandle::~PluginWithDlHandle() + 46
#4    Object "libgz-waves1-waves-visual-system.1.", at 0x12e98b203, in gz::sim::v7::systems::WavesVisual::~WavesVisual() + 67
#3    Object "libgz-waves1-waves-visual-system.1.", at 0x12e990b11, in gz::sim::v7::systems::WavesVisualPrivate::~WavesVisualPrivate() + 97
#2    Object "libsystem_platform.dylib", at 0x7fff203c0d7c, in _sigtramp + 28
#1    Object "libgz-tools2-backward.dylib", at 0x10a5ddfad, in backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 13
#0    Object "libgz-tools2-backward.dylib", at 0x10a5de016, in backward::SignalHandling::handleSignal(int, __siginfo*, void*) + 70
zsh: segmentation fault  gz sim -v4 -s -r waves.sdf

client

% gz sim -v4 -g
...
[GUI] [Msg] Loading plugin [gz-rendering-ogre2]
[GUI] [Dbg] [EntityContextMenuPlugin.cc:79] Entity context menu plugin is using camera [scene::Camera(65527)]
^C[GUI] [Dbg] [SignalHandler.cc:141] Received signal[2].
[GUI] [Dbg] [Gui.cc:331] Shutting down gz-sim-gui
[GUI] [Dbg] [Application.cc:165] Terminating application.
[GUI] [Msg] Loading plugin [gz-rendering-ogre2]
[GUI] [Dbg] [MinimalScene.cc:662] Destroy scene [scene]
Stack trace (most recent call last) in thread 123145401655296:
#24   Object "libsystem_pthread.dylib", at 0x7fff2037b8fc, in _pthread_start + 224
#23   Object "QtCore", at 0x10b5a7b3a, in QThread::qt_metacall(QMetaObject::Call, int, void**) + 1178
#22   Object "QtCore", at 0x10b5a6c2c, in QThread::exec() + 140
#21   Object "QtCore", at 0x10b7670c7, in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 471
#20   Object "QtCore", at 0x10b7c9dd9, in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 73
#19   Object "QtCore", at 0x10b76bbd8, in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 792
#18   Object "QtCore", at 0x10b76aac7, in QCoreApplication::notifyInternal2(QObject*, QEvent*) + 167
#17   Object "QtWidgets", at 0x10a9f6a00, in QApplication::notify(QObject*, QEvent*) + 480
#16   Object "QtWidgets", at 0x10a9f5646, in QApplicationPrivate::notify_helper(QObject*, QEvent*) + 262
#15   Object "QtCore", at 0x10b7936e9, in QObject::event(QEvent*) + 745
#14   Object "libMinimalScene.dylib", at 0x138515f36, in gz::gui::plugins::RenderThread::ShutDown() + 22
#13   Object "libMinimalScene.dylib", at 0x138520745, in gz::gui::plugins::RenderThreadRhiMetal::ShutDown() + 21
#12   Object "libMinimalScene.dylib", at 0x1385156c9, in gz::gui::plugins::GzRenderer::Destroy() + 665
#11   Object "libgz-rendering7.7.dylib", at 0x13857b189, in gz::rendering::v7::BaseRenderEngine::DestroyScene(std::__1::shared_ptr<gz::rendering::v7::Scene>) + 73
#10   Object "libgz-waves1-waves-visual-system.1.", at 0x143420b08, in gz::rendering::v7::BaseStore<gz::rendering::v7::Scene, gz::rendering::v7::Ogre2Scene>::Destroy(std::__1::shared_ptr<gz::rendering::v7::Scene>) + 120
#9    Object "libgz-waves1-waves-visual-system.1.", at 0x1434332ae, in gz::rendering::v7::BaseStore<gz::rendering::v7::Scene, gz::rendering::v7::Ogre2Scene>::DestroyImpl(std::__1::__map_iterator<std::__1::__tree_iterator<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::shared_ptr<gz::rendering::v7::Ogre2Scene> >, std::__1::__tree_node<std::__1::__value_type<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::shared_ptr<gz::rendering::v7::Ogre2Scene> >, void*>*, long> >) + 46
#8    Object "libgz-rendering7-ogre2.7.dylib", at 0x14358f412, in gz::rendering::v7::Ogre2Scene::Destroy() + 34
#7    Object "libOgreMain.2.2.6.dylib", at 0x143aabf23, in Ogre::SceneManager::destroyAllMovableObjectsByType(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 291
#6    Object "libOgreMain.2.2.6.dylib", at 0x1439b45ae, in Ogre::Item::~Item() + 14
#5    Object "libOgreMain.2.2.6.dylib", at 0x1439b4403, in Ogre::Item::~Item() + 99
#4    Object "libOgreMain.2.2.6.dylib", at 0x143a73dc8, in Ogre::Renderable::~Renderable() + 40
#3    Object "libOgreMain.2.2.6.dylib", at 0x143969467, in Ogre::HlmsDatablock::_unlinkRenderable(Ogre::Renderable*) + 39
#2    Object "libsystem_platform.dylib", at 0x7fff203c0d7c, in _sigtramp + 28
#1    Object "libgz-tools2-backward.dylib", at 0x1088d3fad, in backward::SignalHandling::sig_handler(int, __siginfo*, void*) + 13
#0    Object "libgz-tools2-backward.dylib", at 0x1088d4016, in backward::SignalHandling::handleSignal(int, __siginfo*, void*) + 70
zsh: segmentation fault  gz sim -v4 -g

Hello all,

I followed the install guide, but unfortunately three strange things happen.

The first is that the sky in gazebo looks strange, like a moire pattern.
Secondly, the above error shows up, which leads me to the third error, all objects immediately sink to the bottom on sim start.

I get a similar error on the client complaining about missing WavesVisual

This is on a freshly installed Ubuntu 22.04 system, gazebo Garden. Everything seemed to compile and exports were done.

What are next steps to help debug?

Thanks!

This questions was asked to Rhys via email, here is the conversation history up to this point for anyone interested.

My initial email:
I am trying to use your ASV wave simulator and I have some issues with the collision of the waves. I am trying to use sonar sensors to measure the wave height in Gazebo, but the waves being generated are purely visual and have no collision (which you know).

So, I am wondering: is there any way to apply collision to the visual wavefield? Or is there a way to apply the Gerster wave .vert and .frag files to some sort of collision mesh so I can have my sensors detect the water? I am working on Ubuntu 18.04 with ROS Melodic.

Any help you can provide would be greatly appreciated.

The first response from Rhys:
The physical aspects of the waves are handled by the buoyancy and hydrodynamics physics plugins that are attached to the model. If the waves had a collision as well then the objects would sit on top of it (like a terrain), and there would be a significant performance impact as the collision algorithm would need to examine all the wave triangles.

The waves do return depth information when sensed by a depth camera, so perhaps another approach would be to look into how your sonar sensor is getting a return. Is it just the standard sensor available with Gazebo or something custom?

Second email to Rhys from me:
I figured giving the waves' collision would cause the simulation to be too computationally intense (especially for my hardware I think), though my solution for this would be to make the wave area as small as possible.

As for my sensor, I am using the sonar sensor from the Hector Quadrotor package. I believe this is simply a ray that looks for something to collide with to return a height.

To solve this problem I was considering trying to adjust the sensor to detect points based on the Gerstner waves being generated by the Wavefield script. However, I am confused about what element of this file defines the calculated wavefield at each time step, could you provide any insight into this?

I am looking to pull the z components of all of the points in the wavefield so that I can use these as conditions for sensor detection.

Answer to the second email from Rhys:
I think the approach you’re looking for may be similar to the way a GPU LIDAR sensor is implemented in Gazebo. I think this does record a return from the waves (even for the earlier version using the Gerstner waves scripts).

There is a simple wave example included in the more recent Gazebo distributions. I’ll take a look at whether that example results in a return from the waves for a start and from that we may come up with a way for you to estimate wave heights from a range sensor.

A method of last resort would be to use the same ray intersection calculation used for the wave height in the hydrodynamics plugin (but tracing the ray at a given angle from the sensor location). That would be less efficient than a GPU based approach using the scene depth buffer though.

The rest of this conversation will be had here so anyone can access the information. Thanks for the help Rhys!

The depth calculation using the WavefieldSampler accounts for about 18% of the compute time in the hydrodynamics update. This issue is to track improvements to optimise performance.

• Axis align the water patch with the coordinates used for the link / collision mesh
• Create version of water patch and grid that does not require CGAL
  • Assume that the line search is always along one axis (z)
  • Take care with floating point comparisions when determining the cell / triangle each vertex projects into
  • Precalculate normals and plane equations for each triangle

Hi, I'm trying to use the asv_wave_sim package to simulate an autonomous buoy in gazebo. I've a .urdf file that describes the buoy and the motors with some plugin for simulate imu, thrusters, etc in ROS. I'm trying to include the libHydrodynamicsPlugin.so to perform the buoyancy of the main <link> of the buoy, but without success. I'm reading the documentation and the examples in the wiki but i see only the tag for the .sdf file. I've tried to include the same tag in the <gazebo> tag of the .urdf but not works: the buoy go down. Can any help me to understand how can include the HydrodynamicsPlugin in a .urdf file? Thanks for your attention.

Hello, I have used your plug-in, but when I set the coordinate z of the ocean model to -25, the objects I placed (like boxes) will still float on the original horizontal plane. How can I adjust the position of the horizontal?

The default version of cgal installed by brew on macOS is now 5.6 which has compilation issues.

Starting >>> gz-waves1
--- stderr: gz-waves1                                              
Call Stack (most recent call first):
  /Users/rhys/Code/osrf/gz_garden_ws/install/share/cmake/gz-cmake3/cmake3/GzCodeCheck.cmake:4 (include)
  /Users/rhys/Code/osrf/gz_garden_ws/install/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:292 (_gz_setup_target_for_codecheck)
  CMakeLists.txt:181 (gz_configure_build)
This warning is for project developers.  Use -Wno-dev to suppress it.

/Volumes/MacPro2_DV1/Code/robotics/gz_waves_ws/src/asv_wave_sim/gz-waves/src/WavefieldSampler.cc:97:11: error: non-const lvalue reference to type 'boost::iterators::detail::iterator_facade_base<CGAL::Surface_mesh<CGAL::Point_3<CGAL::Simple_cartesian<double>>>::Index_iterator<CGAL::SM_Vertex_index>, CGAL::SM_Vertex_index, std::random_access_iterator_tag, CGAL::SM_Vertex_index, long, false, false>::reference' (aka 'CGAL::SM_Vertex_index') cannot bind to a temporary of type 'boost::iterators::detail::iterator_facade_base<CGAL::Surface_mesh<CGAL::Point_3<CGAL::Simple_cartesian<double>>>::Index_iterator<CGAL::SM_Vertex_index>, CGAL::SM_Vertex_index, std::random_access_iterator_tag, CGAL::SM_Vertex_index, long, false, false>::reference' (aka 'CGAL::SM_Vertex_index')
    auto& v0 = *it.first;
          ^    ~~~~~~~~~
/Volumes/MacPro2_DV1/Code/robotics/gz_waves_ws/src/asv_wave_sim/gz-waves/src/WavefieldSampler.cc:98:11: error: non-const lvalue reference to type 'boost::iterators::detail::iterator_facade_base<CGAL::Surface_mesh<CGAL::Point_3<CGAL::Simple_cartesian<double>>>::Index_iterator<CGAL::SM_Vertex_index>, CGAL::SM_Vertex_index, std::random_access_iterator_tag, CGAL::SM_Vertex_index, long, false, false>::reference' (aka 'CGAL::SM_Vertex_index') cannot bind to a temporary of type 'boost::iterators::detail::iterator_facade_base<CGAL::Surface_mesh<CGAL::Point_3<CGAL::Simple_cartesian<double>>>::Index_iterator<CGAL::SM_Vertex_index>, CGAL::SM_Vertex_index, std::random_access_iterator_tag, CGAL::SM_Vertex_index, long, false, false>::reference' (aka 'CGAL::SM_Vertex_index')
    auto& v1 = *it.second;
          ^    ~~~~~~~~~~
2 errors generated.
gmake[2]: *** [src/CMakeFiles/gz-waves1.dir/build.make:244: src/CMakeFiles/gz-waves1.dir/WavefieldSampler.cc.o] Error 1
gmake[2]: *** Waiting for unfinished jobs....
gmake[1]: *** [CMakeFiles/Makefile2:413: src/CMakeFiles/gz-waves1.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2
---
Failed   <<< gz-waves1 [25.8s, exited with code 2]
Aborted  <<< asv_sim2 [30.3s]                                  

Summary: 1 package finished [30.7s]
  1 package failed: gz-waves1
  1 package aborted: asv_sim2
  2 packages had stderr output: asv_sim2 gz-waves1

A temp fix is to pin cgal to version 5.5.2.

The readme shows a gif of a sailing simulation, and I am looking to replicate that. The closest thing I could find is your old sail_sim_docker repo here: https://github.com/srmainwaring/sail_sim_docker but that uses a much older version of Gazebo than what is shown in the readme.

Are the files for running the shown simulation publicly available?

Thanks!

Hi, I'm trying to build the package on ROS Noetic (installed on Ubuntu 20.04), but a lot of errors are raised in the catkin_make process. Below an example of some errors' print:

/home/user/ros_ws/src/asv_wave_sim/asv_wave_sim_gazebo_plugins/src/Utilities.cc:154:44: error: ‘_sdf’ was not declared in this scope; did you mean ‘sdf’?
  154 | bool Utilities::SdfParamBool(sdf::Element& _sdf,
      |                                            ^~~~
      |                                            sdf
/home/user/ros_ws/src/asv_wave_sim/asv_wave_sim_gazebo_plugins/src/Utilities.cc:155:3: error: expected primary-expression before ‘const’
  155 |   const std::string& _paramName, const bool _defaultVal)
      |   ^~~~~
/home/user/ros_ws/src/asv_wave_sim/asv_wave_sim_gazebo_plugins/src/Utilities.cc:155:34: error: expected primary-expression before ‘const’
  155 |   const std::string& _paramName, const bool _defaultVal)
      |                                  ^~~~~
/home/user/ros_ws/src/asv_wave_sim/asv_wave_sim_gazebo_plugins/src/Utilities.cc:155:56: error: expression list treated as compound expression in initializer [-fpermissive]
  155 |   const std::string& _paramName, const bool _defaultVal)
      |                                                        ^
/home/user/ros_ws/src/asv_wave_sim/asv_wave_sim_gazebo_plugins/src/Utilities.cc:160:8: error: ‘size_t asv::Utilities::SdfParamSizeT’ is not a static data member of ‘class asv::Utilities’
  160 | size_t Utilities::SdfParamSizeT(sdf::Element& _sdf,
      |        ^~~~~~~~~
/home/user/ros_ws/src/asv_wave_sim/asv_wave_sim_gazebo_plugins/src/Utilities.cc:166:48: error: ‘_sdf’ was not declared in this scope; did you mean ‘sdf’?
  166 | double Utilities::SdfParamDouble(sdf::Element& _sdf,
      |                                                ^~~~
      |                                                sdf

I think the problem is related to the building process of the plugins files, maybe some change in the gcc compiler.
Had anyone tryed to run the asv_wave_sim package on Noetic? Thanks for the support.

Dear ASV Wave Developers!
I am currently working with your ASV Wave Simulator plugins on ROS Noetic, and in particular exploiting the asv_wave_sim devel branch, combined with uuv_simulator (in particular the libuuv_thruster_ros_plugin). I have built the urdf model of my vehicle, contaning the links, joints ecc.) combined with the urdf model of the actuators and gps/imu models.
When I start my simulation I get the following error:

[Msg] Vertex:     24
[Msg] links:  6
[Msg] meshes: 6
[Msg] Water patch size: 2.52761
[Msg] Water patch size: 0
[Err] [Model.cc:1155] Exception occured in the Init function of plugin with name[hydrodynamics] and filename[libHydrodynamicsPlugin.so]. This plugin will not run

I have done some studies regarding your toolbox. I have become aware that the plug in at the beginning tries to create a water patch size not only for the vehicle but also for the thrusters. The reason for this is that there is a continuous joint connects the thrusters links to the vehicle link in the thruster urdf (if I change it to fixed then there is no water patch size for the thrusters, but the thruster plugin does not work).
The problem can actually be solved by specifying the collision tag inside the urdf of the thrusters (doing so I get a real time factor of 0.01 and simulations are impossible). But since I have decided to not put any collision inside the urdf of the thrusters, I would like to solve this problem and get rid of the previous error.

I would like to add that we successfully made all work (only on one machine) with no collision, the water patch size gets set to 0 for all thruster and no error pops up. We are not able to make it work with other machines.

Hi!

Thank you gor this great project.

I have a project where I need to simulate a tugboat with a propulsion system.

Is there any tutorial that could walk me through the required customization steps?

Would the the hydrodynamic plugin in this project be good enough to use in this case? Or I need to implement a different one?

I also believe that I would need to implement a thruster model, right?
Would the one in the VRX project ( https://github.com/osrf/vrx/blob/master/usv_gazebo_plugins/src/usv_gazebo_thrust_plugin.cc ) work ?

Any hints are highly appreciated.

Thanks.

When I run the asv_wave_sim and the boat reaches the end of the water surface it just keeps on floating in air. Is there a way to have the entire map be water and when it reaches the end it just loops back?

The water is not rendered when under the surface for the FFT generated waves.

The FFT simulation currently executes the FFT plan each time functions such as ElevationAt are called, and updates the amplitudes when the time is updated.

This causes an issue with the new varieties of the function that allow access to individual elements because the optimised version of the FFT using Hermitian symmetry destroys the input storage during the calculation. Calling fftw_execute twice will give erroneous results the second time. The previous complex to complex plan does not have this problem.

The proposal is to implement lazy evaluation, so the FFT for each plan is only executed once after a time update.

The hydrodynamics plugin does not account for the pose of the collision relative to the origin of the link

• branch: gz-marine and dependencies
• platform: all

Description

The hydrodynamics system plugin uses the model's collision meshes to calculate buoyancy and hydrodynamics forces. At each update step a copy of the collision mesh (CGAL surface mesh) is updated to place it the the correct location relative to the wave field. The engine then determines the number of submerged triangles, centroid heights above the local wave field, pressure forces etc.

The function ApplyPose in src/systems/hydrodynamics/Hydrodynamics.cc applies the transformation. In the functions HydrodynamicsPrivate::InitPhysics and HydrodynamicsPrivate::UpdatePhysics the link pose is used; no account is taken for the pose of the collision relative to the link origin.

The results is incorrect buoyancy forces for objects with offset collisions. This may result in objects floating at the wrong level, or upside down.

Example

The example illustrates a number of spherical buoys with the visuals, collisions and inertial elements offset from the link origin. Examples 4 (left most) and 3 (second from left) have the CoM at the link origin but the collision off set 0.5 m below. In both cases the expected behaviour is displayed in example 2 (second from right), where the CoM is displaced down 0.5 m and the collision remains at the origin.

Hi,
First, thank you for your projects! I am trying to clone your branch fft_waves with gazebo11. everything works ok but the ocean model is crushing. the error I get is libOceanVisualPlugin.so: undefined symbol: ZN6gazebo9rendering10AttachMeshERNS0_6VisualERKNSt7__cxx111basic_stringIcSt11char_traitsIcESaIcEEESA_bSA

when I check it with c++filt I get:
gazebo::rendering::AttachMesh(gazebo::rendering::Visual&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, bool, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)

can you please help me fix it?

CGAL 5.4 on Ubuntu 22.04 is raising a CGAL::Precondition_exception because the calculation of submerged triangles results in some arrangements with collinear points.

terminate called after throwing an instance of 'CGAL::Precondition_exception'
  what():  CGAL ERROR: precondition violation!

The library requires additional checks that all mesh triangles are non-degenerate, and should handle exceptions gracefully.

Replicate

System: Ubuntu Jammy (22.04)

$ gz sim -v4 -s -r waves.sdf

Only the spherical buoy needs to be included to produce the error.

Related

There are 2 failing tests in UNIT_CGAL_TEST on Ubuntu.

$ ./build/gz-marine1/bin/UNIT_CGAL_TEST 
[==========] Running 15 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 15 tests from CGAL
[ RUN      ] CGAL.Surprising
[       OK ] CGAL.Surprising (0 ms)
[ RUN      ] CGAL.SurfaceMesh
[       OK ] CGAL.SurfaceMesh (0 ms)
[ RUN      ] CGAL.AABBPolyhedronFacetIntersection
[       OK ] CGAL.AABBPolyhedronFacetIntersection (0 ms)
[ RUN      ] CGAL.SurfaceMeshGridCell
unknown file: Failure
C++ exception with description "CGAL ERROR: precondition violation!
Expr: ! running
File: /usr/include/CGAL/Timer.h
Line: 83" thrown in the test body.
[  FAILED  ] CGAL.SurfaceMeshGridCell (0 ms)
[ RUN      ] CGAL.SurfaceMeshGrid
[       OK ] CGAL.SurfaceMeshGrid (1 ms)
[ RUN      ] CGAL.SurfaceMeshModifyGrid
[       OK ] CGAL.SurfaceMeshModifyGrid (0 ms)
[ RUN      ] CGAL.SurfaceMeshWavefield
[       OK ] CGAL.SurfaceMeshWavefield (1285 ms)
[ RUN      ] CGAL.VertexRangeIterator
[       OK ] CGAL.VertexRangeIterator (0 ms)
[ RUN      ] CGAL.CreateTriangulationN
unknown file: Failure
C++ exception with description "CGAL ERROR: assertion violation!
Expr: n == N[2]
File: /usr/include/CGAL/Triangulation_ds_face_base_2.h
Line: 224" thrown in the test body.
[  FAILED  ] CGAL.CreateTriangulationN (0 ms)
[ RUN      ] CGAL.CreateTriangulationHierarchyN
[       OK ] CGAL.CreateTriangulationHierarchyN (0 ms)
[ RUN      ] CGAL.CreateTriangulation3
[       OK ] CGAL.CreateTriangulation3 (0 ms)
[ RUN      ] CGAL.CreateTriangulation4
[       OK ] CGAL.CreateTriangulation4 (0 ms)
[ RUN      ] CGAL.CreateConstrainedTrianguation4
[       OK ] CGAL.CreateConstrainedTrianguation4 (0 ms)
[ RUN      ] CGAL.CreateCTAlt
[       OK ] CGAL.CreateCTAlt (0 ms)
[ RUN      ] CGAL.CreateCTAltN
[       OK ] CGAL.CreateCTAltN (159 ms)
[----------] 15 tests from CGAL (1447 ms total)

[----------] Global test environment tear-down
[==========] 15 tests from 1 test suite ran. (1447 ms total)
[  PASSED  ] 13 tests.
[  FAILED  ] 2 tests, listed below:
[  FAILED  ] CGAL.SurfaceMeshGridCell
[  FAILED  ] CGAL.CreateTriangulationN

 2 FAILED TESTS

Hey Rhys,

First of all I wanted to thank you again for creating this package; it has been one of the foundations of a project I've been doing, and it has not disappointed, so thanks a lot!

I recently discovered your fft_waves branch and have been playing with the concept of implementing a complex wavefield with Fourier Transforms. I would like to try to implement it in my project, but I have two questions:

First of all, I see that since the branch is still experimental, there is no possibility to change the wavefield. To be able to change this wavefield to a combination of different waves is an obvious benefit, so I was wandering what files I would have to alter to try to implement a way to change the wave frequencies. I found the following file, but there may be more connections which I'm missing:

WaveSimulationFFTW.cc

Second, I was wondering about the performance of the fft_waves code. The code from the master branch has proven useful, but the performance I've been getting has not been super. I run the simulation in a Virtual Machine, so this probably reduces performance somewhat. To give an example: In an ocean world with no waves, I place 3 meshes with buoyancy. Two with ~300 faces and one with ~800 faces. I get a realtime factor of ~0.2, and when I publish a wave message, it drops quite a bit further. How does the performance of the fft_waves branch compare to that of the main?

Thanks,

Julius

Track changes required to limit CGAL use to internal calculations and use Eigen types in the interface.

• Change Wavefield.hh to use Eigen::Vector3d.

The ocean_waves model crashes on macOS if shader language blocks for both metal and glsl are provided.

<shader language="glsl">
  <vertex>materials/waves_vs.glsl</vertex>
  <fragment>materials/waves_fs.glsl</fragment>
</shader>
<shader language="metal">
  <vertex>materials/waves_vs.metal</vertex>
  <fragment>materials/waves_fs.metal</fragment>
</shader>

The plugin attempts to load the glsl shaders instead of the metal ones.

This issue is to track adding a ship landing example using the WAM-V (scaled) and an Alti-Transition quad-plane from ArduPilot/SITL_Models. It is intended as a PoC / demo and is not intended to be merged back into the ignition-marine branch.

Example branch

https://github.com/srmainwaring/asv_wave_sim/tree/feature/ship-landing-demo

Tasks

• Add scaled up version of the WAM-V model
• Rescale wave model (larger dimension / lower local resolution)
• Ensure Hydrodynamics water patch is sufficient
• Enable scaling / steepness params to be adjusted for FFT
• Update SITL params for WAM-V
• Update joint PID controller params for WAM-V
• Add example launch files for SITL and MAVProxy
• Add user guide for building and running the example

Overview

We would like to combine the non-linear hydrostatic restoring force model used in asv_wave_sim with a linear potential flow wave-body interaction model.

The initial application is to buoys and other structures that satisfy the requirement that the displacements about an initial condition are expected to be small. However some of the features may be useful for surface vehicles, in particular the wave radiation damping and added mass contributions from the linear model may provide a better mechanism than the current model, particularly for larger / more massive vessels.

Approach

The linear wave-body model resolves the interaction into a number of different forces and the way these are incorporated in the simulation differs depending on the type of waves.

Forces

• Buoyancy
• Linear hydrostatic restoring forces
• Wave radiation damping
• Wave radiation added mass
• Wave excitation

Waves

• No waves (decay tests)
• Regular waves, single frequency
• Regular waves, multi-frequency
• Random waves, multi-frequency (FFT methods)

The proposed approach is to progress through the cases starting with the simplest model, no waves with linear hydrostatic restoring forces, and progressively work through the additional forces for each wave category before moving onto a more complex wave model.

Implementation

A working demonstration of the model is available on the demo/linear-wave-body branch which will be used to track progress:

• #70
• #71
• #72
• #73
• #74
• #75
• #76
• #77

Hi Rhys,

I have been using this simulator to good effect and a part of my testing requires using sensor data to determine wave characteristics. I have developed a ROS2 node to determine the wave period, and it seems to be working properly. I have noticed a discrepancy though.

What I noticed is this: If I set the period of regular, sinusoidal waves to 3 then the true wave period is closer to 4 seconds. Similarly, if I set it to 4 the period seems to be closer to 6 seconds. Is this an error which how the period is determined? If I use a timer and track the period myself I find it to be 6 seconds as well, so I'm confused why the true period is a second or two off of what I am giving the model as an argument for the period.

Cheers,

Connor

Hi, I am trying to get this to work on ROS1 Noetic ,ubuntu 22.04. But I only see options for ROS2 and ROS1 Melodic. The Melodic version has a lot of errors if downloaded in noetic environment. So if someone already has it working in Noetic then this would be very helpful. If not I will have to try to get it working using a VM running Melodic.

I am on Ubuntu 22.04 using gazebo garden with ROS2 Humble.
When using gz sim -v4 -r mumbles_head.sdf, though GUI does open up, the server crashes with the following error

terminate called after throwing an instance of 'Ogre::ItemIdentityException'
 what():  OGRE EXCEPTION(4:ItemIdentityException): A texture with name 'HeightMapTex(6)' already exists. (Real tex name: 
'HeightMapTex(6)') in TextureGpuManager::createTexture at ./OgreMain/src/OgreTextureGpuManager.cpp (line 385)

Hi,

First of all thank you for your work.

I am noticing performance issues when using the FFT waves. The Gazebo starts to jitter a lot. When using the sinusoidal waves, the simulation is butter smooth. My assumption is that the FFT waves are more expensive to compute? Is there anything that can be done to increase the performance?

Edit: When I forget to set the environment values correctly, the WavesVisual plugin is not loaded. As a result, the waves are not rendered but the wave dynamics still seem to be working in this case. The jittering is also gone and the performance is smooth. So might this be a rendering issue?

Quick question, is there a way to get this built with Noetic or should I stop before waste a few hours trying?

Looking at the various branches it seems like it's either Melodic with 9 or Humble with Garden. What's so incompatible about Fortress/11?

First of all, thanks for making these plugins -- they've been really helpful with my project so far!

I'm trying to simulate many floating objects at once, as in the image below:

#1: Do you have any tips for speeding up the simulation? When I publish a wave message the simulation speed drops to about 0.01 real-time. Are there any approximations/speedups that I can turn on in the plugins?

#2: This error shows up many times when I simulate a wave field on the large array of cylinders:

[Err] [Wavefield.cc:906] point:  -8.72634e+24 -5.07838e+24 1.38239e+23
[Err] [Wavefield.cc:908] Water patch is too small

Could you explain what this error means?

Thank you!

The main branch and new development are focussed on Gazebo Garden / ROS2 Humble and later versions, however there are periodically requests for versions that run on ROS Noetic / Ubuntu 20.04 (Focal). There are a number of branches under feature that will compile and run for Gazebo11 but contain the initial development code for FFT waves. These need to be better organised and documented and put into an archive / maintenance state.

The initial version targeting Gazebo9/ROS Melodic/Ubuntu 18.04 (Bionic) should have a counterpart for Gazebo11/ROS Noetic/Ubuntu 20.04 (Focal) that does not include the FFT development code and is interface compatible with the earlier version.

Some of the re-organisation has been partially addressed in #99, #101, #102 and #103.

Tasks

Gazebo9

• Add branch gazebo9 for Gazebo9/ROS Melodic/Ubuntu 18.04 (Bionic).
• Replace Travis CI with GitHub Actions using an ubuntu-18.04 runner.
• Update documentation in gazebo9 branch.
• Update documentation for legacy support in master branch.

Gazebo11

• Add branch gazebo11 for Gazebo11/ROS Noetic/Ubuntu 20.04 (Focal).
• Replace Travis CI with GitHub Actions using an ubuntu-20.04 runner.
• Update documentation in gazebo11 branch.
• Update documentation for legacy support in master branch.

Gazebo11 / FFT Waves

There are three branches under feature that contain the initial development for FFT waves. These have been ported to Gazebo11 at different stages (via a merge of fe74d47) and contain different feature sets. Usually code for release would not be rebased, however it will be much cleaner to organise these branches with a linear history rebased on the gazebo11 branch described in the section above (and feature branches are development). The proposal is to create rebased versions of the branches under feature renaming them, and eventually removing the original branches after a warning period.

Current structure of feature/ branches

• feature/gazebo11 and feature/fft_waves have a last common commit at 00b89df
• feature/gazebo11 and feature/ardupilot_sailboat_poc have a last common commit at 00b89df
• feature/fft_waves and feature/ardupilot_sailboat_poc have a last common commit at 67e1cda

Reorganised structure of feature/ branches

• From feature/gazebo11 create branch feature/fft-waves-v1 rebased on gazebo11.
• From feature/fft_waves create branch feature/fft-waves-v2 rebased on feature/fft-waves-v1.
• From feature/ardupilot_sailboat_poc create branch feature/fft-waves-v3 rebased on feature/fft-waves-v2.
• Ensure all branches have CI with GitHub Actions using an ubuntu-20.04 runner.
• Update documentation for each branch.
• Update documentation for legacy development / feature/ branch support in master.
• Update downstream projects https://github.com/srmainwaring/sail_sim_docker (depends on feature/fft_waves).

Related Issues

Previous issues requesting / discussing support for ROS Noetic.

• #12
• #13
• #14
• #68
• #98

This issue is to track improvements to the FFT wave generation model.

Issues with the current FFT wave model:

• There are missing scale factors when discretising the continuous Pierson-Moskowitz (PM) variance spectrum which means the simulated spectrum is not correct (and does not behave at all well as the resolution N is altered).
• The PM spectrum is omni-directional and the method used to implement travelling time-dependent waves is not very natural (and possibly is not Hermitian in the frequency domain leading to an imaginary component in the wave field).
• It is not possible to set the wave direction from the parameters (or rather it is, but it has no effect).

Proposed solution:

• Follow Curtis Mobley's detailed tutorial on generating sea surfaces from Ocean Optics taking care to include the correct scaling when transitioning from continuous one-sided spectra to discrete two-sided spectra
• Use the ECKV omni-directional spectra with the cos-2S spreading function to generate travelling time-dependent waves
• Allow the downwind direction to be specified as a parameter (using an angle from the positive x-axis (east in ENU coordinates))
• Add checks for various statistical properties of the waves and confirm the Fourier amplitudes are Hermitian.

Tracking implementation on this branch:

• https://github.com/srmainwaring/asv_wave_sim/tree/feature/fft-eckv-cos2s

Task list

• Add new FFT wave simulation class
• Integrate FFT class into OceanTile and enable in SDF models
• Add ECKV omni-directional spectrum
• Add ECKV and cosine-2S spreading functions
• Port prototype from Python to C++
• Check FFTW vs NumPy / SciPy FFT conventions
• FFT for wave height
• Enable parameters to control wind speed and direction
• FFT for wave height derivatives
• FFT for horizontal displacements
• FFT for horizontal displacements derivatives
• Update SDF parameter options
• First round of optimisation

I saw your posts on the ArduPilot sailboat thread, and have been trying out this project. It's definitely the best sailboat simulator I've found, so thank you for the work you put into it.

One issue I have been running into is when the boat capsizes due to too much wind, the simulator stops working and prints the following error thousands of times:

[Err] [WavefieldSampler.cc:207] Water patch is too small
[Err] [WavefieldSampler.cc:205] point:  1.03388e+253 -1.19529e+252 -5.06649e+252

I've been working on modeling my own boat, and it happens even more with it. If I add the rudder to the URDF, it happens immediately on startup.

In #8 you mentioned that you had a fix, but that doesn't seem to be published.

Interestingly, I switched to a debug build to try to look into the problem more, and the error changed:

terminate called after throwing an instance of 'CGAL::Precondition_exception'
  what():  CGAL ERROR: precondition violation!
Expr: ! K().collinear_3_object()(p,q,r)
File: /nix/store/4pd2d8rrzy6x4v08hzw713iq28wvkssw-cgal-5.1/include/CGAL/Kernel/function_objects.h
Line: 1780

Ubuntu 22
Ros2 Humble

The colcon build command that you specified returns the following error:

stderr.log

The project will not build on ubuntu18 / melodic / gazebo9:

New features in Gazebo 9.6 are used that prevent a build on a standard linux configuration.

Follow up to #85:

1. Resolve issues in the tests disabled in:

• CGAL_TEST
• EigenFFTW_TEST
• WaveSimulationFFT2_TEST
• WaveSimulation_TEST

2. Change the macOS Monterey CI workflow

• Only run on a PR (as it is very slow to install dependencies on the macOS runner)
• Consider removing the caching, and run a complete install each time (may be faster)
• Or - refine re-linking stage - only running the force relink on the packages that are reinstalled.
• Move build and test commands back into the main workflow yaml file from bash scripts

3. Add static checks

4. Add coverage checks

I'm curious to know if there are any methods for simulating breaking waves. Are there specific models or techniques that can be employed to simulate the behavior of fine-grained breaking waves?

New Feature

This issue is to track the migration of the wave simulation and hydrodynamics plugins to Ignition (Garden).

Desired behaviour

The wave visuals and physics behaviour are available in Ignition using the ogre2 render engine. There should be support for both Linux and macOS (the latter using Metal graphics API).

Implementation suggestion

The model and visual plugins from legacy Gazebo will be replaced with system plugins in Ignition. As before three plugins are required:

• wave visuals system
• wave physics system
• hydrodynamics physics system

wave visuals

The wave visuals are perhaps the most challenging change as they require migration to the Ogre2 render engine and integration into the ignition-rendering framework. As with legacy Gazebo, there is no direct support for modifying meshes at run time, with the exception perhaps of the DynamicRenderable objects for Ogre and Ogre2 which sit outside the main mesh frameworks from ignition-common and ignition-rendering.

The proposed approach is to first create visuals for a static wave field, which can be done staying within the available mesh and rendering framework and will use the vertex generation from the existing OceanTile. Static waves will allow the following to be migrated:

• wave generation methods
• materials and shaders
• parameter interfaces

wave physics

• Enable switching between the existing trochoid wave and development branch FFT wave algorithms

hydrodynamics physics

• No changes in functionality planned.
• Clarify use of different vector and mesh types (CGAL vs Ogre vs Ignition)

Other changes

The migration to Ignition requires such a significant change, it could be regarded as a complete reworking of the library. Other changes that may be included as sub-issues are:

• simplify the plugin / project names, reduce the number of projects
• move from the catkin build system to colcon (i.e. strip out ROS dependencies)
• factor out the core physics from the Ignition specific applications
• review the use of CGAL for the mesh physics
• look at performance improvements (specifically the ray intersection code which is the main bottleneck)
• improved range of wave spectra
• provide a standardised set of environment parameters with intermediate mappings to wave spectra and wave generator parameters

Progress

• #16
• #17
• #18
• #19
• #23
• #24
• #25
• #26
• #27

Description

In the README, there's this file of the environment setup:

# ensure gazebo finds the config for this installation
export GZ_CONFIG_PATH=\
$HOME/gz_ws/install/share/gz

By running this, I get the following error:

junwoo@JW-XPS:~/ROS2_ws/asv_wave_ws$ gz sim -v4 -s -r waves.sdf
I cannot find any available 'gz' command:
	* Did you install any Gazebo library?
	* Did you set the GZ_CONFIG_PATH environment variable?
	    E.g.: export GZ_CONFIG_PATH=$HOME/local/share/gz

Suggestion

And this prevents the gz command from being found, and the share/gz directory doesn't even exist after the colcon build, so I think this step is unnecessary.

What was the reasoning behind this step?

Notes

Possibly related to: #66

As mentioned here: https://github.com/gazebosim/gz-launch#known-issue-of-command-line-tools, the GZ_CONFIG_PATH should point to the location of the gz installation, which for my case it was obviously not in the wave sim's location 🤔

Hi @srmainwaring ,

first thank you a lot for this plugin, it helped significantly.

I am running your "develop" branch with Gazebo 11, and with a simple Wam-V simulation the real-time factor of Gazebo is 0.14 with only one CPU running 100%.

I have a quite decent computer (NVIDIA Quadro T2000, Corei9 with 8 cores, 32GB of RAM).

To reproduce I just clone your repository, checkout development branch, build then:

roslaunch asv_wave_sim_gazebo ocean_world.launch

Then from Gazebo insert the Wam-V model.

Is there something I am missing ?

Thank you !

PR #65 introduced the ability to enable hydrodynamics at link level using an <enable> element.

Currently the link must be fully scoped in the namespace of the enclosing model. This limits the reusability of models containing the hydrodynamics plugin as when they are including with a <name> element, the scoped name of the link changes and the hydrodynamics is not applied.

The proposed change is to not require the immediate enclosing model's name in the scoping rules.

Examples:

• model::float_link would be referred to as float_link
• model::nested_model::float_link would be referred to as nested_model::float_link

where we suppose that the plugin is defined in the scope of model.

Questions:

• Can the change be made so that is backwards compatible (or so the behaviour can be deprecated?)

Hi,
I managed to get the waves working and although I was struggling to get a boat model working I just set the collisions to a a box the same size as the lower boat and now its able to move with the waves. I am trying to test sensors such as LiDAR's in the simulation and they work fine and I can see the models that I place on the waves moving. But the waves themself are not showing as visible objects? is there a way to turn them into objects that sensors can see ?

The original version for Gazebo11 includes an executable that allows wave parameters to be updated dynamically without needed to reload the wave model. For Ignition Gazebo it is proposed to replace this with a GUI plugin that can be loaded into the sidebar and used to control the wave environment directly.

Prototype

Tasks

• Add standalone GUI plugin for waves controls
• Integrate the GUI plugin into the project build
• Migrate original Gazebo11 param_v messages to Ignition equivalents
• Publish wave params messages from Waves Control GUI plugin
• Subscribe to wave params messages in Waves visual system
• Subscribe to wave params messages in Waves model system

Checkboxes for markers are provided in the prototype - defer implementing these to a followup issue.

Code

https://github.com/srmainwaring/asv_wave_sim/tree/feature/gui-plugin

The "Set environment variables" section is missing the export for GZ_SIM_SYSTEM_PLUGIN_PATH in the example.

I have followed the instructions in your github readme.md

input command:

output:

expected output:
successful build

looked at these links:
CGAL/cgal#6647
microsoft/vcpkg#23098
did not understand what to do.

followup:
on trying to build again, I didnt get error this time, but build is not finished yet. it is at 40% after 40 mins.

how much time, it should take normally?

configuration:
gazebo garden
wsl2 ubuntu 22.04 jammy
i5 9th gen, 8gb ram, windows 10 (updated version)