Original report (archived issue) by Michael McCarrin (Bitbucket: m1chaelm).

In the "T" section of the Propulsion Configuration Tutorial we say:

"To add a single lateral thruster requires the following changes:

• Define new URDF/xacro definition of the WAM-V https://github.com/osrf/vmrc/blob/master/wamv_gazebo/urdf/wamv_gazebo_t.urdf.xacro This description includes a new thruster layout:

1. A thruster layout definition that includes both the visual and thruster plugin parameters https://github.com/osrf/vmrc/blob/master/wamv_gazebo/urdf/thruster_layouts/wamv_t_thrusters.xacro

It could be just the bullet/number mix, but this explanation lost me. What do we mean by "define new URDF/xacro definition of the WAM-V"?

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

This is a proposal - would welcome improvements and comments.

As a first prototype, having the following simple capability would provide teams with a tool to prototype the way their autonomy deals with underwater acoustic beacons used in RobotX.

• Provides a simulated measurement of the range, azimuth and elevation between a specific model link and a fixed point (defined as location in gazebo coordinates)
• with user configured uncertainty in each of the three dimensions
• at a user configured update rate (0.5 - 2 Hz)

Teams have to develop this functionality using a variety of methods (e.g., hydrophone arrays and beam forming), but we can use a higher abstraction for the purposes of developing autonomy.

The description above is a sufficient first step. A couple of next-step extensions to increase fidelity, might include

• Uncertainty model should include Gaussian uncertainty, but could also include a probability of an outlier and/or dropout - which is typical of acoustic means.
• Ranges are subject to line-of-sight visibility (probably too detailed for RobotX)

Original report (archived issue) by [email protected] (Bitbucket: joshua.vaughan).

In the System Setup instructions, I think that

$ pip install vcstools

should be

$ pip install vcstool

The latter enables the remainder of the instructions; the former does not.

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

Would like to keep the basic working example minimal with the option to add more items such as the light_buoy, dock elements, etc.

• Add tutorial(s) to illustrate how to add elements to the provided example worlds.

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

Currently the visualization of the surface waves is independent of the wave displacements that affect the vessel motion. We have them setup to use the same wave parameters (amplitude, direction, etc.), but they are not synchronized in time.
See a demo of the effect: https://vimeo.com/253718860 And here is what happens if you have large wave in the physics, but the same small waves in the rendering: https://vimeo.com/253842494

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

This document might be relevant.

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

Working in default branch. When I run roslaunch robotx_gazebo sandisland.launch, I get error...

#!bash
[FATAL] [1531350486.327760996]: You must call ros::init() before creating the first NodeHandle

...

Couldn't find an AF_INET address for []

If I edit the sandisland.launch file to use the world: "$(find robotx_gazebo)/worlds/sandisland.world
then the error goes away.

Ran out of time to chase this one to ground.

Original report (archived issue) by Anonymous.

The original report had attachments: 1.png

I want to add velodyne sensors on WAM-V and I use the file from velodyne_simulator
I include the HDL32-E file into wamv-robotx.xacro file.
I can see the model and /velodyne_points, but there is no data in the topic
and terminal which launches sandisand will not show "command timeout" and the number anymore.

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

This issue was discussed in pull request #41.

A potential solution might involve to play with visibility masks.

Original report (archived issue) by Arthur Hsieh (Bitbucket: arthur960304).

I just found some typos and mistakes in tutorials, please check.

Tutorials/Driving:

1. In section Overview second paragraph line 4: and "-1.0" is maximum reverse force.
2. In section Examples, rostopic pub: "rostopic pub --once /cmd_drive robots_gazebo/UsvDrive..." should change to "rostopic pub --once /cmd_drive usv_gazebo_plugins/UsvDrive..."

Tutorials/Visualizing with RVIZ:

1. In section Publishing a TF tree: "$ roslaunch wamv_gazebo localization_example.launch" is not working on my desktop. Here is the error message:

ERROR: cannot launch node of type [robot_localization/ekf_localization_node]: robot_localization

ROS path [0]=/opt/ros/kinetic/share/ros

ROS path [1]=/home/nctuece/vmrc_ws/src

ROS path [2]=/opt/ros/kinetic/share

ERROR: cannot launch node of type [robot_localization/navsat_transform_node]: robot_localization

ROS path [0]=/opt/ros/kinetic/share/ros

ROS path [1]=/home/nctuece/vmrc_ws/src

ROS path [2]=/opt/ros/kinetic/share

Tutorials/ChangingPluginParameters:

