Depth Buffer bug fix

[tomlarkworthy]

Depth buffer wasn;t working, changed depth texture encoding type to make it work as before again

[perezsolerj]

Hi again,

As I was changing some things on VirtualCamera's ROSInterface I made a quick fix to the issue. Now depth cameras publish mono16 (mono32 doesn't exist :-1: ) using the 16 most significant bits so, precision is lower than multibeamrangesensor or widget cameras on UWSim, but now you can process images with common software. Anyway it's better than old mono8 precision.

Please check if it's OK and i will close the issue.

[tomlarkworthy]

ok I am doing other things right now. I'll test it out in a month or so. Thanks for the joint updates though.

On Fri, Jul 12, 2013 at 10:53 AM, Javier Perez notifications@github.comwrote:

Hi again,

As I was changing some things on VirtualCamera's ROSInterface I made a quick fix to the issue. Now depth cameras publish mono16 (mono32 doesn't exist [image: :-1:] ) using the 16 most significant bits so, precision is lower than multibeamrangesensor or widget cameras on UWSim, but now you can process images with common software. Anyway it's better than old mono8 precision.

Please check if it's OK and i will close the issue.

— Reply to this email directly or view it on GitHubhttps://github.com/uji-ros-pkg/underwater_simulation/pull/6#issuecomment-20867917 .

Post Doctoral Research Associate at Heriot-Watt Ocean Systems Lab PANDORA: persistenly autonomous AUVs, http://persistentautonomy.com/ Share periodic tasks with ease using http://www.quickrota.com

Member of Edinburgh Hacklab, http://edinburghhacklab.com

[tut-yury]

I recently tried to use the depth image publishing code and it is, actually, broken. You publish "mono16" encoding, but using most significant bits of "float" to write "unsigned short", while still leaving "pixel" size as 4 bytes. If you want, I can fix it to be in accordance with REP 118, the only question is which representation we want to use - 4-byte float in metres (32FC1) or 2-byte short in mm (mono16). I think canonical 32FC1 is better and more versatile, but we can also put this option into XML, as to what encoding to use... This will also make it trivial to copy data from depth buffer to ROS message...

[perezsolerj]

Well, I don't have any preferences as I usually don't use this interface. So 32FC1 is ok for me. Maybe @tomlarkworthy who uses it more, as far as I know, wants to say something about this.

[tomlarkworthy]

In the end it was more of a problem that it solved and we added a wrapper to the normal camera to get the kind of info we needed. People had to reinstall UWSim to use my fork, and we had a divergent set of higher level functionality. Last we check the depth buffer didn't seem to work on default UWSim but we now changed our code work on blue on black vanilla virtual cameras anyways.

The depth buffer does not work as well as expected anyway because the sea counts as a thing. So when a depth camera is underwater everything has range 0. You have to remove the sea from around the AUV which is not great.

Tom

On Thu, Dec 12, 2013 at 11:49 AM, Javier Perez notifications@github.comwrote:

Well, I don't have any preferences as I usually don't use this interface. So 32FC1 is ok for me. Maybe @tomlarkworthyhttps://github.com/tomlarkworthywho uses it more, as far as I know, wants to say something about this.

— Reply to this email directly or view it on GitHubhttps://github.com/uji-ros-pkg/underwater_simulation/pull/6#issuecomment-30412116 .

Post Doctoral Research Associate at Heriot-Watt Ocean Systems Lab PANDORA: persistenly autonomous AUVs, http://persistentautonomy.com/ Share periodic tasks with ease using http://www.quickrota.com

Member of Edinburgh Hacklab, http://edinburghhacklab.com

[tut-yury]

Actually, I use depth camera in my sensors (through SimulatedDevice-based plugin) and it works great, except for the ocean surface, yes. I also have plugin-based ROS interface which converts depth image from z-buffer format into meters and it publishes beatifully... I just offered my help in doing the same in the default ROS intrerface for depth camera... This way it will be possible to correctly visualize the data using RVIZ or any other software that works with depth images...

[perezsolerj]

Yes, as yury says, depth camera works except for the ocean-surface where it detects an obstacle. But RosInterface format publisher is a little bit weird right now as I changed z-buffer resolution, and done a quick fix just to make it work. So updating it to publish in a correct format is a thing TODO, in my opinion. I totally forgot about this...

Right now multibeam has a similar functionality and the published interface is a laserScan in meters. But "pixels" are moved to achieve a constant angle distance between them instead of the camera-like device.

Maybe with the DepthCamera we should do something similar using format 32FC1 or mono16 and publishing real measures instead of z-buffer.

[tut-yury]

Ok, I can do this and it will take maybe 10 minutes from me, but currently I cannot compile the latest version of code because of the recently introduced robot_state_publisher dependency... I can do it as soon as I can compile the latest code...

[marioprats]

@tut-yuri, you should be able to build the code by adding the robot_state_publisher source to your catkin workspace: https://github.com/ros/robot_state_publisher/tree/hydro-devel

We can remove it later when binaries with the fix are released.

On Thu, Dec 12, 2013 at 4:49 AM, tut-yury notifications@github.com wrote:

Ok, I can do this and it will take maybe 10 minutes from me, but currently I cannot compile the latest version of code because of the recently introduced robot_state_publisher dependency... I can do it as soon as I can compile the latest code...

— Reply to this email directly or view it on GitHubhttps://github.com/uji-ros-pkg/underwater_simulation/pull/6#issuecomment-30417842 .

[tut-yury]

I did that, but still get the error on linking:

Linking CXX shared library /home/yury/catkin_ws/devel/lib/libuwsim.so /usr/bin/ld: cannot find -lorocos-kdl

I checked, I have the lib at /opt/ros/hydro/lib/liborocos-kdl.so

[perezsolerj]

Did you pulled last commits?, travis build seems fine now since I added:

link_directories(${orocos_kdl_LIBRARY_DIRS})

as stated here: https://github.com/ros-planning/moveit_ros/issues/376

[tut-yury]

That solved the problem, thanks :) Will create a new PR soon...

[perezsolerj]

I think it was fixed on #30 so I'll close this