Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unbounded velocity growth observed with hydrodynamics plugin #1923

Open
1 task done
laughlinbarker opened this issue Mar 9, 2023 · 14 comments
Open
1 task done

Unbounded velocity growth observed with hydrodynamics plugin #1923

laughlinbarker opened this issue Mar 9, 2023 · 14 comments
Assignees
Labels
bug Something isn't working

Comments

@laughlinbarker
Copy link

laughlinbarker commented Mar 9, 2023

Environment

  • OS Version: Ubuntu 22.04.2 LTS
  • Source or binary build: binary, version 7.4.0
    • Rendering plugin: ogre2
      • running in Docker/Singularity
    • Rendering system info:
ubuntu@coyote:/opt/mr/nadir$ lspci -nn | grep VGA
2d:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1)
ubuntu@coyote:/opt/mr/nadir$  echo "$DISPLAY"
:1
ubuntu@coyote:/opt/mr/nadir$ glxinfo -B | grep -i '\(direct rendering\|opengl\|profile\)' 
direct rendering: Yes
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 510.108.03
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 4.6.0 NVIDIA 510.108.03
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 510.108.03
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
ubuntu@coyote:/opt/mr/nadir$ ps aux | grep Xorg
ubuntu    180400  0.0  0.0   4020  2052 pts/1    S+   13:21   0:00 grep --color=auto Xorg

There appears to be a bug, which I believe to be related to the hydrodynamics plugin, which results in a model world velocity run-away. I've experienced this with my personal model, and it is reproducible in the AUV example provided by [auv_controls.sdf](https://github.com/gazebosim/gz-sim/blob/gz-sim7/examples/worlds/auv_controls.sdf#L139)

Description

  • Expected behavior: Vehicle velocity should decrease upon commanding zero prop speed
  • Actual behavior: Vehicle velocity grows unbounded until sim crash

In my own simulation, the problem is not exhibited when the added mass terms are 0, or significantly smaller than the vehicle mass. I have adjusted the sign of the added mass terms in my own model (non-example LRAUV system) and this does not change the outcome.

I haven't had time yet to check the implementation of Fossen's Eqns in HydrodynamicsPlugins.cc.