1. File Location is not right: it should be changed to "wamv_gazebo/urdf/dynamics/...xacro"

Original report (archived issue) by Kevin Allen (Bitbucket: kev-the-dev).

Team UF has a working scan the code challenge in Gazebo on their open source repo. We can put it in here for teams to use

Original report (archived issue) by Michael McCarrin (Bitbucket: m1chaelm).

In the System Install tutorial for installing files to host, the catkin_make command fails with the message:

In file included from /home/user/vmrc_ws/src/vmrc/usv_gazebo_plugins/src/usv_gazebo_wind_plugin.cc:27:
/usr/include/gazebo-7/gazebo/common/Plugin.hh:42:22: fatal error: sdf/sdf.hh: No such file or directory
compilation terminated.

It's possible that this was caused by conflict with a previous ROS install, but I'm not sure.

The full output is as follows:
Base path: /home/user/vmrc_ws
Source space: /home/user/vmrc_ws/src
Build space: /home/user/vmrc_ws/build
Devel space: /home/user/vmrc_ws/devel
Install space: /home/user/vmrc_ws/install

Running command: "make cmake_check_build_system" in "/home/user/vmrc_ws/build"

Running command: "make -j4 -l4" in "/home/user/vmrc_ws/build"

[ 4%] Building CXX object vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_wind_plugin.dir/src/usv_gazebo_wind_plugin.cc.o
[ 4%] Building CXX object vmrc/usv_gazebo_plugins/CMakeFiles/buoyancy_gazebo_plugin.dir/src/buoyancy_gazebo_plugin.cc.o
[ 7%] Building CXX object vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_dynamics_plugin.dir/src/usv_gazebo_dynamics_plugin.cc.o
[ 9%] Building CXX object vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_thrust_plugin.dir/src/usv_gazebo_thrust_plugin.cc.o
In file included from /home/user/vmrc_ws/src/vmrc/usv_gazebo_plugins/src/buoyancy_gazebo_plugin.cc:21:0:
/usr/include/gazebo-7/gazebo/common/Events.hh:21:22: fatal error: sdf/sdf.hh: No such file or directory
compilation terminated.
vmrc/usv_gazebo_plugins/CMakeFiles/buoyancy_gazebo_plugin.dir/build.make:62: recipe for target 'vmrc/usv_gazebo_plugins/CMakeFiles/buoyancy_gazebo_plugin.dir/src/buoyancy_gazebo_plugin.cc.o' failed
make[2]: *** [vmrc/usv_gazebo_plugins/CMakeFiles/buoyancy_gazebo_plugin.dir/src/buoyancy_gazebo_plugin.cc.o] Error 1
CMakeFiles/Makefile2:785: recipe for target 'vmrc/usv_gazebo_plugins/CMakeFiles/buoyancy_gazebo_plugin.dir/all' failed
make[1]: *** [vmrc/usv_gazebo_plugins/CMakeFiles/buoyancy_gazebo_plugin.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
In file included from /home/user/vmrc_ws/src/vmrc/usv_gazebo_plugins/include/usv_gazebo_plugins/usv_gazebo_wind_plugin.hh:28:0,
from /home/user/vmrc_ws/src/vmrc/usv_gazebo_plugins/src/usv_gazebo_wind_plugin.cc:27:
/usr/include/gazebo-7/gazebo/common/Plugin.hh:42:22: fatal error: sdf/sdf.hh: No such file or directory
compilation terminated.
vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_wind_plugin.dir/build.make:62: recipe for target 'vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_wind_plugin.dir/src/usv_gazebo_wind_plugin.cc.o' failed
make[2]: *** [vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_wind_plugin.dir/src/usv_gazebo_wind_plugin.cc.o] Error 1
CMakeFiles/Makefile2:822: recipe for target 'vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_wind_plugin.dir/all' failed
make[1]: *** [vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_wind_plugin.dir/all] Error 2
In file included from /home/user/vmrc_ws/src/vmrc/usv_gazebo_plugins/include/usv_gazebo_plugins/usv_gazebo_thrust_plugin.hh:35:0,
from /home/user/vmrc_ws/src/vmrc/usv_gazebo_plugins/src/usv_gazebo_thrust_plugin.cc:28:
/usr/include/gazebo-7/gazebo/common/Plugin.hh:42:22: fatal error: sdf/sdf.hh: No such file or directory
compilation terminated.
vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_thrust_plugin.dir/build.make:62: recipe for target 'vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_thrust_plugin.dir/src/usv_gazebo_thrust_plugin.cc.o' failed
make[2]: *** [vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_thrust_plugin.dir/src/usv_gazebo_thrust_plugin.cc.o] Error 1
CMakeFiles/Makefile2:891: recipe for target 'vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_thrust_plugin.dir/all' failed
make[1]: *** [vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_thrust_plugin.dir/all] Error 2
In file included from /usr/include/gazebo-7/gazebo/common/common.hh:8:0,
from /home/user/vmrc_ws/src/vmrc/usv_gazebo_plugins/include/usv_gazebo_plugins/usv_gazebo_dynamics_plugin.hh:31,
from /home/user/vmrc_ws/src/vmrc/usv_gazebo_plugins/src/usv_gazebo_dynamics_plugin.cc:32:
/usr/include/gazebo-7/gazebo/common/Battery.hh:25:22: fatal error: sdf/sdf.hh: No such file or directory
compilation terminated.
vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_dynamics_plugin.dir/build.make:62: recipe for target 'vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_dynamics_plugin.dir/src/usv_gazebo_dynamics_plugin.cc.o' failed
make[2]: *** [vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_dynamics_plugin.dir/src/usv_gazebo_dynamics_plugin.cc.o] Error 1
CMakeFiles/Makefile2:1024: recipe for target 'vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_dynamics_plugin.dir/all' failed
make[1]: *** [vmrc/usv_gazebo_plugins/CMakeFiles/usv_gazebo_dynamics_plugin.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
Invoking "make -j4 -l4" failed

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

With release 0.2.0 we'd like to have a docker hub image for folks to download directly, rather than building their own.

• Need internal documentation on the workflow for creating the image and pushing to docker hub.
• Where do we host this at docker hub? Does OSRF have a preference or an organization with in the hub? Should we start a new "VMRC" organization on docker hub.
• Need a short tutorial under system setup for novice users to be able to use this from scratch: https://osrf-migration.github.io/vrx-gh-pages/#!/osrf/vmrc/wiki/tutorials

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

Based on Carlos' email comments, would recommend the following refactor for docker tutorials:

• Install on host: no changes
• Using Docker:
  • Install Docker (Common setup for all docker use cases)
    • Install Nvidia Docker (additional instructions for Nvidia users)
  • Two posibilities for using Docker containers
    1. Download and run current Docker image from Docker Hub (includes both non-nvidia and nvidia directions) Use this option if you want a stable setup with minimal steps to get running, but without the latest changes to the source code. Best if you are a user and don't plan to contribute to the project.
    2. Build and run Docker image from latest VMRC repository (includes both non-nvidia and nvidia directions) Use this option if you want your own Docker container with the most recent source code. Best if you want to contribute to the VMRC project.

Original report (archived issue) by Kevin Allen (Bitbucket: kev-the-dev).

Add simulation xacro and (if needed) plugins for simulating a 3D scanning LIDAR, similar to a Velodyne puck.

This will be useful for the RobotX teams which use a sensor like this and could be a standard sensor for the virtual competition.

Gazebo7 supports the simulation of sensors like this using the gpu_sensor. For getting this sensor to interface with ROS, there are a few options:

• The velodyne_simulator contains a plugin to simulate a velodyne, publishing the same output as the real velodyne driver. Downside: somewhat specific to velodyne sensor

• gazebo_ros_block_laser plugin in gazebo_ros_pkgs. Downsides: publishes the legacy PointCloud message instead of PointCloud2 (which may make it incompatible with some higher level software) and it does NOT support gpu based simulation.

• The gazebo_ros_ray_sensor plugin in my recent Pull Request to gazebo_ros_pkgs. This provides something similar to gazebo_ros_block_laser but uses the newer message standard and supports either CPU or GPU simulation. Downside: not currently merged (may never be merged into kinetic), so would likely have to import it into this repo

Original report (archived issue) by Michael McCarrin (Bitbucket: m1chaelm).

Docker tags only support ASCII (see https://docs.docker.com/engine/reference/commandline/tag/). The build.bash script generates tags using the Linux date command, and the output of the date command varies depending on the locale settings. For some locale settings, such as Chinese, this causes the date command to produce a unicode string, which causes a crash when used as input to the -t argument of the docker build command.

We can avoid this by choosing a tag format that is ASCII in all locales. One fix is to eliminate the use of date. Another is to use formatting options that remain numeric (such as %m instead of %b).

Original report (archived issue) by Michael McCarrin (Bitbucket: m1chaelm).

Currently, this tutorial only makes sense for users who followed the host-based install path. We could update it to include alternative commands for users who followed the Docker-based path. This will add some complexity, however.

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

If I do a clean setup, e.g.,

#!bash

cd ~/vmrc_ws/src
hg clone ssh://[email protected]/osrf/vmrc
cd ~/vrmc_ws
catkin_make

I then get a make error - the pertinent bit seems to be

In file included from /home/bsb/vmrc_ws/src/vmrc/usv_gazebo_plugins/src/usv_gazebo_thrust_plugin.cc:26:0:
/home/bsb/vmrc_ws/src/vmrc/usv_gazebo_plugins/include/usv_gazebo_plugins/usv_gazebo_thrust_plugin.hh:36:41: fatal error: usv_gazebo_plugins/UsvDrive.h: No such file or directory

If I run catkin_make again, it all compiles.

Original report (archived issue) by Arthur Hsieh (Bitbucket: arthur960304).

I followed steps in the tutorials of buildRunLocalImage but I found that I could not execute the command $ ./build.bash vmrc

Here is the error message:

"docker build" requires exactly 1 argument.
See 'docker build --help'.

Usage: docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile
"docker tag" requires exactly 2 arguments.
See 'docker tag --help'.

Usage: docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]

Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
Built vmrc:2018_ 8月_28_1201 and tagged as vmrc:latest

I'm not sure why is this happening.

Original report (archived issue) by Raymond Andrade (Bitbucket: 808brick).

Hey All, thanks for the great work on the simulation. I just wanted to point out that there was no documentation for utilizing sensors with different thruster configurations. When running:

#!unix

roslaunch robotx_gazebo sandisland.launch urdf:=`pwd`/my_wamv.urdf  thrust_config:=X

It will run the simulation with the sensors, but the thrust configuration will remain as the default "H" Layout.
To change this I had to edit wamv_gazebo.urdf.xacro so that the line:

#!xacro

<xacro:wamv_gazebo thruster_layout="$(find wamv_gazebo)/urdf/thruster_layouts/wamv_aft_thrusters.xacro"/>

instead reads:

#!xacro

<xacro:wamv_gazebo thruster_layout="$(find wamv_gazebo)/urdf/thruster_layouts/wamv_x_thrusters.xacro"/>

and then converting the xacro to urdf by:

#!unix

rosrun xacro xacro --inorder wamv_gazebo.urdf.xacro > wamv_gazebo.urdf

Only after doing this will the command:

#!unix

roslaunch robotx_gazebo sandisland.launch urdf:=`pwd`/my_wamv.urdf  thrust_config:=X

work as expected

If this documentation was added to the tutorials I think that would help others who are trying to utilize the sensors with the different thrust configurations.

Original report (archived issue) by Kevin Allen (Bitbucket: kev-the-dev).

Several teams used a holonomic (4 motor) configuration at RobotX 2016. This feature was also requested by a member of the RobotX fourms.

Here's one plan:

• Add a new urdf with 4 engines attached, each at 45 degree angles
• Adjust the thrust plugin to accommodate this configuration

Original report (archived issue) by Kevin Allen (Bitbucket: kev-the-dev).

The sensor example requires hector-gazebo-plugins package but it is not installed in the tutorial of docker image.

Original report (archived issue) by Raymond Andrade (Bitbucket: 808brick).

I think the latest release to main repository has a Gazebo related bug in it. After following all the setup instructions in the tutorial, I am unable to startup the simulation, as Gazebo just hangs on launch. The Gazebo window and GUI opens, but then the program just hangs and never shows the simulation.

The last thing printed in the terminal is:
[spawn_model-3] process has finished cleanly
log file: /home/raymond/.ros/log/a1ec64b8-8c8d-11e8-8535-1002b5c27c61/spawn_model-3*.log

I had a previous version of the simulation working, but I decided to reinstall the simulation as mine had not been updated since late May. I have tried restarting terminal, restarting computer, and recompiling with catkin_make.

Any help would be appreciated

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

Deadline: October 15th.

Required:

• ☑ Task draft.
• ☐ Docker maintenance and improvements.
  • ☑ Build images automatically. Issue #36 and #55
  • ☐ Tutorial update. Issue #37.
  • ~~ ☐ Issue #45. Pushed for future release. ~~
  • ☑ Issue #47.
  • ☑ Issue #53. Update Docker image in repo.
  • ☐ Update Docker-based tutorials to use new package names.
• ~~ ☐ Refine sensor configuration. Issue #30.~~ Pushed for future release.
• ~~ ☐ Laser reflecting the ocean. Issue #29. Pushed for future release.~~
• ~~ ☐ Acoustic beacons. Issue #26. Pushed for future release.~~
• ~~ ☐ Wave physical and rendering synchronization. See issue #23. Pushed for future release.~~
• ☑ Create a .Deb package. Issue #50.
• ☐ Tutorial review.

Optional:

• ☐ Better buoyancy model based on multiple simple shapes.
• ☐ Create nice sensor meshes.
• ☐ Create mesh to mount the lateral thruster (if present).

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

See https://github.com/osrf/vmrc/blob/master/robotx_gazebo/ for the current status.

Original report (archived issue) by Michael McCarrin (Bitbucket: m1chaelm).

The drive tutorial says:
"To use the keyboard, we use the teleop_twist_keyboard package, along with a custom twist2drive_keyboard.py node to convert the Twist messages to two Float32 messages for the left and right thrusters. "
However, the link to the twist2drive_keyboard.py gives a file-not-found error. Should this be https://github.com/osrf/vmrc/blob/master/robotx_gazebo/nodes/twist2thrust.py instead? I think it probably should, so I've changed it, but I'm not completely sure if that's right.

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

Will need this for scoring. Should also determine direction of crossing.

Brian has a prototype here https://github.com/bsb808/rossc/blob/master/nodes/speed_test_eval.py

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

Not sure if this is a bug, or just something we should document.

On my desktop, with an NVIDIA card, I successfully run the NVIDIA version of the Docker Hub image tutorial.

If I try to run the non-NVIDIA image...

$ ./run.bash osrf/vmrc:current

The docker image downloads and runs correctly, but then seg faults when I try the example...

developer@e7912a51336d:~$ roslaunch robotx_gazebo sandisland.launch 
... logging to /home/developer/.ros/log/58bfcf3c-aa33-11e8-aa75-0242ac110002/roslaunch-e7912a51336d-58.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://e7912a51336d:38151/

SUMMARY
========

PARAMETERS
 * /robot_description: <?xml version="1....
 * /rosdistro: kinetic
 * /rosversion: 1.12.13
 * /use_sim_time: True

NODES
  /
    gazebo (gazebo_ros/gzserver)
    gazebo_gui (gazebo_ros/gzclient)
    spawn_model (gazebo_ros/spawn_model)

auto-starting new master
process[master]: started with pid [68]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 58bfcf3c-aa33-11e8-aa75-0242ac110002
process[rosout-1]: started with pid [81]
started core service [/rosout]
process[gazebo-2]: started with pid [88]
[ INFO] [1535399815.825274566]: Finished loading Gazebo ROS API Plugin.
[ INFO] [1535399815.825703481]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
process[gazebo_gui-3]: started with pid [110]
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Warning [parser.cc:644] XML Attribute[xmlns:xacro] in element[sdf] not defined in SDF, ignoring.
Warning [parser.cc:644] XML Attribute[xmlns:xacro] in element[world] not defined in SDF, ignoring.
[ INFO] [1535399816.093618114]: Finished loading Gazebo ROS API Plugin.
process[spawn_model-4]: started with pid [177]
[ INFO] [1535399816.115683393]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
[ INFO] [1535399817.094805121]: Pattern is YRY
[ INFO] [1535399817.132733059, 0.022000000]: waitForService: Service [/gazebo/set_physics_properties] is now available.
[ INFO] [1535399817.157287113, 0.046000000]: Physics dynamic reconfigure ready.
[ INFO] [1535399817.365024684, 0.249000000]: waitForService: Service [/gazebo/set_physics_properties] is now available.
Warning [parser.cc:644] XML Attribute[xmlns:xacro] in element[plugin] not defined in SDF, ignoring.
[ INFO] [1535399817.489728272, 0.307000000]: Physics dynamic reconfigure ready.
[spawn_model-4] process has finished cleanly
log file: /home/developer/.ros/log/58bfcf3c-aa33-11e8-aa75-0242ac110002/spawn_model-4*.log
Segmentation fault (core dumped)
[gazebo_gui-3] process has died [pid 110, exit code 139, cmd /opt/ros/kinetic/lib/gazebo_ros/gzclient __name:=gazebo_gui __log:=/home/developer/.ros/log/58bfcf3c-aa33-11e8-aa75-0242ac110002/gazebo_gui-3.log].
log file: /home/developer/.ros/log/58bfcf3c-aa33-11e8-aa75-0242ac110002/gazebo_gui-3*.log
^C[gazebo-2] killing on exit
[gazebo-2] escalating to SIGTERM
[rosout-1] killing on exit
[master] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done
developer@e7912a51336d:~$ 

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

Edit plugin parameters for GPS, IMU, LIDAR, cameras, etc. to reflect typical sensors used in RobotX. This would serve as the standard configuration used in VMRC.

Original report (archived issue) by Kevin Allen (Bitbucket: kev-the-dev).

Running sandisland.launch with gazebo7 currently causes a gzserver to crash with an error related to the sandisland height map. There may be an issue in our configuration or it could be a bug in gazebo.

The following PR is related:
[https://bitbucket.org/osrf/gazebo/pull-requests/2978/check-terrain-layer-count-in-height-map/activity#](Link URL)

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

There's a constant flow of log information:

[ INFO] [1530898335.354347581, 5.500000000]: 0: 0.0414236 / 0.000165695
[ INFO] [1530898335.855024332, 6.3167fc3ec4555094a7bbd76a87b675a9e5e2d065]: 0: 0.0414236 / 0.000165695
[ INFO] [1530898335.891886977, 6.037000000]: Command timeout!
[ INFO] [1530898336.357305769, 6.501000000]: 0: 0.0414236 / 0.000

that deviates the attention from other errors or sporadic log info. We should avoid continuous log messages.

We could either play with the log level or remove these calls to ROS_INFO_STREAM_THROTTLE() in usv_gazebo_thrust_plugin.cc.

Original report (archived issue) by Anonymous.

In your tutorial you only mentioned that "X" will be transformed into a 4x4 grid dock block in model.sdf.erb file.

My question is, how do I let "X" to be transformed into 2x2 or 3x3 grid dock block?

I think it would be better to include that in tutorial.

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

Related tutorials:

http://wiki.ros.org/bloom/Tutorials/FirstTimeRelease
http://wiki.ros.org/rosdistro/Tutorials/Indexing%20Your%20ROS%20Repository%20for%20Documentation%20Generation

Original report (archived issue) by Anonymous.

We try to use velodyne_simulation package (https://bitbucket.org/DataspeedInc/velodyne_simulator/src/01bfb68ef647?at=master) with VMRC simulation.
However, when we add velodyne sensor to the URDF model and try to recieve /velodyne_points topic, simulation time in gazebo stops.

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

When running default example: `rosluan
I till get the warning...

[ INFO] [1531426975.285814102, 0.262000000]: Physics dynamic reconfigure ready.
Warning [parser.cc:437] Converting a deprecated SDF source[data-string].
[ INFO] [1531426976.783171816, 1.727000000]: missing <robotNamespace>, defaulting to 
[ INFO] [1531426976.783269823, 1.727000000]: missing <topicName>, defaulting to color
Warning [parser.cc:437] Converting a deprecated SDF source[data-string].
[ INFO] [1531426976.789518507, 1.733000000]: missing <robotNamespace>, defaulting to 
[ INFO] [1531426976.789619557, 1.734000000]: missing <topicName>, defaulting to color
Warning [parser.cc:437] Converting a deprecated SDF source[data-string].
[ INFO] [1531426976.797483575, 1.742000000]: missing <robotNamespace>, defaulting to 
[ INFO] [1531426976.797502613, 1.742000000]: missing <topicName>, defaulting to color

Console output suggests it may be associated with the gazebo_ros_color plugin.

Perhaps related to this issue?

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

Will need for VMRC scoring.
Define min and max radius. Report via ros message if a robot has circumnavigated - and report direction.

Original report (archived issue) by Kevin Allen (Bitbucket: kev-the-dev).

The tutorials point the user to https://github.com/bsb808/nps_robotx for an example of a WAM-V with sensors / localization. I think an example like this should be in this repo for teams to reference

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

When launching VMRC with:

roslaunch robotx_gazebo sandisland.launch

there are two xacro warnings:

Warning [parser.cc:644] XML Attribute[xmlns:xacro] in element[sdf] not defined in SDF, ignoring.
Warning [parser.cc:644] XML Attribute[xmlns:xacro] in element[world] not defined in SDF, ignoring.

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

Some ideas:

• Show WAM-V model, propellers spinning, collisions, inertias
• Show current environments with all the different challenges
• Show wind
• Show waves
• Show buoyancy
• Show dynamics teleoperating
• Show sensors with ROS integration (RViz)

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

Including some cleaning if possible but no big functional refactors.

Original report (archived issue) by Michael McCarrin (Bitbucket: m1chaelm).

This tutorial contains three commands, for running a simulation, robot localization, and visualization. All 3 commands are currently failing on my machine (configured using the host installation from tutorial 1). Is there additional preparation that needs to be completed before running this?

The output of the commands is:

#!bash

$ ~/vmrc_ws/example_vmrc_package$ roslaunch robotx_gazebo vmrc.launch

[vmrc.launch] is neither a launch file in package [robotx_gazebo] nor is [robotx_gazebo] a launch file name
The traceback for the exception was written to the log file

#!bash

$ ~/vmrc_ws/example_vmrc_package$ roslaunch wamv_gazebo localization_example.launch 

... logging to /home/mq/.ros/log/20447be0-a839-11e8-8fc7-4c34883f13b7/roslaunch-mq-ThinkPad-X1-Carbon-3rd-30263.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://mq-ThinkPad-X1-Carbon-3rd:43783/

SUMMARY
========

PARAMETERS
 * /ekf_localization/base_link_frame: base_link
 * /ekf_localization/frequency: 60
 * /ekf_localization/imu0: imu/data
 * /ekf_localization/imu0_config: [False, False, Fa...
 * /ekf_localization/imu0_differential: False
 * /ekf_localization/imu0_remove_gravitational_acceleration: True
 * /ekf_localization/map_frame: map
 * /ekf_localization/odom0: odometry/gps
 * /ekf_localization/odom0_config: [True, True, True...
 * /ekf_localization/odom0_differential: False
 * /ekf_localization/odom_frame: odom
 * /ekf_localization/publish_tf: True
 * /ekf_localization/sensor_timeout: 2.0
 * /ekf_localization/smooth_lagged_data: True
 * /ekf_localization/two_d_mode: False
 * /ekf_localization/world_frame: odom
 * /navsat_transform_node/broadcast_utm_transform: True
 * /navsat_transform_node/datum: [21.30996, -157.8...
 * /navsat_transform_node/frequency: 60
 * /navsat_transform_node/magnetic_declination_radians: 0
 * /navsat_transform_node/publish_filtered_gps: True
 * /navsat_transform_node/use_odometry_yaw: True
 * /navsat_transform_node/wait_for_datum: True
 * /navsat_transform_node/yaw_offset: 0
 * /rosdistro: kinetic
 * /rosversion: 1.12.13

NODES
  /
    ekf_localization (robot_localization/ekf_localization_node)
    navsat_transform_node (robot_localization/navsat_transform_node)
    rob_st_pub (robot_state_publisher/robot_state_publisher)

auto-starting new master
process[master]: started with pid [30273]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 20447be0-a839-11e8-8fc7-4c34883f13b7
process[rosout-1]: started with pid [30286]
started core service [/rosout]
process[rob_st_pub-2]: started with pid [30303]
process[ekf_localization-3]: started with pid [30304]
process[navsat_transform_node-4]: started with pid [30306]
[ERROR] [1535182394.941206542]: Could not find parameter robot_description on parameter server
[ INFO] [1535182394.979079447]: Datum (latitude, longitude, altitude) is (21.309960, -157.890100, 0.000000)
[ INFO] [1535182394.979148879]: Datum UTM coordinate is (615116.100362, 2356857.621317)
[ INFO] [1535182394.979189190]: Initial odometry pose is Origin: (0 0 0)
Rotation (RPY): (0, -0, 0)

[ INFO] [1535182394.997427626]: Corrected for magnetic declination of 0.000000 and user-specified offset of 0.000000. Transform heading factor is now 0.000000
[ INFO] [1535182394.997487988]: Transform world frame pose is: Origin: (0 0 0)
Rotation (RPY): (0, -0, 0)

[ INFO] [1535182394.997540326]: World frame->utm transform is Origin: (-615116.10036203637719 -2356857.6213171021082 0)
Rotation (RPY): (0, 0, -1.6798231958602382502e-322)

[rob_st_pub-2] process has died [pid 30303, exit code 255, cmd /opt/ros/kinetic/lib/robot_state_publisher/robot_state_publisher __name:=rob_st_pub __log:=/home/mq/.ros/log/20447be0-a839-11e8-8fc7-4c34883f13b7/rob_st_pub-2.log].
log file: /home/mq/.ros/log/20447be0-a839-11e8-8fc7-4c34883f13b7/rob_st_pub-2*.log

#!bash

$ ~/vmrc_ws/example_vmrc_package$ roslaunch wamv_gazebo rviz_vmrc.launch

[rviz_vmrc.launch] is neither a launch file in package [wamv_gazebo] nor is [wamv_gazebo] a launch file name
The traceback for the exception was written to the log file

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).

For scoring purposes will want to get notifications of WAM-V collisions with obstacles. Plugin should include logic so that only one event is recorded per incident.

Original report (archived issue) by Kevin Allen (Bitbucket: kev-the-dev).

As found in #1, the height map based collision for sandisland is very taxing on ray based sensors such as the velodyne_gazebo plugin. This collision is not very important, as the simulation will take place in open water with objects remaining on the surface, so it could just be removed. Alternatively, simple geometries for the shore and sea floor collisions could be implemented.

Original report (archived issue) by Michael McCarrin (Bitbucket: m1chaelm).

The original report had attachments: rviz_errors.png

Following steps up to the "Running RVIZ" section of the rviz tutorial and running the command:

#!bash

roslaunch wamv_gazebo rviz_example.launch

opens rviz with a white outline of the wamv model and many errors displayed on the left side of the screen. This appears to be the case whether or not any modifications have been made to the urdf file. The error messages appear to relate to missing odometry information (see attached screenshot).

Original report (archived issue) by Michael McCarrin (Bitbucket: m1chaelm).

The driving tutorial (https://osrf-migration.github.io/vrx-gh-pages/#!/osrf/vmrc/wiki/tutorials/Driving) describes a "default configuration" that is associated with a wamv_gazebo_thrust_plugin.xacro file. The link to the file (https://github.com/osrf/vmrc/blob/master/wamv_gazebo/urdf/dynamics/wamv_gazebo_thrust_plugin.xacro) gives a file not found error. On inspecting the source, it seems that this file has been deprecated and is no longer the default. However, many details of the tutorial still seem to work, so I'm not sure whether the tutorial is still using the configuration it describes or not. If it is, then we should update the link to the correct configuration file. If not, we may need to change the description of the model in the tutorial to match whatever the new default is.

This same problem occurs in the Propulsion Configuration tutorial (https://osrf-migration.github.io/vrx-gh-pages/#!/osrf/vmrc/wiki/tutorials/PropulsionConfiguration), which has a copy of the same paragraph in it.

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

When there are changes in the affected branches. DockerHub allows to do this but we need to fix some errors.

Original report (archived issue) by Kevin Allen (Bitbucket: kev-the-dev).

Remove references to kingfisher_gazebo package, as it is not listed as a dependency and is independently maintained. If any files from this package are needed, copy them into this repo

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

Required:

• ☑ Add outstanding models. See issue #16.
• ☑ Refactor all plugins to follow Gazebo style. See issue #17.
• ☑ Add basic tests.
• ☑ Add an initial set of sensors and instructions and helpers for customize our own list.
  See issue #18.
• ☑ Create new video with latest changes. Issue #20.
• ☑ Reduce log information. See issue #14.
• ☑ Review/rerun tutorials before the release . See issue #25.

Optional:

• ☑ 3D LIDAR support.
• ☐ Better buoyancy model based on multiple simple shapes.
• ☑ Support for other propulsion configurations. See issue #11.
• ☑ No warnings when launching. See issue #13.
• ☐ Create a .Deb package.
• ☑ Push a Docker image to a Docker hub. See issue #22.
• ☐ Coordinate the physics and visualization of the wave field. See issue #23

Original report (archived issue) by Raymond Andrade (Bitbucket: 808brick).

When running the command:

#!unix

vcs import . < vmrc.repos

I get the following output:

#!Unix

=== ./robotx_gazebo (hg) ===
Could not determine url: not found!

It's worth noting that I needed to use:

#!unix

sudo pip install vcstools

to install vcstools without an error.

If I try to proceed with the rest of the tutorial, when I try to launch the project I get:

#!unix

[sandisland.launch] is neither a launch file in package [robotx_gazebo] nor is [robotx_gazebo] a launch file name
The traceback for the exception was written to the log file

I am running Ubuntu 16.04 and had ROS Kinetic installed prior

Original report (archived issue) by Michael McCarrin (Bitbucket: m1chaelm).

In the Teleop: Gamepad section of the Driving tutorial, we say:
"To use a gamepad, we use the joy and joy_teleop packages, along with a custom twist2drive_diff node to convert Twist messages from the standard telelop to two Float32 messages for the thruster plugin."

However, the link to the twist2drive_diff file is broken and a search of the source does not find the file. I don't have a gamepad to test this part of the tutorial. If it is working properly and the file has changed, we should update to reference the new file.