News

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.

Force sensors are now available on UWSim. It measures the external forces on a part of a vehicle. It can be added to every visual part of a vehicle and it will measure the collision forces the piece is suffering in Newtons force torque.

This sensor uses Bullet physics engine to create two identical collision shapes one colliding with external objects and one "ghost" that traverses them, at the end of each physics iteration measuring the difference between these two collision shapes allows us to calculate the force suffered by the object. Physical properties of the vehicle part such as weight should be correctly provided on URDF to obtain realistic results. For instance, this sensor has been used to measure collision forces of the girona500 vehicle and send this information to underwater vehicle dynamics module which uses it as an input for external forces, the result is vehicle can no longer traverse objects as we can see in the embedded video. The XML code needed to add one is:

  <ForceSensor>
    <name>ForceG500</name>
    <target>base_link</target>
    <offsetp>
      <x>-0.2</x>
      <y>0.75</y>
      <z>0</z>
    </offsetp>
    <offsetr>
      <x>-1.57</x>
      <y>0</y>
      <z>3.14</z>
    </offsetr>
  </ForceSensor>

The example shows that only a target and offset from the part's center is needed to add a force sensor. The measured force can be published in ROS by adding the following lines inside the rosInterfaces block of your XML:

  <ForceSensorROS>
    <name>ForceG500</name>
    <topic>g500/ForceSensor</topic>
    <rate>100</rate>
  </ForceSensorROS>