Is there any way to limit the rate of acquisition. Because I'm having limited computation resources and I thought this could help.

Thanks!

Issue by wkentaro
Friday Jun 17, 2016 at 12:54 GMT
Originally opened as ros-drivers/openni2_launch#32

Currently it seems not-implemented..

Howdy,

I have an ASUS Xtion Pro Live that I want to calibrate and use to guide a robot to perform a process that involves touching surfaces. I need to calibrate this camera and use its intrinsic parameters (e.g focal lengths).

I have noticed that running the calibration process and producing a calibration file in .ros/camera_info will change the published depth camera_info to match the IR image, but the actual depth data itself is not changed. This means that later ROS nodes use a different focal length to project the depth data than is used to create the depth from what I presume is a disparity map from the device.

My question can be posed several ways:

• How do I find the camera intrinsics used to compute the depth data?
• How do I adjust the openni2 nodes so that I can use the same calibrated focal length for both depth calculation and projection into a point cloud?
• How have others dealt with similar situations?

Thanks

Issue by mikeferguson
Saturday Sep 21, 2013 at 04:36 GMT
Originally opened as ros-drivers/openni2_launch#8

need a new release with #6 included

I would like to set the RGB exposure level on startup. I am using ROS Indigo on Ubuntu 14.04 (openni2_camera package built from source). The exposure level cannot be set unless the camera is actively streaming data, see Openni2 issue. However, even if that issue is resolved, setting exposure on start up will still fail (but in a different way).

The driver either ignores the exposure setting or perhaps after it is fixed returns an error. Due to the change detection logic, here, the dynamic reconfigure will not re-set the exposure unless the exposure is specifically changes. As a result there value reflected in dynamic reconfigure does not match the value in the low level driver.

I believe this should mostly be fixed in the low level driver code, but the change detection logic should probably be reworked to avoid similar "hidden" bugs.

This is what I get:

[ INFO] [1370658958.459688665]: Starting depth stream.
[ INFO] [1370658958.894467438]: camera calibration URL: file:///etc/robot/head_rgb.yaml
[ INFO] [1370658961.044891770]: Linear joint limits reset successfully after estop.
[FATAL] [1370658966.531155375]: ASSERTION FAILED
        file = /tmp/buildd/ros-groovy-image-transport-1.10.3-0precise-20130418-2038/src/camera_publisher.cpp
        line = 126
        cond = false
        message = 
[FATAL] [1370658966.531319404]: Call to publish() on an invalid image_transport::CameraPublisher
[FATAL] [1370658966.531372437]: 

[head_camera_nodelet_manager-1] process has died [pid 13453, exit code -5, cmd /opt/ros/groovy/lib/nodelet/nodelet manager __name:=head_camera_nodelet_manager __log:=/home/dgossow/.ros/log/3d0eac6e-cfc2-11e2-bf3f-00e0f426264b/head_camera_nodelet_manager-1.log].
log file: /home/dgossow/.ros/log/3d0eac6e-cfc2-11e2-bf3f-00e0f426264b/head_camera_nodelet_manager-1*.log

I'm wondering if anyone has openni2_camera or openni2_launch working with Kinect?

