Although we already had some old work in this direction (thanks Mario!), we couldn't add it to main branch until last weeks. Today we are presenting interactive marker support in UWSim. To do so, we have updated the visualization_osg package and now it is available for ROS indigo and jade, and will be required in UWSim v1.4. This package allows to create markers and interactive markers in OpenSceneGraph. Although some things are still missing, such as menus, the main features are working and available in the github code and debian packages.
 
Using this package we have added interactive marker capabilities in UWSim, which means you should be able to create and move your own markers through the scene, and receive feedback in the server. Furthermore we have created a SpawnMarker service which will allow to create, modify and delete geometry through ROS service calls. As usual we added two interface examples to show how to use this new feature and provide basic code.
 
The first example followMarker creates an interactive marker that will be followed by a vehicle copying its pose. For this reason the example requires a dataNavigator topic of the vehicle. The second example uses the spawn marker service to create , modify or delete a mesh object in the desired position. More information about how to use this features is available in the uwsim wiki.
 
We are sure that this update will help to improve the usability of UWSim, and can be used to create much more interesting examples (scene configuration maybe?). We encourage you to share your ideas in the discussion group  and contribute. Finally, here is a short video of the interactive markers in action.

As some people were commenting, maintaining XML scenes was quite complicated due to the need of copying and pasting large blocks of XML, mostly unedited, from file to file. This caused huge problems on consistency, for instance the "same" simulated sensor could be different on each scene. In order to solve this we added a xacro processing on the build compilation and few suggested macros have been created to help with this issue. If you don't know what xacro is you can check this.  This feature is called at build time, so only source-based installation will have it automatically, although deb users can build their xacro files manually using "xacro.py". What we suggest is to use four main files for macro libraries, to know:

• Common: Basic generic macros for UWSimScenes.
• DeviceLibrary: intended for sensors and interfaces, some added as example.
• ObjectLibrary: Common used objects such as cirs terrain or blackbox should be available here, so there is no need to remember 3d mesh file, offsets or physics configuration to add them on a scene.
• VehicleLibrary: library for vehicles (uses deviceLibrary to add sensors). This way we can easily maintain different configurations for vehicles and add the whole vehicle in a scene instead of copying it.

And then in the scene xacro file (.xml.xacro) call this macros to build the scene. This allows to have a unique library for sensors, objects and vehicles and just call the macro in each scene where it is used. An example has also been added, "xacroExample.xml.xacro", which creates the 424 lines "cirs.xml" scene, with just 35 lines!.  
 
Finally some lines have been added to CMakeLists so ".xml.xacro" files present on data/scenes are automatically built on catkin_make. Also, if any of this files suffers any changes is rebuilt on the next catkin_make, so there is no need to call "rosrun xacro....". The only drawback is changes on the libraries will require a manual rebuild.

We have added examples and more detailed information on how to do it in our wiki.
 
I hope this example helps you to create your own macro library and finish with the inconsistency problems!

We recently added a new ROS interface to help users working with pointclouds(PCD) in UWSim: the ROSPointCloudLoader. This interface allows to hear pointclouds from a topic and visualize them on the 3D main window. The code takes all the required parameters, such as reference frame, from the pointcloud so there is only one parameter the topic name. Besides this parameter, an attribute can be configured to disable deleting the last PCD when a new one is received. This can be useful for laser stripe reconstruction to see the PCD building process. This is an example of how to include it into your scene XML file:

  <ROSPointCloudLoader delLastPCD="false">
    <topic>/laser_stripe/points2</topic>
  </ROSPointCloudLoader>

This example shows a PCD viewer for laser stripe reconstructions. In the following video you can see it running on both, a stereo reconstruction, and a laser stripe reconstruction. As can be seen in the video pointclouds will only be visible in the main windows, so it will not cause problems in virtual cameras.

Hope this feature helps debugging when working with pointclouds!.

We have completely updated the shader management of UWSim. Now shaders are created for each camera and main view, instead of for each object. This allows us to easily maintain shaders and use different shader effects on each camera.

Now osgOcean shaders are used, so the copied version of them present on data/shaders have been deleted, only maintaining default_scene shader, which is our custom object shader with added functionality such as structured light projector. This shader has been slightly optimized, so a small performance increase may be noticeable on some scenes.

Furthermore, this update also fixed some osgOcean underwater effects done through shaders as  uniforms were not correctly passed to virtual camera shaders.

Finally, depending on the texture and object colors some objects were showing wrong appearance, this should be fixed now. This was particularly noticeable in the ship of the shipwreck scene. See below the before(left) and after(right) images.

Besides this, an ARMask (Augmented Reality Mask) has been added to osgOcean in a way that every object using this mask should be visible only in the main view. This mask, has been applied to frames, frame labels, multibeam and range sensor debugs, trails ...etc. This means that now, virtual cameras should only see the raw scene without added information.

As this update required "major" modifications, bugs may appear, so please report any issue in the git repository as usual.