I want to use IMU sensor data to estimate the velocity of the ROV. However, the IMU sensor on rexrov model doesn't produce accurate linear acceleration data, but not the case for angular velocity (all 0 when stationary). For example, the linear acceleration in X and Y direction fluctuates slightly at about -0.85 and 0.3 respectively, while linear acceleration in Z direction is about 9.75, which makes sense more than in X and Y direction, when ROV remains still. What's the cause of such bias?

Looking for feedback for a few things I noticed about the installation tutorial while testing on Noetic.

I can update the tutorials once I get a green light. Just wanted to double-check these things aren’t already somewhere that I didn’t know about, since I’m still kind of new to the repo.

• #124

• #125

• #126

• #127

I'm not done testing yet. There might be more, but I wanted to start the ticket in the interest of release timeline.

In order to run the demo, the path to the .csv file specified in the launch file (uuv_dave/uuv_dave_transientcurrent_demo.launch) must be manually edited to a valid path on the local machine. This needs to be changed to a relative path that the ROS or Gazebo "find" functionality can locate.

From PR#42

Collision = visual. No individual collision models with reduced textures was produced. ∴ , which may result in more collision computations than needed.

The visual mesh is fairly simplified, so this may not be an issue in terms of computational load. Should evaluate before generating new collision mesh.

• It would be useful to have a baseline docker image that supports development for both vrx and dave. Right now these use different images.
• We may want to set up a separate repository for this image.
• A github action that builds and pushes this image to Dockerhub would be convenient.
• We may also want to ship our dave and vrx releases as part of prebuilt images, or make these available for use with cloudsim.
• This might warrant moving Dockerfiles out of the individual repos, depending on what kind of use cases or workflows are envisioned.
• To decide the above we also need to sketch out the workflows we are intending to support.

Problem

If no controller is connected, or it is not at /dev/input/js0 the following error appears at launch:

[ERROR] [1598203806.880535332]: Couldn't open joystick /dev/input/js0. Will retry every second.

This turns out to be fatal. Later we see:

[INFO] [1598203808.546280, 0.000000]: Controller Spawner: Waiting for service controller_manager/switch_controller
[INFO] [1598203808.547676, 0.000000]: Controller Spawner: Waiting for service controller_manager/unload_controller
[INFO] [1598203808.548790, 0.000000]: Loading controller: /rexrov/oberon7/finger_left_joint/controller
[ERROR] [1598203808.590425, 0.004000]: Spawn service failed. Exiting.

Solution

Ideally we should check for a controller at each available /dev/input/js# and if none are found fall back to keyboard teleop control.

Rocker’s most recent release, 0.2.3, is from Nov 2020. If we install via apt like the DAVE Noetic wiki says, the newer features like --volume aren’t available. I had problems using it because it only mounts /home, but none of my code is in my home directory (all my stuff is in a separate partition which I usually mount with docker run --volume). We might want to either ask Tully to make a new release, or put a note in the DAVE wiki saying if they want new features, then they need to install Rocker following the venv instructions on the Rocker page (that gets the latest version, and it worked for me).

The Noetic docker tutorial doesn’t have instructions on how to build, while the Melodic page and the host installation page do. Since they’re all linked from the installation page, I propose to move the “Install Dave and dependencies from source” section from the Melodic page to the Installation page. All 4 ways of installation need to use these compiler commands.

The dave/sonar_dave_plugins directory contains a copy of the uuv image_sonar_ros_plugin Sonar model. It was to contain a custom Sonar model. Now sonar models are managed elsewhere. This Sonar model copy provides libimage_sonar_dave_plugin.so. The only entry to this plugin is sonar_dave_uuv/urdf/sonar_snippets.xacro and its only entry is dave/uuv_dave/urdf/sensor_snippets.xacro. Its significant use is to provide Sonar for the primary example:

roslaunch uuv_dave uuv_dave.launch

The fix must include redirection to UUV's libimage_sonar_ros_plugin.so and to .xacro files so that this example still works. We may wish to perform this fix when a new Sonar model becomes available.

