All documentation of Project DAVE can be found in the Dave Documentation (https://field-robotics-lab.github.io/dave.doc/).
The documentation source code is in the Field-Robotics-Lab/dave.doc repository.
Project DAVE
License: Apache License 2.0
All documentation of Project DAVE can be found in the Dave Documentation (https://field-robotics-lab.github.io/dave.doc/).
The documentation source code is in the Field-Robotics-Lab/dave.doc repository.
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
.
I experience unexpected behavior in the usbl tutorial when I rename the <model name="box">
in tutorial.world
of usbl_gazebo
Steps to reproduce:
tutorial.world
rename <model name="box">
to <model name="box_2">
roslaunch usbl_gazebo tutorial.launch
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?
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.
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.
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.
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:
The Teledyne ODI connectors serve as a surrogate product family to consider. Below is background information for considering how to model the interactions:
Some of the features that should be included to simulate the mating/demating
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
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.
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.
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)..hh
extensions because it just skips the header guard check entirely..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.
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,
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
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.
Make our conditional smarter so it can detect directories too.
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) =
| ~~~~~~~~~~~~~~~~~~~^~~~~~~~
B/c the PR is in github and Peng can't make changes to github I am doing the following...
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.
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.
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.
Believe we decided on .cc and .hh
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
If you have verified all this, no need to reply, but wanted to make sure we have verified the various functionalities, e.g,
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.
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.
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.
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,
roslaunch glider_hybrid_whoi_gazebo start_demo_kinamtics_stratified_current.launch
rostopic echo /hydrodynamics/current_velocity/glider_hybrid_whoi
Example
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
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
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,
@bsb808 Is the proposed method what you meant?
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.
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?
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.
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].
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
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.
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.
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:
The combination of these choices allow the user to build 4 different varieties of images.
Problem:
Fix:
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.
Ideally we should check for a controller at each available /dev/input/js#
and if none are found fall back to keyboard teleop control.
PR#54 for the ROV reuses the REXROV hydro parameters. This is probably fine for now, but should customize model for the new vehicle.
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).
join.bash takes the image name as an argument instead of the container name.
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.
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.
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.
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.
After merging PR#50, move the custom ROS messages to the frl_msgs repository.
We should get the docker images working, then synchronize the host installation instructions to the docker images.
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
---
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.
The Docker image installation instructions have fallen out of date. The following need to be addressed:
Goal is to have station-keeping functionality demonstrated (examples and tutorial/demo instructions).
Typically for ROVs the motion control is decomposed into independent DOFs:
Each of these DOFs can be enabled/disabled independently. For our work this would be actuated via joystick or keyboard teleop.
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:
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.
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.
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.
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>
On some systems, this produces the desired effect:
On other systems, however, this same configuration produces very strange laser effects:
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.
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.
I'm not done testing yet. There might be more, but I wanted to start the ticket in the interest of release timeline.
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?
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.
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.
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.
TODO: Description
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.
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.
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).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.