My understanding is that this would only be possible by using the freenect driver and OpenNI2-Freenect wrapper (https://github.com/piedar/OpenNI2-FreenectDriver), since there is no official OpenNI2-compatible driver for Linux. For OpenNI version 1.5, you could use the avin2 SensorKinect driver (https://github.com/avin2/SensorKinect), but I don't think that works with OpenNI2.

So, I'm running OpenNI2-Freenect, and when I try to roslaunch openni2.launch, I get a bunch of errors about unsupported IR/color/depth modes- I'm guessing because the freenect driver is limited in what modes it supports.

Can anyone clarify the situation for me? Am I right in these assumptions?

Issue by rastaxe
Tuesday Feb 23, 2016 at 08:37 GMT
Originally opened as ros-drivers/openni2_launch#26

I am not able to load a oni file (OpenNI record file) with openni2 in Indigo. In Hydro I was able to load it simply with: roslaunch openni2_launch openni2.launch device_id:=/path/to/your/file.oni
but in Indigo openni2 still tries to open the real device. Do you have the same problem?

When you launch an openni device with this driver, disconnect it from USB and re-connect it, the driver will recognize those events: OpenNI2DeviceManager::onDeviceDisconnected() and OpenNI2DeviceManager::onDeviceConnected() are called. However the OpenNI2Device handle in OpenNI2Driver is not updated. As a consequence, the device will never be re-opened and no images are served.
It would be great if the driver would use the callbacks in OpenNI2DeviceManager to reestablish the connection.

Will the indigo_devel branch work without modification on ROS Kinetic?

It's failing to build on Xenial 64 due to this: http://build.ros.org/view/Kbin_uX64/job/Kbin_uX64__openni2_camera__ubuntu_xenial_amd64__binary/22/console

23:34:17 /usr/lib/ccache/x86_64-linux-gnu-g++   -DROSCONSOLE_BACKEND_LOG4CXX -DROS_PACKAGE_NAME=\"openni2_camera\" -Dopenni2_driver_lib_EXPORTS -I/tmp/binarydeb/ros-kinetic-openni2-camera-0.2.6/obj-x86_64-linux-gnu/devel/include -I/tmp/binarydeb/ros-kinetic-openni2-camera-0.2.6/include -I/opt/ros/kinetic/include -I/usr/include/openni2  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2  -fPIC   -o CMakeFiles/openni2_driver_lib.dir/src/openni2_driver.cpp.o -c /tmp/binarydeb/ros-kinetic-openni2-camera-0.2.6/src/openni2_driver.cpp
23:34:21 In file included from /tmp/binarydeb/ros-kinetic-openni2-camera-0.2.6/src/openni2_driver.cpp:32:0:
23:34:21 /tmp/binarydeb/ros-kinetic-openni2-camera-0.2.6/include/openni2_camera/openni2_driver.h:54:38: fatal error: openni2_camera/GetSerial.h: No such file or directory
23:34:21 compilation terminated.

I believe this line needs the additional dependency ${PROJECT_NAME}_generate_messages_cpp

Surprisingly this is the only platform where it is failing due to this race condition.

If I

 <include file="$(find openni2_launch)/launch/openni2.launch">
 <arg name="rgb_camera_info_url"
      value="file:///home/mlampre/.ros/camera_info/rgb_PS1080_PrimeSense.yaml" />
 <arg name="depth_camera_info_url"
      value="file:///home/mlampre/.ros/camera_info/depth_PS1080_PrimeSense.yaml" />
</include>

and have seperate .yaml files openni2 publishes the exact same messages on these topics:
camera/rgb/camera_info
camera/depth/camera_info

Issue by liborw
Monday Sep 02, 2013 at 08:08 GMT
Originally opened as ros-drivers/openni2_launch#3

This pull request will enable to launch openni2 driver on different machine.

liborw included the following code: https://github.com/ros-drivers/openni2_launch/pull/3/commits

Looks like version 0.2.3 has been bloom'ed but no PR was made to rosdistro (indigo rosdistro still has version 0.2.2). @mikeferguson was that intentional?

Issue by filipetrocadoferreira
Monday Apr 18, 2016 at 11:33 GMT
Originally opened as ros-drivers/openni2_launch#28

Is there any way to limit of acquisition rate? I'm having computational resources limits and i believe if I limit the acquisition of the cameras (in my case 3) I won't have the CPU so busy.

Reported in this thread.

Technically we could implement a logic to check the the driver's compatibility by looking at manufacturor's device id (Then we need to address the concern at #80 (comment)).

The default device in openni2_launch/launch/openni2.launch is #1 which does not work (at least for the Asus Xtion Pro). Passing the device ID as it was listed by the driver on startup (e.g. 1d27/0600@1/3) works though.

[ INFO] [1369867499.843871696]: Device "1d27/0600@1/3" connected

process[camera/depth/rectify_depth_raw-8]: started with pid [20032]
[ INFO] [1369867499.853492240]: No matching device found.... waiting for devices. Reason: openni2_wrapper::OpenNI2Device::OpenNI2Device(const
 string&) @ /home/swirth/catkin_ws/src/openni2_camera/src/openni2_device.cpp @ 74 : Initialize failed
        DeviceOpen: Couldn't open device '#1'

Could someone release the latest version for indigo-devel?

Hello,
It may exist but I couldn't find a way to change the xyz rpy of each tf relatively to the main link.
I'd like to change them to fit my Asus Xtion Pro, and in order for the RGB to better match the point cloud.

Is there a way to do that ?
Thanks!

Particularly it's requested here for Kinetic.

I'm taking care of this.

When starting two instances of the driver together (e.g. from the same launch file) and both try to access all openni2 devices to request their serial number, one (or both) can (silently) fail. This makes resolving the device URI by serial number impossible (serial numbers for devices that could not be opened on startup are empty).

A possible solution might be to retry reading the serial numbers instead of doing it only once on startup.

Currently blocked by #10

This is what I get:

[ INFO] [1370658765.712107712]: Starting depth stream.
[ INFO] [1370658766.140377589]: camera calibration URL: file:///etc/robot/head_rgb.yaml
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
what():  boost::lock_error
[head_camera_nodelet_manager-1] process has died [pid 11484, exit code -6, cmd /opt/ros/groovy/lib/nodelet/nodelet manager __name:=head_camera_nodelet_manager __log:=/home/dgossow/.ros/log/3d0eac6e-cfc2-11e2-bf3f-00e0f426264b/head_camera_nodelet_manager-1.log].
log file: /home/dgossow/.ros/log/3d0eac6e-cfc2-11e2-bf3f-00e0f426264b/head_camera_nodelet_manager-1*.log

Issue by 130s
Thursday Aug 31, 2017 at 19:02 GMT
Originally opened as ros-drivers/openni2_launch#38

I need to confirm by myself but I have a feeling as per subject, e.g. with an input device_id:=5@1, only "5" is taken as the bus number and "1" is ignored.

Issue by mikeferguson
Thursday Sep 05, 2013 at 03:15 GMT
Originally opened as ros-drivers/openni2_launch#4

Should not be merged until this is merged: ros-drivers/rgbd_launch#1

mikeferguson included the following code: https://github.com/ros-drivers/openni2_launch/pull/4/commits

Hi,

In OpenNI2.cfg, shouldn't it be

gen.add("ir_mode", int_t, 0, "Video mode for IR camera", 5, 1, 12, edit_method = output_mode_enum)

instead of

gen.add("ir_mode", int_t, 0, "Video mode for IR camera", 1, 5, 12, edit_method = output_mode_enum)

because the order of the values is default, min, max?

I am using the OpenNi2 Camera under Ubuntu 14.04 on RPI2.

Just figured out that the OpenNi2 Camera works reasonable well there but is unable to activate the RGB Camera.
Depth camera works ok.

Issue by bit-pirate
Monday Sep 16, 2013 at 07:28 GMT
Originally opened as ros-drivers/openni2_launch#7

I just switched the default for one of the robots here from openni1 to 2 and I noticed that openni2_launch does not support a parameter for choosing hardware depth registration aka depth_registration.

Is there a specific reason why this is missing? I see that this parameter is available through dynamic reconfigure and it is turned on by default.

Issue by hershwg
Tuesday Jul 23, 2013 at 19:06 GMT
Originally opened as ros-drivers/openni2_launch#1

The hydro version of "tf" no longer supports having a leading slash "/" in tf frames. There is some backwards compatibility but it is not universal. Removing these leading slashes made things work better for me in Hydro.

hershwg included the following code: https://github.com/ros-drivers/openni2_launch/pull/1/commits

Issue by mikeferguson
Sunday Sep 01, 2013 at 05:40 GMT
Originally opened as ros-drivers/openni2_launch#2

There's still a need for an openni2_launch package, but it should just be a thin wrapper around rgbd_launch, much like what @piyushk did for the openni_launch package: https://github.com/ros-drivers/openni_launch/blob/hydro-devel/launch/openni.launch

Issue by bit-pirate
Monday Sep 16, 2013 at 07:26 GMT
Originally opened as ros-drivers/openni2_launch#6

This is similar to ros-drivers/openni_launch#2

Is there a specific reason why this hasn't been adopted for openni2_launch or has this just been missed?

bit-pirate included the following code: https://github.com/ros-drivers/openni2_launch/pull/6/commits

Howdy openni2_camera maintainers!

It would be really awesome to have a Lunar release of this very widely used package.
Thanks!

Running on the ODROID XU3 14.04 I can view
/camera/depth/points but when I enable /camera/rgb/image_raw the point cloud data stops streaming.

There are no errors or warnings present.

I should also mention I've tried with the apt pre-compiled binaries as well as compiling OpenNI2 and openni2_camera from source.

This also prevents registered depth points from working.

Example of problem: https://www.youtube.com/watch?v=uwS2gWFywPk

When trying to catkin_make openni2_camera on ROS Indigo / OS X 10. 10.10.2, I get the following error:

/Users/tatsch/ros_catkin_ws/src/openni2_camera/src/usb_reset.c:40:10: fatal error: 'linux/usbdevice_fs.h' file not found
#include <linux/usbdevice_fs.h>
         ^

because that header file is not available under OS X.

As a workaround I replaced the include with

define USBDEVFS_RESET _IO('U', 20)

which seems to work. How can this be done properly?

Will this driver work with the structure.io sensor (which also uses OpenNI2)? I'm currently using https://github.com/fangchangma/openni2_ros_wrapper , but would love to get the additional color and raw depth sensor messages that this driver offers...

Issue by pirobot
Friday Jan 23, 2015 at 15:43 GMT
Originally opened as ros-drivers/openni2_launch#22

When using an Asus Xtion Pro and the latest Indigio Debian packages under Ubuntu 14.04, after running

$ roslaunch openni2_launch openni2.launch

there is no disparity data on the topic /camera/depth/disparity as expected.

Even when explicitly setting the disparity_processing argument to true:

$ roslaunch openni2_launch openni2.launch disparity_processing:=true

there is no data on the topic /camera/depth/disparity as expected.

Issue by ljklonepiece
Tuesday May 24, 2016 at 01:00 GMT
Originally opened as ros-drivers/openni2_launch#31

I am using openni2_launch for Xtion Pro Live camera.
I want to obtain high-resolution rgb images (SXGA).
after launch the camera, it is able to stream VGA (30hz) images (/camera/rgb/image_raw) smoothly, but after (using rqt_reconfigure) changing the color mode from VGA_30Hz to SXGA_30Hz, it is unable to stream the /camera/rgb/image_raw.

Anyone encountered the same problem previously? How shall I resolve this?
Thank you so much!

If the given device ID cannot be resolved through the number (#1) or the device at bus 3@1 scheme, the device ID is treated as serial number. If that lookup fails, the last option is to find a string match of the device ID in any device URI. If that match fails, an empty string is returned here: https://github.com/ros-drivers/openni2_camera/blob/indigo-devel/src/openni2_driver.cpp#L719 which makes the driver open any device: https://github.com/ros-drivers/openni2_camera/blob/indigo-devel/src/openni2_device.cpp#L70

Instead, the driver should fail with an error message that the given device ID could not be resolved.

This isn't actually actionable right now, but keeping logging here for future debugging. On startup I saw:

 [ERROR] [1380501149.547482947]: Unsupported color video mode - Resolution: 640x480@30Hz Format: RGB888

Followed by lots of:

[ERROR] [1380501211.906861555]: Rectified topic '/head_camera/depth/image_rect_raw' requested but camera publishing '/head_camera/depth/camera_info' is uncalibrated
[ WARN] [1380501171.307709212]: [image_transport] Topics '/head_camera/depth/image_rect_raw' and '/head_camera/depth/camera_info' do not appear to be synchronized. In the last 10s:
    Image messages received:      0
    CameraInfo messages received: 150
    Synchronized pairs:           0

We never reconnected, but restarting my launch file worked. We should probably retry when configuration fails.

While testing the new Asus Xtion 2 (which is a great unit btw, anybody who wants more information is welcome to ask) I found out that it features a close range mode.
I can toggle it in the newest version of the NiViewer and the important part of the code can be found here:
https://github.com/OpenNI/OpenNI2/blob/115cf06c6efea32304182d293eca16ca883c9150/Source/Tools/NiViewer/Device.cpp#L365

It would be great to have the functionality to set this property in ROS.

There are two reasons for this:
First thing is that in close range mode it is possible to see objects down to a distance between approx. 10 to 25 cm depending on the color and surface.
This is a huge benefit for navigation in narrow environments.
Whereas the second point is crucial for some applications:
The Xtion 2 is based on TOF and not Structured Light. This introduces the problem with non explicit distance values.
Today I did some testing and in normal mode at a distance of approx. 11 meters the objects (a white wall in my case) led to points directly in front of the camera.
The close range mode dims the emitter so that when it is activated instead of getting wrong values I get no distance values from objects with a distance greater than 11 meters. Which surely is the better deal.

Hi everyone.

I am building openni2_camera (indigo-devel branch) from source. Grabbing images was working two months ago. However, today I rebuilt the system and I got the following error message when firing up the grabber:

[ INFO] [1516105619.826425870]: No matching device found.... waiting for devices. Reason: std::__cxx11::string openni2_wrapper::OpenNI2Driver::resolveDeviceURI(const string&) @ /home/nao/workspace/ros-openni2-camera-indigo-devel-ci-deploy-pepper-head-robocup-nightly/src/openni2_driver.cpp @ 737 : Invalid device number 1, there are 0 devices connected.

I confirmed that the camera is working though. Are there any known regressions?

Also, the list_devices executable does not find any...

Now I'm using primesense sensors and it only works on libopenni2 2.2.
I'd like to use it on hydro, so could you upgrade the version of libopenni2?
(I don't know this repository is the correct one to request this issue)

For the openni_camera I was able to change the output for depth stream to shift values by changing the configuration file at /etc/openni/GlobalDefaults.ini. For the openni2 there is a /etc/openni2/PS1080.ini which looks very similar. But uncommenting the OutputFormat=102 doesn't have any effect.

Is there other way how to switch the driver to shift values?

Issue by bit-pirate
Monday Sep 23, 2013 at 02:59 GMT
Originally opened as ros-drivers/openni2_launch#9

When I deactivated depth registration via rqt_reconfigure, I get the following error:

[ERROR] [1379904975.770528069]: Depth image frame id [sensor_3d_depth_optical_frame] doesn't match RGB image frame id [sensor_3d_rgb_optical_frame]

Can anyone confirm this? What's different to the old version (openni1)?

I want to use openni2 with Kinetic as mention here
https://github.com/ros-gbp/openni2_launch#openni2_launch-kinetic---022-0

Any help is appreciated

I am getting the following output
[ INFO] [1530543321.228722086]: No matching device found.... waiting for devices. Reason: std::__cxx11::string openni2_wrapper::OpenNI2Driver::resolveDeviceURI(const string&) @ /home/abdu/catkin_ws/src/openni2_camera/openni2_camera/src/openni2_driver.cpp @ 737 : Invalid device number 1, there are 0 devices connected.

I wonder if it might be possible to expose some of the openni2 emitter properties through ROS in some way? In particular, it would be nice to be able to turn the emitter on and off using a service call which wraps

Device.setProperty(XN_MODULE_PROPERTY_EMITTER_STATE,(XnUInt64)(TRUE/FALSE));

I was just wondering if it made much sense considering most of the other properties of this kind are set using the ini file -- but apparently since openni2, they have been made directly accessible.

Would it be possible to release the last tag for hydro? (Please :P)

Issue by bit-pirate
Monday Sep 23, 2013 at 02:59 GMT
Originally opened as ros-drivers/openni2_launch#9

When I deactivated depth registration via rqt_reconfigure, I get the following error:

[ERROR] [1379904975.770528069]: Depth image frame id [sensor_3d_depth_optical_frame] doesn't match RGB image frame id [sensor_3d_rgb_optical_frame]

Can anyone confirm this? What's different to the old version (openni1)?

Issue by bit-pirate
Tuesday Sep 10, 2013 at 09:47 GMT
Originally opened as ros-drivers/openni2_launch#5

Is there any show stopper we know of?

To replicate, download the sources, then do a

catkin_make install
. install/setup.bash
rosrun openni2_camera openni2_camera_node

The output is:

terminate called after throwing an instance of 'openni2_wrapper::OpenNI2Exception'
  what():  openni2_wrapper::OpenNI2DeviceManager::OpenNI2DeviceManager() @ /wg/stor5/jbinney/ws/openni2_camera/src/openni2_camera/src/openni
2_device_manager.cpp @ 185 : Initialize failed
        LibraryHandler: Couldn't load library libDummyDevice.so.0
        DeviceDriver: library handle is invalid for file libDummyDevice.so.0
        Couldn't understand file 'libDummyDevice.so.0' as a device driver
        LibraryHandler: Couldn't load library libOniFile.so.0
        DeviceDriver: library handle is invalid for file libOniFile.so.0
        Couldn't understand file 'libOniFile.so.0' as a device driver
        LibraryHandler: Couldn't load library libPS1080.so.0
        DeviceDriver: library handle is invalid for file libPS1080.so.0
        Couldn't understand file 'libPS1080.so.0' as a device driver
        Found no valid drivers in '/usr/lib/OpenNI2/Drivers'

This appears to be because the libopenni2-0 library puts the libraries for each device driver in /usr/lib/OpenNI2/Drivers, but doesn't add that to the library search path in /etc/ld.so.conf. This doesn't fail in devel space because we get the library path for OpenNI2 from package config:

jbinney@jbk-> pkg-config --libs libopenni2
-L/usr/lib/OpenNI2/Drivers -lOpenNI2 -lDummyDevice -lOniFile -lPS1080.so

Possible solution would be to have libopenni2-0 install a file into /etc/ld.so.conf.d/ to add /usr/lib/OpenNI2/Drivers to the library search path, so this is probably actually a bug with that library and not with openni2_camera. But I'm leaving this here because it is blocking the release of this package.