Bathymetry tiles are products of converting large tiff data into tiles using Bathymetry_Converter. The converter is kept in separate repo since it takes a long time and not easy to install (tutorial). In the tutorial, the original tiff (ncei19_n41x75_w070x75_2018v1.tif) is downloaded from my personal dropbox link using wget function. (wget -O bathymetry_source.tar.bz2 https://www.dropbox.com/s/x3acdnnpw3ej9b4/bathymetry_source.tar.bz2?dl=1).

Currently, the minimal tiles to run the plugin correctly are included in the dave repo. However, we don't want any static example data to be included in the repo. The products of such should not be stored within the git repos. Instead, it should be kept in some persistent storage and providing instructions on how (e.g., use a curl/wget script to download from gdrive/Box/dropbox).

So what we propose is,

1. Remove everything out of the repo (Proposed)
   • Remove Launch file (bathy_dave.launch), world file (dave_bathy.world), and xacro file (dave\uuv_dave\urdf\rexrov_oberon7_with_bathy.xacro), and all tile models from dave repo
   • Make those removed files downloadable (with minimal tiles to launch tutorial case) by wget (hosted on Google Drive)
   • Rest of the tiles are not provided. They are DIY following the Bathymetry Converter and its tutorial
2. Leave minimal examples in the repo (Current setting)
   • Leave Launch file (bathy_dave.launch), world file (dave_bathy.world), xacro file (dave\uuv_dave\urdf\rexrov_oberon7_with_bathy.xacro), and minimal tiles in dave repo
   • Rest of the tiles are not provided. They are DIY following the Bathymetry Converter and its tutorial

@bsb808 Is the proposed method what you meant?

After merging PR#50, move the custom ROS messages to the frl_msgs repository.

Hi, thanks for the really great project!

From the roadmap,

Release 3.0: Addition of new model based on HDT Adroit.

Is it available now?

For consideration - move the USBL sensor plugin (see source and wiki) from the dave repo to the uw_sensors repo.

@dtdavi1 is working on a new outline, so this change is pending the new layout.

Visual model is here.
https://drive.google.com/drive/folders/1UzQr_FlO7210fE2Vl9TFe1Qe8C8M5urK?usp=sharing

Rename to "caldus".

Here is a how-to https://github.com/Field-Robotics-Lab/dave/wiki/New-Underwater-Vehicle

Note that the mesh and texture files are here https://github.com/Field-Robotics-Lab/dave/tree/master/uuv_dave/models/erov
Should move them within the repo to be consistent with the tutorial above.

The single ocean current value published by the transient current plugin (uuv_dave/UnderwaterCurrentROSPlugin.cc) is dependent on a separate model plugin to select the depth for which the depth is published. Since the plugin has been updated to publish an array of currents for all of the depths, the single value no longer needs to be depth-specific. Reversing this change will maintain reverse compatibility with models that assume a single homogeneous ocean current value.

Currently the underwater lidar plugin expects a uwl namespace, which is hard coded. It should detect and use the actual name space passed in to the macro.

Request in to modeler to clean up a few things with the smilodon model - remove proprietary labels and the gold cylinder on the port side which hides the lateral thruster.

Using a Vector3 array instead of three float32 arrays is more in keeping with the de facto standards of the rest of the codebase. The single velocity value generated by the same plugin is already published as a single Vector3 value.

From PR#42

No texture: The individual links were not centralized. After I centralized them in Blender, the tag in the dae file responsible for texture disappears.

The current plugin requires a plugin to be loaded at the model description UDRF to switch on stratified ocean currents. It's because the stratified ocean current calculation requires a vehicle depth. A better way for further developments would be 'define all stratified parameters at the world file'. This can be brought up using gazebo's generic function called /gazebo/get_model_state.

Testing PR #16 raises some questions about the validity of the torque sensor plugin outputs and their use for force feedback. See the video: https://vimeo.com/422977387 There seem to be some simulation artifacts.

Can we test a subset of joints by adding external forces to gain confidence that they are providing trustworthy results?

A suggested step is to simplify the example from the PR to a standalone manipulator on a fixed pedestal with no ocean world (just empty gazebo world). This would simplify the testing and allow us to do some sniff tests of the outputs.

Context

• The dockwater repository contains docker images intended to support CI testing, local development, and cloudsim environments for our various water-related simulation repositories.
• The Dockerfiles for these images give a clear description of the dependencies needed to build our environments.

Problem

• Our host installation tutorials give instructions for installing needed dependencies directly on the host, but these are sometimes inconsistent, or sometimes take different approaches such that it is unclear whether they are equivalent.
• These are difficult to test without reinstalling the operating system.

Solution

We should get the docker images working, then synchronize the host installation instructions to the docker images.

Doing coordinated, whole-body, mobile manipulation is challenging. For many examples it is best to start with a simpler example where the vehicle is static - approximating a scenario where the vehicle is on the bottom or held stationary by a perfect feedlback control system.

Develop a convenient interface and example such that the vehicle can be set to static when spawned in the world to facilitate testing the manipulation independent of the vehicle motion control. Ideally this would be a command line argument when launching the scenario.

Although the Predator Arm works fine in Gazebo 9, not so in Gazebo 11. See the image below and note that the wrist is floating above the arm and the hand is lying on the floor in the back of the UUV:

Initial scan of the error messages suggests that this may be due to a name collision that Gazebo 9 forgives but Gazebo 11 gets mad about:

Warning [Model.cc:212] Non-unique names detected in XML children of model with name[rexrov].
Error [Model.cc:311] Joint with name [predator/wrist] in model with name [rexrov] has a name collision. Please rename this joint.
[Err] [Model.cc:123] Error Code 25 Msg: relative_to name[predator/wrist] is identical to joint name[predator/wrist], causing a graph cycle in model with name[rexrov].
[Err] [Model.cc:123] Error Code 26 Msg: PoseRelativeToGraph error, too many incoming edges at a vertex with name [predator/wrist].

The Docker scripts we have now were quickly ported over from our previous VRX environment. They offer command line options that allow the user to specify:

1. whether the base image is Nvidia-enabled or not;
2. whether the base image runs Ubuntu 18 with ROS melodic and Gazebo 9 or Ubuntu 16 with ROS kinetic and Gazebo 7

The combination of these choices allow the user to build 4 different varieties of images.

Problem:

• Of these options, the only one that we are actively testing Ubuntu 18.04/Melodic/Gazebo9 with an Nvidia GPU.

Fix:

• I propose to drop support for everything except the configuration we're actually using.

I recently had to clear out cached Docker images to make space for the massive Mathworks build process (which didn't work). Now, attempting to rebuild our Dave Docker image with:

./build.bash .

I get to step 5 in the build process and then it crashes:

W: GPG error: https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64  Release: The following signatures were invalid: BADSIG F60F4B3D7FA2AF80 cudatools <[email protected]>
E: The repository 'https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64  Release' is not signed.

This is a known issue: NVIDIA/nvidia-docker#1369 but it is closed because nvidia-docker doesn't want to own it. They want it submitted to their developer forum. It has been: https://forums.developer.nvidia.com/t/cuda-10-1-install-gpg-error-the-following-signatures-were-invalid-badsig-f60f4b3d7fa2af80/79944

It looks like there are workarounds, but maybe the best fix is to move to using Rocker from a standard 18.04 base image.

Goal is to have station-keeping functionality demonstrated (examples and tutorial/demo instructions).

Typically for ROVs the motion control is decomposed into independent DOFs:

• Auto-heading (yaw control)
• Auto-depth
• Auto-altitude
• Auto-xy (station keeping)

Each of these DOFs can be enabled/disabled independently. For our work this would be actuated via joystick or keyboard teleop.

Previous work

• UUV Simulator - DP Tutorial . Dynamic Positioning is synonymous with station-keeping. I have not dug into this process, but at first glance it appears to be overly complicated.

• Video examples from a previous project using UUV Simulator to develop PID controllers:

  • Auto-heading: https://vimeo.com/313474378
  • Auto-xy, joystick: https://vimeo.com/313474439
  • Auto-xy, button: https://vimeo.com/313474494

Approach

• Teleoperator engages each feedback control for each DOF independently
• If disengaged (open-loop), the teleoperation commands provide a thrust command to the vehicle. this passes through the thrust manager so that the thruster allocation matrix allows the linear/angular thrust command to be decomposed into commands for the individual thrusters.
• If engaged (closed-loop)
  • If the command is zero (within deadband of joystick) either
    • The velocity setup is zero (this is a bit easier) OR
    • The vehicle goes into position control mode
  • If the command is non-zero, the teleoperation command maps to a velocity setupoint.

Where to start

Start with auto-heading and/or auto-depth. Doing a single degree of freedom at a time is quite a bit easier. Auto-xy can be a little tricky.

Context

We use the gpu_ray sensor to approximate our under water lidar sensor, which is based on the specs for the 3d at Depth SL3. By default, the sensor field of view is 30 degrees x 30 degrees and contains 1450 x 1450 points. We produce this by setting the following values for both the <horizontal> and <vertical> elements of the <scan> element:

<samples>1450</samples>
<resolution>0.1</resolution>
<min_angle>-${pi/12}</min_angle>
<max_angle>${pi/12}</max_angle>

Problem

On some systems, this produces the desired effect:

On other systems, however, this same configuration produces very strange laser effects:

Notes

We don't currently know what differences between systems could be causing this effect. Of particular note is that in at least one case the plugin works correctly inside a Docker install, but fails on a host-based install on the same machine.

Problem

Our run.bash script attempts to detect whether /tmp/.docker.xauth exists and to create it if it doesn't. However, on some systems with multiple displays /tmp/.docker.xauth may be a directory containing files for each display. In this case our conditional check incorrectly concludes that the file is not there, tries to create it, and fails. This is because we use:

XAUTH=/tmp/.docker.xauth
if [ ! -f $XAUTH ]

which will be true if /tmp/.docker.xauth doesn't exist or if it does exist but is a directory.

Solution

Make our conditional smarter so it can detect directories too.

repositories:
src/dave:
type: git
url: https://github.com/field-robotics-lab/dave
version: master
src/ds_msgs:
type: git
url: https://bitbucket.org/whoidsl/ds_msgs.git
version: master
src/ds_sim:
type: git
url: https://bitbucket.org/whoidsl/ds_sim.git
version: master
src/eca_a9:
type: git
url: https://github.com/uuvsimulator/eca_a9.git
version: master
src/gtri_based_sonar:
type: git
url: https://github.com/Field-Robotics-Lab/gtri_based_sonar.git
version: master
src/hydrographic_msgs:
type: git
url: https://github.com/apl-ocean-engineering/hydrographic_msgs.git
version: main
src/nps_uw_multibeam_sonar:
type: git
url: https://github.com/field-robotics-lab/nps_uw_multibeam_sonar
version: main
src/nps_uw_sensors_gazebo:
type: git
url: https://github.com/Field-Robotics-Lab/nps_uw_sensors_gazebo.git
version: master
src/rexrov2:
type: git
url: https://github.com/uuvsimulator/rexrov2.git
version: master
src/uuv_manipulators:
type: git
url: https://github.com/field-robotics-lab/uuv_manipulators
version: master
src/uuv_simulator:
type: git
url: https://github.com/field-robotics-lab/uuv_simulator
version: master

• roslaunch uuv_dave uuv_dave.launch
• rostopic echo /rexrov/gps

header: 
  seq: 641
  stamp: 
    secs: 21
    nsecs: 830000000
  frame_id: "rexrov/gps_link"
status: 
  status: 0
  service: 1
latitude: -56.7189407714
longitude: -3.51555967066
altitude: -93.0446776133
position_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
position_covariance_type: 3
---

• The signs on both latitude and longitude are flipped from what is defined in the world file: https://github.com/Field-Robotics-Lab/dave/blob/master/uuv_dave/worlds/uuv_dave_ocean_waves.world#L38
• They also seem wrong given the comment in the world file
  • -56.7189407714, -3.51555967066
  • 56.7189407714, 3.51555967066

This seems to be caused by this PR in the uuv_simulator repo: uuvsimulator/uuv_simulator#250
In that PR, the maintainer stated that the long term fix was to replace the sensor plugin completely with one that does the necessary computation independent of Gazebo.

USBL Dev - first PR

#50

B/c the PR is in github and Peng can't make changes to github I am doing the following...

1. Where possible, will try to make changes directly to the code in the PR. Then Peng will review the PR (test it) and approve. Once approved I will merge on github.

2. Below are my comments on the PR that should be addressed post-merge. They will be addressed on the gitlab side so that the tools can support interactive review.

#include <opencv2/imgproc/imgproc_c.h>

The addition in
sonar_dave_plugins/sonar_dave_uuv/src/gazebo_ros_image_sonar.cpp

This is an unrelated change. I have removed it from the PR.

If it is still an issue with github/master, it should be a separate PR.

File extensions

Believe we decided on .cc and .hh

Move package to nps_us_sensors_gazebo

Message definition comments

Please add documentation in the .msg files to clarify the interface. For example see the ROS sensor_msgs, e.g., https://github.com/ros/common_msgs/blob/noetic-devel/sensor_msgs/msg/NavSatFix.msg

Verification

If you have verified all this, no need to reply, but wanted to make sure we have verified the various functionalities, e.g,

• Have we verified the two different interrogation modes.
• Have you verified that the sphericial and cartesian outputs behave as expected? I looked at the math briefly, but would need to run tests in various quadrants and orientations to make sure all the details are correct.

Ping Scheduler

This appears to be a constant update rate - true?

If so, would recommend a different idiom for used. Look at the way other gazebo plugins implement an update rate within the ModelPlugin::Update() method. The use of a separate timer object and thread seems to overly complicate the implementation.

Set sound speed directly

I believe it would be simpler to set the speed of sound directly - rather than indirectly through the temperature.

Also, speed of sound should probably be an SDF parameter of the plugins rather than set via ROS messaging.

Documentation

For users we should explain a bit more about how this plugin works - what is the theory of operation? One thing that would help would be to sketch the communications - maybe use the rosgraph as a start and explain the ROS communication.

Dear All,

I am facing some issues during the compile of this project.
I am considering the branch tidal_current_fix_before_reorg based on the indications of the repository Glider Hybrid Whoi.
During the execution of the catkin_make command, I have the following error:

[ 97%] Building CXX object dave/usbl_gazebo/CMakeFiles/transceiverPlugin.dir/src/transceiverPlugin.cpp.o
In file included from /home/tommaso.fabbri/Git/aasw/passiveWorkspace/gitAsw_pSimulation/uuv_ws/src/dave/usbl_gazebo/src/transceiverPlugin.cpp:19:0:
/home/tommaso.fabbri/Git/aasw/passiveWorkspace/gitAsw_pSimulation/uuv_ws/src/dave/usbl_gazebo/include/transceiverPlugin.hpp:16:10: fatal error: ignition/common/StringUtils.hh: No such file or directory
 #include <ignition/common/StringUtils.hh>
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
dave/usbl_gazebo/CMakeFiles/transceiverPlugin.dir/build.make:62: recipe for target 'dave/usbl_gazebo/CMakeFiles/transceiverPlugin.dir/src/transceiverPlugin.cpp.o' failed
make[2]: *** [dave/usbl_gazebo/CMakeFiles/transceiverPlugin.dir/src/transceiverPlugin.cpp.o] Error 1
CMakeFiles/Makefile2:11022: recipe for target 'dave/usbl_gazebo/CMakeFiles/transceiverPlugin.dir/all' failed
make[1]: *** [dave/usbl_gazebo/CMakeFiles/transceiverPlugin.dir/all] Error 2

The libignition-common-dev is installed on my system through apt, and the mentioned file is at /usr/include/ignition/common1/ignition/common/StringUtils.hh.
My system is Ubuntu 18.04 with ROS Melodic. Any suggestions?

Thank you

The Docker image installation instructions have fallen out of date. The following need to be addressed:

• As of Docker 19.03 the docker-nvidia2 package is not needed.
• rosdep is no longer included by default
• The Dockerfile is out of sync with host-based installation instructions, which is causing runtime errors.
• The ./run.bash script should support mounting a host-based repositories so the image can be used for development and will stay in sync with the repository.

On WSL Ubuntu 20.04 (supposedly equivalent to direct install on the host process), sudo apt-get install -y libignition-math2 fails because libignition-math2 is only at package manager up to Ubuntu 18.04. Somewhere following along with the installation wiki, libignition-math6 is installed.

catkin_make fails on Ubuntu 20.04 with ROS Noetic Gazebo 11 and I suspect the above problem is causing it. Are we suppose to git clone some other specific branch or version of uuv_simulator?

some of catkin_make fail error logs,

In file included from /usr/include/ignition/math6/ignition/math/Spline.hh:22,
                 from /usr/include/gazebo-11/gazebo/common/Animation.hh:22,
                 from /usr/include/gazebo-11/gazebo/common/common.hh:5,
                 from /usr/include/gazebo-11/gazebo/gazebo_core.hh:19,
                 from /usr/include/gazebo-11/gazebo/gazebo.hh:20,
                 from /home/woensug/uuv_ws/src/uuv_simulator/uuv_gazebo_plugins/uuv_gazebo_plugins/src/Dynamics.cc:16:
/usr/include/ignition/math6/ignition/math/Helpers.hh:40:13: warning: variable templates only available with ‘-std=c++1
’ or ‘-std=gnu++14’
   40 | constexpr T IGN_MASSMATRIX3_DEFAULT_TOLERANCE = T(10);
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[  5%] Generating C++ code from ds_acomms_msgs/Point_F32.msg
/usr/include/ignition/math6/ignition/math/Helpers.hh: In function ‘std::chrono::_V2::steady_clock::duration ignition::math::v6::stringToDuration(const string&)’:
/usr/include/ignition/math6/ignition/math/Helpers.hh:990:28: error: ‘chrono_literals’ is not a namespace-name
  990 |       using namespace std::chrono_literals;
      |                            ^~~~~~~~~~~~~~~
/usr/include/ignition/math6/ignition/math/Helpers.hh: In function ‘std::chrono::_V2::steady_clock::time_point ignition::math::v6::stringToTimePoint(const string&)’:
/usr/include/ignition/math6/ignition/math/Helpers.hh:1032:28: error: ‘chrono_literals’ is not a namespace-name
 1032 |       using namespace std::chrono_literals;
      |                            ^~~~~~~~~~~~~~~
/usr/include/ignition/math6/ignition/math/Helpers.hh:1033:56: error: unable to find numeric literal operator ‘operator""s’
 1033 |       std::chrono::steady_clock::time_point timePoint{-1s};
      |                                                        ^~
/usr/include/ignition/math6/ignition/math/Helpers.hh:1033:56: note: use ‘-fext-numeric-literals’ to enable more built-in suffixes
/usr/include/ignition/math6/ignition/math/Helpers.hh:1033:58: error: no matching function for call to ‘std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long int, std::ratio<1, 1000000000> > >::time_point(<brace-enclosed initializer list>)’
 1033 |       std::chrono::steady_clock::time_point timePoint{-1s};

In file included from /usr/include/ignition/math6/ignition/math.hh:30,
                 from /usr/include/sdformat-9.5/sdf/Param.hh:33,
                 from /usr/include/sdformat-9.5/sdf/Element.hh:28,
                 from /usr/include/sdformat-9.5/sdf/Actor.hh:25,
                 from /usr/include/sdformat-9.5/sdf/sdf.hh:2,
                 from /usr/include/gazebo-11/gazebo/common/Battery.hh:25,
                 from /usr/include/gazebo-11/gazebo/common/common.hh:8,
                 from /usr/include/gazebo-11/gazebo/gazebo_core.hh:19,
                 from /usr/include/gazebo-11/gazebo/gazebo.hh:20,
                 from /home/woensug/uuv_ws/src/uuv_simulator/uuv_gazebo_plugins/uuv_gazebo_plugins/src/Dynamics.cc:16:
/usr/include/ignition/math6/ignition/math/Capsule.hh: At global scope:
/usr/include/ignition/math6/ignition/math/Capsule.hh:91:20: error: ‘optional’ in namespace ‘std’ does not name a template type
   91 |       public: std::optional< MassMatrix3<Precision> > MassMatrix() const;
      |                    ^~~~~~~~
/usr/include/ignition/math6/ignition/math/Capsule.hh:91:15: note: ‘std::optional’ is only available from C++17 onwards
   91 |       public: std::optional< MassMatrix3<Precision> > MassMatrix() const;

In file included from /usr/include/ignition/math6/ignition/math/Spline.hh:22,
                 from /usr/include/gazebo-11/gazebo/common/Animation.hh:22,
                 from /usr/include/gazebo-11/gazebo/common/common.hh:5,
                 from /usr/include/gazebo-11/gazebo/gazebo_core.hh:19,
                 from /usr/include/gazebo-11/gazebo/gazebo.hh:20,
                 from /home/woensug/uuv_ws/src/uuv_simulator/uuv_gazebo_plugins/uuv_gazebo_plugins/src/Dynamics.cc:16:
/usr/include/ignition/math6/ignition/math/Helpers.hh: In instantiation of ‘std::tuple<_Tps ...> ignition::math::v6::breakDownDurations(DurationIn) [with Durations = {std::chrono::duration<long unsigned int, std::ratio<86400, 1> >, std::chrono::duration<long int, std::ratio<3600, 1> >, std::chrono::duration<long int, std::ratio<60, 1> >, std::chrono::duration<long int, std::ratio<1, 1> >, std::chrono::duration<long int, std::ratio<1, 1000> >}; DurationIn = std::chrono::duration<long int, std::ratio<1, 1000000000> >]’:
/usr/include/ignition/math6/ignition/math/Helpers.hh:829:57:   required from here
/usr/include/ignition/math6/ignition/math/Helpers.hh:810:29: error: no matching function for call to ‘get<std::chrono::duration<long unsigned int, std::ratio<86400, 1> > >(std::tuple<std::chrono::duration<long unsigned int, std::ratio<86400, 1> >, std::chrono::duration<long int, std::ratio<3600, 1> >, std::chrono::duration<long int, std::ratio<60, 1> >, std::chrono::duration<long int, std::ratio<1, 1> >, std::chrono::duration<long int, std::ratio<1, 1000> > >&)’
  810 |         (std::get<Durations>(retval) =
      |          ~~~~~~~~~~~~~~~~~~~^~~~~~~~

A quick check of the inertia values for the predator arm suggests something is amiss:

The center of gravity seems to be wrong for a few of the joints and the inertia generally looks a bit weird. Inertial blocks are calculated using a macro that may not be correctly accounting for the shapes of the objects.

This issue is resolved with PR #110. I'm writing it up to document it because it is a significant change to the way the join.bash script works (and not consistent with other versions of this script yet).

Problem

join.bash takes the image name as an argument instead of the container name.

• This has been good enough until now, but is not great logically because one can run multiple containers from the same image.
• Now that we are using rocker the image doesn't have a name and is assigned a hash for an ID, so the user has to look this up, which requires knowing where to find it in the rocker output or knowing which container it is associated with.

Solution

It is easier just to switch to using the container name. Rocker supports specifying the container name through the --name argument, so we can control this, which makes writing the documentation easier.

Current behavior:

When run locally, cpplint.py recommends using the full path of the file from the root of the repository to name the guard. So, for example, code_check.sh will include an error like this:

./include/nps_uw_sensors_gazebo/nps_gazebo_ros_gpu_sonar_single_beam.h:19:  
#ifndef header guard has wrong style, please use: 
INCLUDE_NPS_UW_SENSORS_GAZEBO_NPS_GAZEBO_ROS_GPU_SONAR_SINGLE_BEAM_H_

This error can be eliminated by changing the header guard as requested (although this is not ideal). However, when the same check is performed in the github action environment, the file path and corresponding variable name is very strange:

./include/nps_uw_sensors_gazebo/nps_gazebo_ros_gpu_sonar_single_beam.h:19:
 #ifndef header guard has wrong style, please use: 
___W_NPS_UW_SENSORS_GAZEBO_NPS_UW_SENSORS_GAZEBO_INCLUDE_NPS_UW_SENSORS_GAZEBO_NPS_GAZEBO_ROS_GPU_SONAR_SINGLE_BEAM_H_

Both of these are wrong, and it is not possible pass tests locally and in the github action environment with the same code.

Additional Notes

• Although the code_check.sh script specifies file extension .hh should be checked, cpplint.py only runs the CheckForHeaderGuard function on files with a .h extension (the relevant code is here).
• This means this issue does not show up for files with .hh extensions because it just skips the header guard check entirely.
• I believe this means that this check was never actually run on any code in vrx because we didn't write any headers with the .h extension, so this problem never showed up.
• Conversely, a workaround is just to use the .hh extension and skip this check.

The UUV Simulator HydrodynamicModel Plugin parses the neutrally_buoyant SDF parameter and calls a corresponding method (see https://uuvsimulator.github.io/packages/uuv_simulator/docs/api/gazebo::BuoyantObject/#public-voidsetneutrallybuoyant).

Not much documentation, but the name seems to suggest that this would setup the plugin so that the ROV was stable at a fixed alt/depth.

However, setting this parameter to 1 in rexrov xacro description (https://github.com/uuvsimulator/uuv_simulator/blob/master/uuv_descriptions/urdf/rexrov.gazebo.xacro), which is called by the example roslaunch uuv_dave uuv_dave.launch does not seem to have the desired effect.

Is there opencv version requirement to compile the code? My workaround is to change CV_AA to CV_L1 as suggested by the compiler. My machine is using OpenCV 4.1.0. See attached and let me know what you think.

Objective is to be able to simulate and assess the process of mating and demating an electrical optical connection. As an example see these videos:

• teledyne fly-through, simulated
• ROPOS Ocean Observatory ODI connections
• OCEANEERING jumper install with two manipulator plugin, simulated
• BluHaptics demo, illustrates how force feedback can be used for teleoperation

The Teledyne ODI connectors serve as a surrogate product family to consider. Below is background information for considering how to model the interactions:

• The Gross Alignment Funnel / Enhanced Latch Indicator is a newer product with design elements to aid ROV installation.
• The Installation and operation manual for wet-mate hybrid connectors is a great overview of how to mate/demate with an ROV.
• The Electrical/Optical Flying Lead connector, Case Study - Connecting Subsea Networks

Some of the features that should be included to simulate the mating/demating

• Representation of parameterized mating/demating force.
• Mating/demating are represented visually as the location of the mating pair as well as a visual indicator (see "enhanced latching indicator" in the Installation and operation manual for wet-mate hybrid connectors
• ROS interface to indicate successful mate/demate
• Representation of mating/demating alignment requirements (rotational, angular (tilt) and linear).
• ROS interface for diagnostics including current alignment, location and forces.
• Performance evaluation of mating/demating attempts including metrics such as...
  • alignment, rotational, angular (tilt) and linear (see Figures 15-17 in the Installation and operation manual for wet-mate hybrid connectors
  • mating/demating forces and "smoothness"
  • off axis forces and torques
  • end effector location relative to connector grip (See Figure 2 in the Installation and operation manual for wet-mate hybrid connectors

On default startup "roslaunch uuv_dave uuv_dave.launch" I notice some errors: Couldn't open joystick force feedback and We do not have clip. I get error "Couldn't open joystick force feedback!" and an indication at the bottom that a process has died. Also there are diagnostics verbiage that might be removed.

Sudden jumps at the topic published from the ocean current plugin are observed. I suspect it's a division error or int/double error. But not sure why exactly now.

To reproduce,

• Repositories
  • dave : master (commit : 4623fe5)
  • glider_hybrid_whoi : 'two_gliders' branch (commit : 30bb4312b67cff9a82304700d47a49c38447ab52)
• Launch command
  • roslaunch glider_hybrid_whoi_gazebo start_demo_kinamtics_stratified_current.launch
• Monitering
  • Through gazebo window, the glider teleports at random time
  • Transinet ocean current topic shows sudden jumps at it's value while it should be constant at constant depth.
    • rostopic echo /hydrodynamics/current_velocity/glider_hybrid_whoi
• Sudden jump happens randomly, sometimes at 8 seconds after the launch and other times at different time.

Example

• Correct value interpolated at its depth

header: 
  seq: 907
  stamp: 
    secs: 90
    nsecs: 900000000
  frame_id: "/world"
twist: 
  linear: 
    x: 0.00799999999868
    y: 0.00802509638012
    z: 0.0
  angular: 
    x: 0.0
    y: 0.0
    z: 0.0

• Sudden jumps appeared at random time

header: 
  seq: 908
  stamp: 
    secs: 91
    nsecs:         0
  frame_id: "/world"
twist: 
  linear: 
    x: 0.01
    y: 0.0100250963814
    z: 0.0
  angular: 
    x: 0.0
    y: 0.0
    z: 0.0

For early testing of vehicle implementation we use this simple node:
https://github.com/Field-Robotics-Lab/dave/blob/master/uuv_dave/nodes/joy_thrusterop.py

Would increase utility if the namespace was parameterized as a ROS parameters.

Currently this is community supported - see https://github.com/Field-Robotics-Lab/dave/wiki/Community-Supported-Features

Personally, I have been converted to using VCS for projects with more than one repo. If others think it is a meaningful addition,we should officially support by,

• Removing from community support
• Using vcs in official installation instructions
• Test

I experience unexpected behavior in the usbl tutorial when I rename the <model name="box"> in tutorial.world of usbl_gazebo

Steps to reproduce:

1. In tutorial.world rename <model name="box"> to <model name="box_2">
2. roslaunch usbl_gazebo tutorial.launch
3. rostopic pub --once /USBL/common_interrogation_ping std_msgs/String "data: 'ping'"

Error message in console of roslaunch usbl_gazebo tutorial.launch

[ INFO] [1626964248.162015610]: Physics dynamic reconfigure ready.
gzserver: /usr/include/boost/smart_ptr/shared_ptr.hpp:734: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = gazebo::physics::Model; typename boost::detail::sp_member_access<T>::type = gazebo::physics::Model*]: Assertion `px != 0' failed.
Aborted (core dumped)

Can anybody reproduce this behavior?

PR#54 for the ROV reuses the REXROV hydro parameters. This is probably fine for now, but should customize model for the new vehicle.

The body-frame for the slocum glider model is not correctly aligned.

The body frame should be consistent with the ROS convention from REP 103:

In relation to a body the standard is:

x forward
y left
z up

Can probably be done by simply rotating the visual model pose in reference to the base_link.

Need to also check the other glider models - hybrid and wave.

TODO: Description

Running this command

roslaunch uuv_dave uuv_gliders_hybrid_whoi.launch paused:=true

generates a warning...

[ WARN] [1599576113.958181542]: The root link glider_hybrid_whoi/base_link has an inertia specified in the URDF, but KDL does not support a root link with an inertia.  As a workaround, you can add an extra dummy link to your URDF.

This suggests that the rigid body inertia of the vehicle may not be set.

I believe the slocum and wave glider examples have the same warning: https://github.com/Field-Robotics-Lab/dave/wiki/Glider-Models