I believe M_A (added mass matrix) should be positive definite, symmetric. Yet the terms that exist in [auv_controls.sdf](https://github.com/gazebosim/gz-sim/blob/206def391d6ba23259ce8596e7256c2d705a9e53/examples/worlds/auv_controls.sdf#L144) result in a decidedly negative definite matrix.

Steps to reproduce

  1. Launch the auv sim: gz sim auv_controls.sdf -v 4
  2. Run the prop momentarily: gz topic -t /model/tethys/joint/propeller_joint/cmd_thrust -m gz.msgs.Double -p 'data: -31'
  3. Stop the prop: gz topic -t /model/tethys/joint/propeller_joint/cmd_thrust -m gz.msgs.Double -p 'data: -0'

Output

You can see a video of the problem manifesting here: https://youtube.com/shorts/zExnMM8K-L8
Notice the world velocity of the AUV growing unbounded even once the prop has been commanded to stop.

ogre2.log

@laughlinbarker laughlinbarker added the bug Something isn't working label Mar 9, 2023
@laughlinbarker
Copy link
Author

laughlinbarker commented Mar 9, 2023

Of note: when commanding the prop in reverse (gz topic -t /model/tethys/joint/propeller_joint/cmd_thrust -m gz.msgs.Double -p 'data: 31'), the vehicle backs up as expected. Upon stopping the prop, the vehicle decelerates (towards zero velocity), but the sim still crashes after a few seconds.

@azeey
Copy link
Contributor

azeey commented Mar 10, 2023

There was a behavior change introduced recently which has been documented in #1888. Can you see if that helps?

@laughlinbarker
Copy link
Author

Thanks @azeey. Appropriate naming of those parameters appears (in my test run of N=1) to prevent the runaway condition.

Parameters used:

<plugin
        filename="gz-sim-hydrodynamics-system"
        name="gz::sim::systems::Hydrodynamics">
        <link_name>base_link</link_name>
        <xDotU>-4.876161</xDotU>
        <yDotV>-126.324739</yDotV>
        <zDotW>-126.324739</zDotW>
        <kDotP>0</kDotP>
        <mDotQ>-33.46</mDotQ>
        <nDotR>-33.46</nDotR>

        <xUabsU>-6.2282</xUabsU>
        <yVabsV>-601.27</yVabsV>
        <zWabsW>-601.27</zWabsW>
        <kPabsP>-0.1916</kPabsP>
        <mQabsQ>-632.69</mQabsQ>
        <nRabsR>-632.69</nRabsR>

        <xU>0</xU>
        <yV>0</yV>
        <zW>0</zW>
        <kP>0</kP>
        <mQ>0</mQ>
        <nR>0</nR>
      </plugin>

The mis-naming of the second-order (and in the case of the demo, the only non-zero) damping terms, appears to be at the heart of the issue.

Seems like appropriate course of action is:

  • (Minimum) Submit PR to rename Hydro params appropriately in auv_controls.sdf
  • (Better) Above + address this potential for instability at the plugin level. This could be by providing warnings for uninitialized first/second order drag terms, or even by providing a default (but small?) drag term so as to remain stable.
  • (Best) Above + Add some checks in the appropriate unit tests to catch something of this nature?

@laughlinbarker
Copy link
Author

Submitted minimal PR as described above, don't have time at the moment to investigate other options I enumerated.

@azeey
Copy link
Contributor

azeey commented Mar 11, 2023

/cc @arjo129

@arjo129
Copy link
Contributor

arjo129 commented Mar 13, 2023

This was fixed in #1888. The said fix has not yet been forward ported to Garden. I like the idea of checking the values and warning users in the event values lead to unbounded velocity growth.

@mateusmenezes95
Copy link

mateusmenezes95 commented Aug 2, 2023

We have experienced the same problem in our project simulation, even using the correct naming for the coefficients of the Damping matrix. After deep investigation, I discovered that numerical computation instability can exist if the condition $M_A \prec M_{RB}$ is unsatisfied, where $M_A$ is the Added Mass matrix, $M_{RB}$ is the system inertia matrix, and $\prec$ is the element wise less than comparison. The authors of the uuv_simulator already reported this error in section II.D of their paper UUV Simulator: A Gazebo-based package for underwater intervention and multi-robot simulation. Based on the uuv_simulation, @joaobrittoneto have also reported this instability in his master thesis Parameters Identification of Dynamic Model and Simulation of Autonomous Underwater Vehicles, section 4.2.

I tested this criterion using an adapted world file used in the hydrodynamics plugins unit tests in the ign gazebo 6.14.0.
To reproduce the error, first, simulate with the hydrodynamics.sdf containing the SDF snippet below using the command ign gazebo hydrodynamics.sdf. This first run shall execute without problems. Now, change the value of zDotU (line 108) to -26.0 kg and rerun the simulation. Using this mass value forces the criterion to be unsatisfied because the sphere's mass is 24 kg, and the left superior block of the Added Mass matrix $M_{A_{11}} \in R^{3 \times 3}$ equals $mI_{3 \times 3}$; thus -zDotU > m and $M_A \prec M_{RB}$ is unsatisfied.
In my execution, the simulation crashed after some seconds. Even with zDotU -25.0 kg, my simulation crashed.

Thus, if someone could reproduce the crash and this criterion must be satisfied, as the criterion is a simple element-wise comparison, my first suggestion is to put a warning or even a fatal error informing the user about the problem.

hydrodynamics.sdf (change the extension to .sdf): hydrodynamics.txt

@arjo129
Copy link
Contributor

arjo129 commented Aug 2, 2023

Hi @mateusmenezes95 yes that is correct, as added mass is expressed in terms of an added unit instead of a percentage in the fossen equations instablilities could arise when Ma < Mrb. I could add a check to the hydrodynamics plugin. This a is a great suggestion.

@mateusmenezes95
Copy link

Very nice @arjo129. Thanks for the fast reply 😄! Another suggestion may be to use the compensation method (named Method 1) suggested by @joaobrittoneto in his thesis that guarantees stability even when the criterion is unsatisfied. However, as reported in the results, this method may degrade the simulation result when there are body rotations. An option is to turn this compensation on/off by a parameter.

@arjo129
Copy link
Contributor

arjo129 commented Aug 2, 2023

I don't have time to add the compensation method but PRs are welcome!

@mateusmenezes95
Copy link

Sure! I will try to submit a pull request with the suggestions.

@mateusmenezes95
Copy link

I think that #1592 solves this issue for Gazebo Harmonic. What do you think @azeey?

@joaobrittoneto
Copy link

I think that #1592 solves this issue for Gazebo Harmonic. What do you think @azeey?

I agree with @mateusmenezes95. The fluid_added_mass present in the inertial (which leverages DART's ability to handle 6x6 spatial inertia tensors) should be favored. It leads to a simpler and more robust solution. The only downturn is the reliance on DART itself (it's not supported by other physics engines).

The added mass effect of the hydrodynamics plugin, IMHO, could be deprecated.
The current implementation, as known, is brittle. Doing a[k] = -Mrb^-1 * Ma * a[k-1] leads to instability when Ma > Mrb.
Trying to use the compensated terms, as mentioned in the references here, leads to a convoluted solution, vide a custom gazebo_underwater plugin I helped to create where those terms are used.

@arjo129
Copy link
Contributor

arjo129 commented Jul 24, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: In progress
Development

No branches or pull requests

5 participants