Same parts from logical cameras with different, non-overlapping views

[Ross Wightman]

I'm currently looking at the parts poses reported by the logical cameras. I have a workspace config like sample_gear_conf.yaml with the same two logical cameras; one over the parts bins and one over the conveyor.

There is unexpected behaviour from both the rostopic echo output and from the TF frames viewed in RVIZ.

1. Looking at the rostopic echo output for either logical_camera_1 or logical_camera_2 I'm seeing dumps of the same parts even though there should be no overlap in the camera frustum. logical_camera_2 should not see those parts.

2. Looking at the RVIZ display of the TF frames, I usually see all of the parts on the bins tied to logical_camera_1 which is correct as those parts are in that cameras view. However, there is a momentary flash once in a while, and I noticed in that flash, those parts will momentarily appear connected to logical_camera_2 for one RVIZ rendered frame. Additionally, in the text tree on the left, the 'Parent' field briefly flashes from logical_camera_1 to logical_camera_2 at the same instant.

I'm running ROS Kinetic on Ubuntu 16.04.

[Deanna Hood]

Hi @rwightman-hwl, thank you for taking the time to report this.

If you can please tell us the following, it will help with reproducing the behaviour on our side:

• how often this is happening
• your exact workspace config if it is at all different to sample_gear_conf.yaml
• if you have noted any particular conditions which make this more likely to occur

[Ross Wightman]

I noticed issue after things had been running a while. I restarted everything and the problem was still observable immediately.

My config just moved the position of camera 2 slightly. I tried with the original sample_gear_conf and the problem is still happening.

My startup script, using the example config is below

rosrun osrf_gear gear.py -f workspace/src/osrf/ariac_example/config/sample_gear_conf.yaml `catkin_find --share osrf_gear`/config/qual1a.yaml &> output/gazebo.txt &
roslaunch --wait ur10_moveit_config ur10_moveit_planning_execution.launch sim:=true &> output/moveit.txt &
roslaunch --wait ur10_moveit_config moveit_rviz.launch config:=true &> output/rviz-mv.txt &
until rostopic list ; do sleep 1; done
rosrun rviz rviz -d `catkin_find osrf_gear --share`/rviz/ariac.rviz $> output/rviz-tf.txt &

[Deanna Hood]

Thank you for the additional details @rwightman-hwl. So far we have not been able to reproduce it locally but we will keep looking into it and get back to you.

[Ross Wightman]

I've pulled out my environment setup into a separate, public repo. It's Docker based. Feel free to share that setup BTW if it's of use to anyone.

I can reproduce the issue cloning my repository below, building container, and running the launch script in container as spec'd in the README file there. Note, this Dockerfile was setup for running on a Ubuntu 16.04 host with Nvidia hardware. It uses nvidia-docker and maps X from container to host. It may run on other version of Ubuntu running with an Nvidia card and Nvidia drivers.

https://github.com/rwightman/ariac-workspace

Once all is up and running, run 'rostopic echo /ariac/logical_camera_2' and it dumps object data for objects it can't see... you should also see weird one frame glitches in the TF rviz window where objects incorrectly appear under logical_camera_2

[Deanna Hood]

Thanks for sharing your docker-based environment setup, @rwightman-hwl. (Would you be willing to add an open source license to that repo?)

Indeed now I can reproduce the error just as you have described it.

I believe the issue to be caused by the version of gazebo that is being used. Following the Installing Gazebo7 section of the system setup tutorial will get you gazebo 7.5.0, whereas your setup is using gazebo 7.0.0. Upgrading to 7.5 fixes the issue from what I have seen. Could you confirm that you see the same?

The logical camera is a relatively new sensor in gazebo -- we will update the system requirements to clarify that gazebo 7.5 is required and that 7.0 is not sufficient. Thank you again for raising this issue.

[Ross Wightman]

Apache license added to that repo.

I'll update my Docker setup to install Gazebo 7.5 and see if that fixes the issue. Thanks.

[Ross Wightman]

Upgrading to Gazebo 7.5 fixed the issue. My Docker repo was updated with the change.

[Deanna Hood]

Glad to hear that this fixed it on your side too. Thank you for confirming and adding the license. I will mark this issue as resolved.