ros-drivers / camera1394 Goto Github PK

Specifically the work by @miquelmassot, here:

https://github.com/srv/camera1394stereo

I'm not sure how much the two packages have diverged at this point, but it would be great to have robust stereo support in the base driver and released, rather than in a fork.

Dear Jack,

Im Claudio, pretty new user of ROS anyway I really cant install your package even if I try it in every way. I`m developing a SLAM framework with a Firewire Camera and I really need your support. Though I got all the dependencies and I compiled the driver, any executable file is produced.

I follow your instructions:

1. clone the source;
2. rosdep install camera1934 (#All required rosdeps installed successfully)
3. rosmake camera1394

and that`s the output:

[ rosmake ] rosmake starting...
[ rosmake ] Packages requested are: ['camera1394']
[ rosmake ] Logging to directory /home/claudios/.ros/rosmake/rosmake_output-20130405-184012
[ rosmake ] Expanded args ['camera1394'] to:
['camera1394']
[rosmake-0] Starting >>> catkin [ make ]
[rosmake-0] Finished <<< catkin ROS_NOBUILD in package catkin
No Makefile in package catkin
[rosmake-0] Starting >>> genmsg [ make ]
[rosmake-1] Starting >>> cpp_common [ make ]
[rosmake-0] Finished <<< genmsg ROS_NOBUILD in package genmsg
No Makefile in package genmsg
[rosmake-0] Starting >>> genpy [ make ]
[rosmake-1] Finished <<< cpp_common ROS_NOBUILD in package cpp_common
No Makefile in package cpp_common
[rosmake-1] Starting >>> rostime [ make ]
[rosmake-0] Finished <<< genpy ROS_NOBUILD in package genpy
No Makefile in package genpy
[rosmake-0] Starting >>> genlisp [ make ]
[rosmake-0] Finished <<< genlisp ROS_NOBUILD in package genlisp
No Makefile in package genlisp
[rosmake-0] Starting >>> gencpp [ make ]
[rosmake-0] Finished <<< gencpp ROS_NOBUILD in package gencpp
No Makefile in package gencpp
[rosmake-0] Starting >>> message_generation [ make ]
[rosmake-0] Finished <<< message_generation ROS_NOBUILD in package message_generation
No Makefile in package message_generation
[rosmake-1] Finished <<< rostime ROS_NOBUILD in package rostime
No Makefile in package rostime
[rosmake-1] Starting >>> roscpp_traits [ make ]
[rosmake-1] Finished <<< roscpp_traits ROS_NOBUILD in package roscpp_traits
No Makefile in package roscpp_traits
[rosmake-1] Starting >>> roscpp_serialization [ make ]
[rosmake-1] Finished <<< roscpp_serialization ROS_NOBUILD in package roscpp_serialization
No Makefile in package roscpp_serialization
[rosmake-1] Starting >>> message_runtime [ make ]
[rosmake-1] Finished <<< message_runtime ROS_NOBUILD in package message_runtime
No Makefile in package message_runtime
[rosmake-0] Starting >>> rospack [ make ]
[rosmake-1] Starting >>> std_msgs [ make ]
[rosmake-0] Finished <<< rospack ROS_NOBUILD in package rospack
No Makefile in package rospack
[rosmake-0] Starting >>> roslib [ make ]
[rosmake-1] Finished <<< std_msgs ROS_NOBUILD in package std_msgs
No Makefile in package std_msgs
[rosmake-0] Finished <<< roslib ROS_NOBUILD in package roslib
No Makefile in package roslib
[rosmake-0] Starting >>> rosunit [ make ]
[rosmake-0] Finished <<< rosunit ROS_NOBUILD in package rosunit
No Makefile in package rosunit
[rosmake-1] Starting >>> rosgraph_msgs [ make ]
[rosmake-1] Finished <<< rosgraph_msgs ROS_NOBUILD in package rosgraph_msgs
No Makefile in package rosgraph_msgs
[rosmake-1] Starting >>> roslang [ make ]
[rosmake-1] Finished <<< roslang ROS_NOBUILD in package roslang
No Makefile in package roslang
[rosmake-1] Starting >>> xmlrpcpp [ make ]
[rosmake-1] Finished <<< xmlrpcpp ROS_NOBUILD in package xmlrpcpp
No Makefile in package xmlrpcpp
[rosmake-1] Starting >>> rosgraph [ make ]
[rosmake-1] Finished <<< rosgraph ROS_NOBUILD in package rosgraph
No Makefile in package rosgraph
[rosmake-0] Starting >>> rosconsole [ make ]
[rosmake-0] Finished <<< rosconsole ROS_NOBUILD in package rosconsole
No Makefile in package rosconsole
[rosmake-0] Starting >>> roscpp [ make ]
[rosmake-0] Finished <<< roscpp ROS_NOBUILD in package roscpp
No Makefile in package roscpp
[rosmake-0] Starting >>> rosparam [ make ]
[rosmake-0] Finished <<< rosparam ROS_NOBUILD in package rosparam
No Makefile in package rosparam
[rosmake-0] Starting >>> rosmaster [ make ]
[rosmake-0] Finished <<< rosmaster ROS_NOBUILD in package rosmaster
No Makefile in package rosmaster
[rosmake-1] Starting >>> rospy [ make ]
[rosmake-1] Finished <<< rospy ROS_NOBUILD in package rospy
No Makefile in package rospy
[rosmake-1] Starting >>> rosout [ make ]
[rosmake-1] Finished <<< rosout ROS_NOBUILD in package rosout
No Makefile in package rosout
[rosmake-1] Starting >>> rosclean [ make ]
[rosmake-1] Finished <<< rosclean ROS_NOBUILD in package rosclean
No Makefile in package rosclean
[rosmake-1] Starting >>> diagnostic_msgs [ make ]
[rosmake-1] Finished <<< diagnostic_msgs ROS_NOBUILD in package diagnostic_msgs
No Makefile in package diagnostic_msgs
[rosmake-0] Starting >>> roslaunch [ make ]
[rosmake-0] Finished <<< roslaunch ROS_NOBUILD in package roslaunch
No Makefile in package roslaunch
[rosmake-0] Starting >>> rostest [ make ]
[rosmake-0] Finished <<< rostest ROS_NOBUILD in package rostest
No Makefile in package rostest
[rosmake-0] Starting >>> topic_tools [ make ]
[rosmake-1] Starting >>> geometry_msgs [ make ]
[rosmake-0] Finished <<< topic_tools ROS_NOBUILD in package topic_tools
No Makefile in package topic_tools
[rosmake-0] Starting >>> rosbag [ make ]
[rosmake-0] Finished <<< rosbag ROS_NOBUILD in package rosbag
No Makefile in package rosbag
[rosmake-0] Starting >>> rosmsg [ make ]
[rosmake-1] Finished <<< geometry_msgs ROS_NOBUILD in package geometry_msgs
No Makefile in package geometry_msgs
[rosmake-1] Starting >>> diagnostic_updater [ make ]
[rosmake-1] Finished <<< diagnostic_updater ROS_NOBUILD in package diagnostic_updater
No Makefile in package diagnostic_updater
[rosmake-1] Starting >>> self_test [ make ]
[rosmake-1] Finished <<< self_test ROS_NOBUILD in package self_test
No Makefile in package self_test
[rosmake-1] Starting >>> sensor_msgs [ make ]
[rosmake-0] Finished <<< rosmsg ROS_NOBUILD in package rosmsg
No Makefile in package rosmsg
[rosmake-0] Starting >>> rosservice [ make ]
[rosmake-0] Finished <<< rosservice ROS_NOBUILD in package rosservice
No Makefile in package rosservice
[rosmake-0] Starting >>> dynamic_reconfigure [ make ]
[rosmake-0] Finished <<< dynamic_reconfigure ROS_NOBUILD in package dynamic_reconfigure
No Makefile in package dynamic_reconfigure
[rosmake-1] Finished <<< sensor_msgs ROS_NOBUILD in package sensor_msgs
No Makefile in package sensor_msgs
[rosmake-1] Starting >>> message_filters [ make ]
[rosmake-1] Finished <<< message_filters ROS_NOBUILD in package message_filters
No Makefile in package message_filters
[rosmake-1] Starting >>> console_bridge [ make ]
[rosmake-1] Finished <<< console_bridge ROS_NOBUILD in package console_bridge
No Makefile in package console_bridge
[rosmake-1] Starting >>> class_loader [ make ]
[rosmake-1] Finished <<< class_loader ROS_NOBUILD in package class_loader
No Makefile in package class_loader
[rosmake-1] Starting >>> pluginlib [ make ]
[rosmake-1] Finished <<< pluginlib ROS_NOBUILD in package pluginlib
No Makefile in package pluginlib
[rosmake-0] Starting >>> driver_base [ make ]
[rosmake-0] Finished <<< driver_base ROS_NOBUILD in package driver_base
No Makefile in package driver_base
[rosmake-0] Starting >>> camera_calibration_parsers [ make ]
[rosmake-0] Finished <<< camera_calibration_parsers ROS_NOBUILD in package camera_calibration_parsers
No Makefile in package camera_calibration_parsers
[rosmake-0] Starting >>> angles [ make ]
[rosmake-0] Finished <<< angles ROS_NOBUILD in package angles
No Makefile in package angles
[rosmake-0] Starting >>> tf [ make ]
[rosmake-1] Starting >>> image_transport [ make ]
[rosmake-1] Finished <<< image_transport ROS_NOBUILD in package image_transport
No Makefile in package image_transport
[rosmake-1] Starting >>> camera_info_manager [ make ]
[rosmake-1] Finished <<< camera_info_manager ROS_NOBUILD in package camera_info_manager
No Makefile in package camera_info_manager
[rosmake-1] Starting >>> smclib [ make ]
[rosmake-1] Finished <<< smclib ROS_NOBUILD in package smclib
No Makefile in package smclib
[rosmake-1] Starting >>> bond [ make ]
[rosmake-1] Finished <<< bond ROS_NOBUILD in package bond
No Makefile in package bond
[rosmake-0] Finished <<< tf ROS_NOBUILD in package tf
No Makefile in package tf
[rosmake-1] Starting >>> bondcpp [ make ]
[rosmake-1] Finished <<< bondcpp ROS_NOBUILD in package bondcpp
No Makefile in package bondcpp
[rosmake-1] Starting >>> nodelet [ make ]
[rosmake-1] Finished <<< nodelet ROS_NOBUILD in package nodelet
No Makefile in package nodelet
[rosmake-1] Starting >>> camera1394 [ make ]
[rosmake-1] Finished <<< camera1394 ROS_NOBUILD in package camera1394
[ rosmake ] Results:
[ rosmake ] Built 53 packages with 0 failures.

then I start rosrun and that`s the result:

[rosrun] Couldn't find executable named camera1394_node below /home/claudios/ros_workspace/camera1394

then I cant find any executable and obviously I cant run your program, however coriander perfectly works. My camera is a Point Grey Research Firefly MV FFMV-03MTM and Ive already installed the drivers for Ubuntu. I need to use a camera as a node in ROS. I hope is not a trivial question and that you can help me. Ive spent last three days trying to fix it but I don`t understand the problem. I run the ROS groovy version in Ubuntu 12.04.

Hi,
beeing fairly new to ROS, I wanted to know, what would have to be changed in cmakelists.txt to install camera1394_trigger_node, so that roslaunch would find it.

I was able to run my Basler622 cameras with camera1394 and wanted to experiment with softwareTriggering.

My system is running indigo with Ubuntu 14.4.

Any help would be appreciated.

I have an open ROS question using camera1394 and indigo on ubuntu 14.04:
http://answers.ros.org/question/192286/rosrun-cant-find-camera1394_node-or-camera1394_nodelet/

Basically, on a clean install with only the camera1394 source, after a successful seeming catkin_make, I can't rosrun camera1394_node or _nodelet

I'm not sure if it is a ros issue, an ubuntu issue or a user issue..

Look at the output of this command rostopic echo /flea3_stereo/right/image_raw | grep secs

    secs: 36
    nsecs: 858272000
    secs: 36
    nsecs: 858272000
    secs: 36
    nsecs: 858272000
    secs: 36
    nsecs: 858272000
    secs: 36
    nsecs: 858272000
    secs: 36
    nsecs: 858272000
    secs: 36
    nsecs: 858272000
    secs: 36
    nsecs: 858272000
    secs: 36
    nsecs: 858272000

The timestamps do not change.
I am going to dig into this. Any help is appreciated.
Maybe it is something to do with this bug
https://code.ros.org/trac/ros-pkg/ticket/4841

I am opening an issue after having tried really a lot of things which did not work.

The problem is the following (I am working on an NVIDIA TX2, an embedded ARM computer):
I am not able to run the camera node with rosrun camera1394 camera1394_node because it gives me the following error:

nvidia@tegra-ubuntu:~$ rosrun camera1394 camera1394_node
libdc1394 warning: usb: Failed to open device for config ROM
libdc1394 warning: Failed to get config ROM from usb device
[ERROR] [1524225157.307367296]: [camera] device open failed: [Camera1394::open]: No cameras found
libdc1394 warning: usb: Failed to open device for config ROM
libdc1394 warning: Failed to get config ROM from usb device
libdc1394 warning: usb: Failed to open device for config ROM
libdc1394 warning: Failed to get config ROM from usb device

This does not happen if I run the node as a root.

On the internet I found out that maybe this is due to some rules in udev that I need to set. I researched this issue a lot and I arrived at the conclusion that I needed to create (if not already available) the file
/etc/udev/rules.d/10-pointgrey.rules and put in this file the following line:
BUS=="usb", SYSFS{idVendor}=="1e10", SYSFS{idProduct}=="3300", GROUP="plugdev"

where I took the idVendor and idProduct from the lsusb command. Which was giving me the following:
Bus 002 Device 003: ID 1e10:3300 Point Grey Research, Inc.

Also after imposing this rule and rebooting the system nothing changed.

Could you please help me?

Thanks in advance for your time

Good night everyone,

I am trying to use a Flea-Hicol camera with this driver and I am having the following problem:
if I open coriander for the first time usage of the camera everything works and I can get image in this software. If I open the camera driver with the specified set of commands in the tutorial, then the topic stucks (though it detects the camera and opens it). I can't kill it with CTRL+C. Also, I have this warning:
"iso allocation not available in this kernel, using channel 0.".

The machine is running ros-hydro

Any help will be much appreciated! If you need further details, let me know.

Thank you very much,

Pedro

The driver causes nearly 100% CPU usage under some conditions:

• The camera is unplugged while the driver is running
• External triggering is used

Camera : PointGrey FireFly MV
OS : Ubuntu 14.04.02 LTS
ROS version : Indigo

It would be great to be able to have pan control for multi-cameras like
Point Grey Ladybug.
It's really easy to implement as it's already done for a lot of features
(brightness, zoom, etc.), and would avoid to implement it by ourselves on
every new release.

I will do a pull request with my fix for implementing this features.

Will there be a Jade release for this package?

more a proposal for enhancement than an issue...

My camera (ladybug3) has lots of options that are probably unique to it. It would be useful to be able to set some registers to some value whenever the camera is started, and maybe reconfigured. Maybe the rosparam server could contain a list of (reg,val) pairs, and the dynamic reconfigure could allow to set an individual register.

Or would that be too hackish? would there be need for it for some other cameras as well?

Now I am considering writing my own driver for the ladybug, as there are really too many custom stuffs in it that camera1394 does not handle (and too many things that it handles but that I don't need, making the reconfigure gui too large).

I have the following launch file:

<launch>
  <node pkg="nodelet" type="nodelet" name="camera_nodelet_manager" args="manager" output="screen">
    <param name="num_worker_threads" value="20"/>
  </node>

  <node pkg="nodelet" type="nodelet" name="left" args="load camera1394/driver camera_nodelet_manager">
    <param name="guid" value="00b09d0100cd6e9e"/>
    <param name="bayer_pattern" value="rggb"/>
    <param name="bayer_method" value="HQ"/> <!-- esto tiene que ser distinto de "" (por ej "HQ") si quiero rectificar por nodelet -->
    <param name="use_ros_time" value="true"/>
    <param name="reset_on_open" value="true"/>
 </node> 

  <!--<node pkg="nodelet" type="nodelet" name="left_debayer" args="load image_proc/debayer /camera_nodelet_manager">
    <remap from="image_raw" to="camera/image_raw"/>
    <remap from="image_color" to="camera/image_color"/>
    <remap from="image_mono" to="camera/image_mono"/>
  </node> -->


  <node pkg="nodelet" type="nodelet" name="left_rectify" args="load image_proc/rectify /camera_nodelet_manager">
    <remap from="image_mono" to="camera/image_raw"/> <!-- remapear image_mono a image_raw, en caso de que el driver este haciendo el debayer solo -->
    <remap from="camera_info" to="camera/camera_info"/>
    <remap from="image_rect" to="camera/image_rect"/>
    <param name="queue_size" value="50"/>
  </node>



</launch>

And, when doing CTRL+C, sometimes I get:

process[left-2]: started with pid [9082]
process[left_rectify-3]: started with pid [9114]
[ WARN] [1404829063.551903876]: Comparing 00b09d0100cd6e9e to 00b09d0100cd6e9e
[ INFO] [1404829063.568476815]: Found camera with GUID 00b09d0100cd6e9e
[ INFO] [1404829063.568623447]: camera model: Point Grey Research Firefly MV FMVU-03MTC
[ WARN] [1404829063.586293968]: [HQ] Bayer decoding in the driver is DEPRECATED; image_proc decoding preferred.
[ INFO] [1404829063.591556576]: [00b09d0100cd6e9e] opened: 640x480_mono8, 30 fps, 400 Mb/s
[ INFO] [1404829063.627000717]: [00b09d0100cd6e9e] has trigger support
[ERROR] [1404829063.628724634]: Unknown trigger source: source_0
[ERROR] [1404829063.629587108]: [00b09d0100cd6e9e] feature initialization failure
[ INFO] [1404829063.629676503]: [00b09d0100cd6e9e] closing device
[ WARN] [1404829063.811004478]: Comparing 00b09d0100cd6e9e to 00b09d0100cd6e9e
[ INFO] [1404829063.828208301]: Found camera with GUID 00b09d0100cd6e9e
[ INFO] [1404829063.828267154]: camera model: Point Grey Research Firefly MV FMVU-03MTC
[ WARN] [1404829063.844065052]: [HQ] Bayer decoding in the driver is DEPRECATED; image_proc decoding preferred.
[ INFO] [1404829063.848904539]: [00b09d0100cd6e9e] opened: 640x480_mono8, 30 fps, 400 Mb/s
[ INFO] [1404829063.889797976]: using default calibration URL
[ INFO] [1404829063.890063598]: camera calibration URL: file:///home/v01d/.ros/camera_info/00b09d0100cd6e9e.yaml
^C[left_rectify-3] killing on exit
[left-2] killing on exit
[camera_nodelet_manager-1] killing on exit
*** Error in `/opt/ros/hydro/lib/nodelet/nodelet': corrupted double-linked list: 0x00007f2394006010 ***
======= Backtrace: =========
/usr/lib/libc.so.6(+0x73f8e)[0x7f23c5e67f8e]
/usr/lib/libc.so.6(+0x7988e)[0x7f23c5e6d88e]
/usr/lib/libc.so.6(+0x79b5a)[0x7f23c5e6db5a]
/usr/lib/libc.so.6(+0x7a6a8)[0x7f23c5e6e6a8]
/usr/lib/libdc1394.so.22(dc1394_usb_capture_stop+0xf3)[0x7f239fdaa603]
/home/v01d/coding/ros/devel/lib//libcamera1394_nodelet.so(_ZN10camera139410Camera13945closeEv+0x47)[0x7f23a5580dbd]
/home/v01d/coding/ros/devel/lib//libcamera1394_nodelet.so(_ZN17camera1394_driver16Camera1394Driver11closeCameraEv+0x1c0)[0x7f23a5537ce8]
/home/v01d/coding/ros/devel/lib//libcamera1394_nodelet.so(_ZN17camera1394_driver16Camera1394Driver8shutdownEv+0x18)[0x7f23a553a00a]
/home/v01d/coding/ros/devel/lib//libcamera1394_nodelet.so(_ZN17Camera1394NodeletD1Ev+0x365)[0x7f23a55316b1]
/home/v01d/coding/ros/devel/lib//libcamera1394_nodelet.so(_ZN17Camera1394NodeletD0Ev+0x18)[0x7f23a55317ea]
/opt/ros/hydro/lib/libnodeletlib.so(_ZN12class_loader11ClassLoader16onPluginDeletionIN7nodelet7NodeletEEEvPT_+0x51)[0x7f23c79025a1]
/opt/ros/hydro/lib/nodelet/nodelet(_ZN5boost6detail12shared_countD1Ev+0x39)[0x406889]
/opt/ros/hydro/lib/libnodeletlib.so(_ZN5boost20ptr_container_detail24reversible_ptr_containerINS0_10map_configIN7nodelet14ManagedNodeletESt3mapISsPvSt4lessISsESaISt4pairIKSsS6_EEELb1EEENS_20heap_clone_allocatorEED2Ev+0x4b)[0x7f23c7902f7b]
/opt/ros/hydro/lib/libnodeletlib.so(_ZN7nodelet6LoaderD1Ev+0x19)[0x7f23c78fbf09]
/opt/ros/hydro/lib/nodelet/nodelet(main+0x17b)[0x404ddb]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7f23c5e14000]
/opt/ros/hydro/lib/nodelet/nodelet[0x4060f4]

Just spotted a question on libdc1394 FAQ:

How can I find out if a frame was dropped from not calling dc1394_capture_dequeue() frequently enough?

After each DMA capture function call, you can check the value returned in the frames_behind member of the dc1394frame_t structure. If frames_behind is equal to the ring buffer size minus one then you may have dropped frames.

If you have reason to believe that frames are transmitted regularly (for example on an external trigger signal) then you could also check the filltime member returned in dc1394frame_t for any irregularities in the time series.

Frames can be dropped when dealing with a high frame rate camera on a slow system. So, implementing this in Camera1394::readData() can be a good diagnostics feature.

To test it on our current hardware we may need to throttle down the read loop.

@jack-oquin, what do you think?

Also, Am I right in thinking that NUM_DMA_BUFFERS is the size of the ring buffer mentioned above?

This is needed for other packages to find the nodelet.

I suppose the unit tests were only working because that file is present in the source tree.

Groovy build farm is complaining of missing dependency.

Carried over from code.ros.org Trac ticket #5494 reported by efernandez:

It seems that some IEEE1394 cameras have raw8 Bayer pattern formats/modes, but that just say to have mono8.

In ROS, when images are mono8 it's not possible to use the debayering capability of the image pipeline.

IMHO, one solution (or workaround) consists on forcing debayering for mono8.

Below are some links decribing the problem in more detail:

http://answers.ros.org/question/37862/force-raw8-for-debayering/

-- Enrique

It's a Basler A102fc camera.

Carried forward from code.ros.org Trac ticket #5574 reported by bgoldfai:

A camera1394 node or nodelet will segfault when a subscriber subscribes to its theora topic.

More detailed information of the problem is at http://answers.ros.org/question/47078/camera1394-node-and-nodelet-crash-with-theora-subscriber/

Attached is the output from running the camera1394 node with gdb and the backtrace after the crash:

1      $ roslaunch auto_rally firewireCamera.launch
2   ... logging to /home/muri/.ros/log/2c1e42c2-2296-11e2-b7c1-f0def19baa7e/roslaunch-muri-laptop-10339.log
3   Checking log directory for disk usage. This may take awhile.
4   Press Ctrl-C to interrupt
5   Done checking log file disk usage. Usage is <1GB.
6   
7   started roslaunch server http://muri-laptop:51256/
8   
9   SUMMARY
10  ========
11  
12  PARAMETERS
13   * /rosdistro
14   * /rosversion
15  
16  NODES
17    /
18      cam1394 (camera1394/camera1394_node)
19  
20  ROS_MASTER_URI=http://localhost:11311
21  
22  core service [/rosout] found
23  Exception AttributeError: AttributeError("'_DummyThread' object has no attribute '_Thread__block'",) in <module 'threading' from '/usr/lib/python2.7/threading.pyc'> ignored
24  process[cam1394-1]: started with pid [10359]
25  GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
26  Copyright (C) 2012 Free Software Foundation, Inc.
27  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
28  This is free software: you are free to change and redistribute it.
29  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
30  and "show warranty" for details.
31  This GDB was configured as "x86_64-linux-gnu".
32  For bug reporting instructions, please see:
33  <http://bugs.launchpad.net/gdb-linaro/>...
34  Reading symbols from /opt/ros/fuerte/stacks/camera1394/bin/camera1394_node...done.
35  Starting program: /opt/ros/fuerte/stacks/camera1394/bin/camera1394_node _video_mode:=640x480_mono8 _frame_rate:=60 __name:=cam1394 __log:=/home/muri/.ros/log/2c1e42c2-2296-11e2-b7c1-f0def19baa7e/cam1394-1.log
36  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
37  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
38  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
39  [Thread debugging using libthread_db enabled]
40  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
41  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
42  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
43  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
44  [New Thread 0x7fffefee5700 (LWP 10367)]
45  [New Thread 0x7fffef6e4700 (LWP 10368)]
46  [New Thread 0x7fffe7fff700 (LWP 10369)]
47  [New Thread 0x7fffeeee3700 (LWP 10374)]
48  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
49  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
50  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
51  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
52  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
53  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
54  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
55  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
56  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
57  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
58  [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
59  [ INFO] [1351622182.724361812]: Found camera with GUID 00b09d0100aa4b0e
60  [ INFO] [1351622182.724428979]: No GUID specified, using first camera found, GUID: 00b09d0100aa4b0e
61  [ INFO] [1351622182.724456180]: camera model: Point Grey Research Grasshopper Express GX-FW-10K3M
62  [ INFO] [1351622182.726189872]: [00b09d0100aa4b0e] opened: 640x480_mono8, 60 fps, 400 Mb/s
63  [ INFO] [1351622182.910750957]: using default calibration URL
64  [ INFO] [1351622182.910936726]: camera calibration URL: file:///home/muri/.ros/camera_info/00b09d0100aa4b0e.yaml
65  [ERROR] [1351622182.911223813]: Unable to open camera calibration file [/home/muri/.ros/camera_info/00b09d0100aa4b0e.yaml]
66  [ WARN] [1351622182.911392669]: Camera calibration file /home/muri/.ros/camera_info/00b09d0100aa4b0e.yaml not found.
67  [ WARN] [1351622182.911524434]: [00b09d0100aa4b0e] calibration does not match video mode (publishing uncalibrated data)
68  [ERROR] [1351622202.883356827]: Unable to convert from 'mono8' to bgr8
69  
70  Program received signal SIGSEGV, Segmentation fault.
71  0x000000000042645d in atomic_exchange_and_add (dv=-1, pw=0x78) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:50
72  50          );
73  (gdb) bt
74  #0  0x000000000042645d in atomic_exchange_and_add (dv=-1, pw=0x78) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:50
75  #1  release (this=0x70) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:143
76  #2  boost::detail::shared_count::~shared_count (this=0x731e40, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:217
77  #3  0x000000000042e400 in ~shared_ptr (this=0x731e38, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/shared_ptr.hpp:168
78  #4  ~Image_ (this=0x731de0, __in_chrg=<optimized out>) at /opt/ros/fuerte/include/sensor_msgs/Image.h:56
79  #5  checked_delete<sensor_msgs::Image_<std::allocator<void> > > (x=0x731de0) at /usr/include/boost/checked_delete.hpp:34
80  #6  boost::detail::sp_counted_impl_p<sensor_msgs::Image_<std::allocator<void> > >::dispose (this=<optimized out>)
81      at /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78
82  #7  0x0000000000426489 in release (this=0x72aa30) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:145
83  #8  boost::detail::shared_count::~shared_count (this=<optimized out>, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:217
84  #9  0x0000000000429eb7 in ~shared_ptr (this=0x7fffffffc840, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/shared_ptr.hpp:168
85  #10 camera1394_driver::Camera1394Driver::poll (this=0x7fffffffcc30)
86      at /tmp/buildd/ros-fuerte-camera1394-1.8.0/debian/ros-fuerte-camera1394/opt/ros/fuerte/stacks/camera1394/src/nodes/driver1394.cpp:205
87  #11 0x000000000042477d in main (argc=1, argv=0x7fffffffdf28)
88      at /tmp/buildd/ros-fuerte-camera1394-1.8.0/debian/ros-fuerte-camera1394/opt/ros/fuerte/stacks/camera1394/src/nodes/camera1394_node.cpp:71
89  

I tested the new trigger feature (#9) running the unit tests on an inexpensive Unibrain Fire-i, which does not support triggering. The test ran successfully, the error log output needs to be toned down:

$ make run_tests_camera1394
-- run_tests.py: execute commands
  /opt/ros/hydro/bin/rostest --pkgdir=/home/joq/ros/wet/hydro/src/camera1394 --package=camera1394 --results-filename tests_camera_node_hz.xml /home/joq/ros/wet/hydro/src/camera1394/tests/camera_node_hz.test 
... logging to /home/joq/.ros/log/rostest-vision-4-28424.log
[ROSUNIT] Outputting test results to /home/joq/ros/wet/hydro/build/test_results/camera1394/rostest-tests_camera_node_hz.xml
libdc1394 error: Generic failure: in dc1394_external_trigger_get_supported_sources (control.c, line 1165): Could not query supported trigger sources

[FATAL] [1376320827.247888760]: enumTriggerSources() failed: -1
[ERROR] [1376320827.247983560]: Failed to enumerate trigger sources
libdc1394 error: Generic failure: in dc1394_feature_get_power (control.c, line 1408): Could not get feature status

libdc1394 error: Generic failure: in dc1394_external_trigger_get_power (control.c, line 1676): Could not set external trigger

[FATAL] [1376320827.248249960]: getExternalTriggerPowerState() failed: -1
libdc1394 error: Generic failure: in dc1394_feature_set_power (control.c, line 1428): Could not get feature register

libdc1394 error: Generic failure: in dc1394_external_trigger_set_power (control.c, line 1668): Could not set external trigger

[FATAL] [1376320827.248566400]: setExternalTriggerPowerState() failed: -1
[ERROR] [1376320827.248691320]: Failed to set external trigger power
libdc1394 error: Generic failure: in dc1394_software_trigger_get_power (control.c, line 1700): Could not get software trigger status

[FATAL] [1376320827.248951800]: getSoftwareTriggerPowerState() failed: -1
libdc1394 error: Generic failure: in dc1394_software_trigger_set_power (control.c, line 1691): Could not set software trigger

[FATAL] [1376320827.249144760]: setSoftwareTriggerPowerState() failed: -1
[ERROR] [1376320827.249262240]: Failed to set software trigger power
libdc1394 error: Generic failure: in dc1394_external_trigger_get_mode (control.c, line 1122): Could not get trigger mode

[FATAL] [1376320827.249479520]: getTriggerMode() failed: -1
libdc1394 error: Generic failure: in dc1394_external_trigger_set_mode (control.c, line 1143): Could not get trigger mode

[FATAL] [1376320827.249919720]: setTriggerMode() failed: -1
[ERROR] [1376320827.249996080]: Failed to set trigger mode
libdc1394 error: Generic failure: in dc1394_external_trigger_has_polarity (control.c, line 1657): Could not get trigger polarity capability

[FATAL] [1376320827.250179920]: getPolarity() failed: -1
libdc1394 error: Generic failure: in dc1394_external_trigger_has_polarity (control.c, line 1657): Could not get trigger polarity capability

[FATAL] [1376320827.250683640]: setPolarity() failed: -1
[ERROR] [1376320827.250790480]: Failed to set trigger polarity
libdc1394 error: Generic failure: in dc1394_external_trigger_get_supported_sources (control.c, line 1165): Could not query supported trigger sources

[FATAL] [1376320840.046748439]: enumTriggerSources() failed: -1
[ERROR] [1376320840.046974879]: Failed to enumerate trigger sources
libdc1394 error: Generic failure: in dc1394_feature_get_power (control.c, line 1408): Could not get feature status

libdc1394 error: Generic failure: in dc1394_external_trigger_get_power (control.c, line 1676): Could not set external trigger

[FATAL] [1376320840.047223919]: getExternalTriggerPowerState() failed: -1
libdc1394 error: Generic failure: in dc1394_feature_set_power (control.c, line 1428): Could not get feature register

libdc1394 error: Generic failure: in dc1394_external_trigger_set_power (control.c, line 1668): Could not set external trigger

[FATAL] [1376320840.047486079]: setExternalTriggerPowerState() failed: -1
[ERROR] [1376320840.047596119]: Failed to set external trigger power
libdc1394 error: Generic failure: in dc1394_software_trigger_get_power (control.c, line 1700): Could not get software trigger status

[FATAL] [1376320840.048000399]: getSoftwareTriggerPowerState() failed: -1
libdc1394 error: Generic failure: in dc1394_software_trigger_set_power (control.c, line 1691): Could not set software trigger

[FATAL] [1376320840.048390839]: setSoftwareTriggerPowerState() failed: -1
[ERROR] [1376320840.048628919]: Failed to set software trigger power
libdc1394 error: Generic failure: in dc1394_external_trigger_get_mode (control.c, line 1122): Could not get trigger mode

[FATAL] [1376320840.049086759]: getTriggerMode() failed: -1
libdc1394 error: Generic failure: in dc1394_external_trigger_set_mode (control.c, line 1143): Could not get trigger mode

[FATAL] [1376320840.049483079]: setTriggerMode() failed: -1
[ERROR] [1376320840.049555119]: Failed to set trigger mode
libdc1394 error: Generic failure: in dc1394_external_trigger_has_polarity (control.c, line 1657): Could not get trigger polarity capability

[FATAL] [1376320840.049731919]: getPolarity() failed: -1
libdc1394 error: Generic failure: in dc1394_external_trigger_has_polarity (control.c, line 1657): Could not get trigger polarity capability

[FATAL] [1376320840.049941239]: setPolarity() failed: -1
[ERROR] [1376320840.050057559]: Failed to set trigger polarity
libdc1394 error: Generic failure: in dc1394_external_trigger_get_supported_sources (control.c, line 1165): Could not query supported trigger sources

[FATAL] [1376320852.697008279]: enumTriggerSources() failed: -1
[ERROR] [1376320852.697119039]: Failed to enumerate trigger sources
libdc1394 error: Generic failure: in dc1394_feature_get_power (control.c, line 1408): Could not get feature status

libdc1394 error: Generic failure: in dc1394_external_trigger_get_power (control.c, line 1676): Could not set external trigger

[FATAL] [1376320852.697394839]: getExternalTriggerPowerState() failed: -1
libdc1394 error: Generic failure: in dc1394_feature_set_power (control.c, line 1428): Could not get feature register

libdc1394 error: Generic failure: in dc1394_external_trigger_set_power (control.c, line 1668): Could not set external trigger

[FATAL] [1376320852.697664559]: setExternalTriggerPowerState() failed: -1
[ERROR] [1376320852.697743199]: Failed to set external trigger power
libdc1394 error: Generic failure: in dc1394_software_trigger_get_power (control.c, line 1700): Could not get software trigger status

[FATAL] [1376320852.697985599]: getSoftwareTriggerPowerState() failed: -1
libdc1394 error: Generic failure: in dc1394_software_trigger_set_power (control.c, line 1691): Could not set software trigger

[FATAL] [1376320852.698151879]: setSoftwareTriggerPowerState() failed: -1
[ERROR] [1376320852.698236639]: Failed to set software trigger power
libdc1394 error: Generic failure: in dc1394_external_trigger_get_mode (control.c, line 1122): Could not get trigger mode

[FATAL] [1376320852.698404559]: getTriggerMode() failed: -1
libdc1394 error: Generic failure: in dc1394_external_trigger_set_mode (control.c, line 1143): Could not get trigger mode

[FATAL] [1376320852.698615959]: setTriggerMode() failed: -1
[ERROR] [1376320852.698688159]: Failed to set trigger mode
libdc1394 error: Generic failure: in dc1394_external_trigger_has_polarity (control.c, line 1657): Could not get trigger polarity capability

[FATAL] [1376320852.698912519]: getPolarity() failed: -1
libdc1394 error: Generic failure: in dc1394_external_trigger_has_polarity (control.c, line 1657): Could not get trigger polarity capability

[FATAL] [1376320852.699115679]: setPolarity() failed: -1
[ERROR] [1376320852.699214679]: Failed to set trigger polarity
testcamera_image_hz_test ... ok
testcamera_info_hz_test ... ok
testdiagnostics_hz_test ... ok

[ROSTEST]-----------------------------------------------------------------------

[camera1394.rosunit-camera_image_hz_test/test_hz][passed]
[camera1394.rosunit-camera_info_hz_test/test_hz][passed]
[camera1394.rosunit-diagnostics_hz_test/test_hz][passed]

SUMMARY
 * RESULT: SUCCESS
 * TESTS: 3
 * ERRORS: 0
 * FAILURES: 0

The catkinized Hydro version does not invoke catkin_package().

Consequently, the package.xml does not get installed and rospack find camera1394 does not work.

@bgromov: Since S/W triggering now works thanks to #9, the driver should support the ROS polled_camera API.

Usually when certain parameter's value is not correct it is reset back to previous or to one that set on device. Current version is doing that, but only with internal variables. So it doesn't write it back to newconfig variable and thus dynamic_reconfigure is not notified.

This has to be fixed in Trigger::reconfigure() for all trigger parameters except for external_trigger and software_trigger.

• camera1394 node and nodelet crash with theora subscriber 5574
• frequent failures setting ROI on Sony cameras 4752
• sometimes Sony XCD-SX910 camera hangs when reconfigure_gui starts 4762
• debayering mono8 for cameras that say not to support raw8 (bayer pattern) 5494

Currently, the number of DMA buffers is fixed to 4 (#define NUM_DMA_BUFFERS 4 in dev_camera1394.cpp).

I propose to make it a parameter for the following reasons.
The size of the buffer can be quite large (e.g., Ladybug3 4*12 Mpx ~ 48MB) and can consume too much memory.
The number of buffers can be too low for high-frame rate cameras and can cause dropping frames.

(Now, we have a patched version of the driver, with an extra parameter in .cfg, which seems to work well.)

This camera seems to lack some required feature (don't know which one):

libdc1394 error: Generic failure: in dc1394_feature_is_present (control.c, line 1317): Could not get register for feature

libdc1394 error: Generic failure: in dc1394_feature_get (control.c, line 234): Could not check feature presence

libdc1394 error: Generic failure: in dc1394_feature_get_all (control.c, line 209): Could not get camera feature

[ERROR] [1328285358.874668407]: could not get camera feature information
[ERROR] [1328285358.874756054]: [08004602000b05d9] feature initialization failure

This is an old ticket carried forward from ros-pkg Trac #5365.

Hi,
I am working on a project where I need to use the LadyBug 3 for getting a 360deg view of the scene. I built this repo from source, however, I am able to access just 1 camera (default camera: 0) from it.

I also tried to get the following launch files to work, however, none are working in my case:

1. camera.launch - however the node runs perfectly using rosrun camera1394 camera1394_node
2. multicamera_example_1.launch
3. multicamera_example_2.launch

The camera remains inactive and the error received is that the camera could not be opened, with a dull green light, which according to the manual means that the camera is idle.

Is there any way in which I would be able to access all the cameras (or any other camera rather than default)? Any help on the same would be greatly appreciated.

Some cameras provide special functionality through control registers which could be made accessible through the driver. I suppose a good option would be to advertise a service to control particular registers.

Our particular use case is the following. We need to exclude one of the sensors of Ladybug3 from auto exposure by calling dc1394_set_control_register. By now, we use a patched version of the driver, calling this inside Camera1394::open. Of course, a general service interfacing all control registers would be a much better option.

There is a problem in the way camera1394 package publishes camera_info. It adds non zero ROI parameters, however it publishes already cropped image. OpenCV tries to crop ROI from the already cropped image.

$ ROS_NAMESPACE=stereo_sync rosrun stereo_image_proc stereo_image_proc

OpenCV Error: Assertion failed (0 <= roi.x && 0 <= roi.width && roi.x + roi.width <= m.cols && 0 <= roi.y && 0 <= roi.height && roi.y + roi.height <= m.rows) in Mat, file /Users/artemlenskiy/ros/hydro/src/opencv2/modules/core/src/matrix.cpp, line 323
OpenCV Error: Assertion failed (0 <= roi.x && 0 <= roi.width && roi.x + roi.width <= m.cols && 0 <= roi.y && 0 <= roi.height && roi.y + roi.height <= m.rows) in Mat, file /Users/artemlenskiy/ros/hydro/src/opencv2/modules/core/src/matrix.cpp, line 323
libc++abi.dylib: libc++abi.dylib: terminating with uncaught exception of type cv::Exception: /Users/artemlenskiy/ros/hydro/src/opencv2/modules/core/src/matrix.cpp:323: error: (-215) 0 <= roi.x && 0 <= roi.width && roi.x + roi.width <= m.cols && 0 <= roi.y && 0 <= roi.height && roi.y + roi.height <= m.rows in function Mat
terminating with uncaught exception of type cv::Exception: /Users/artemlenskiy/ros/hydro/src/opencv2/modules/core/src/matrix.cpp:323: error: (-215) 0 <= roi.x && 0 <= roi.width && roi.x + roi.width <= m.cols && 0 <= roi.y && 0 <= roi.height && roi.y + roi.height <= m.rows in function Mat

Originally the issue was posted here
ros-perception/image_pipeline#55 (comment)

The driver_base package is only used by a few drivers and is deprecated for new drivers. Its status is End of Life, but there is currently no plan to delete it, so no big hurry on removing it from camera1394.

The camera1394 dependency is trivial, only using some constant definitions for the driver state and the reconfigure levels.

The only tricky part is that the reconfigure levels must be defined in C++ for the driver and in Python for the Camera1394.cfg script, as is done by the driver_base/SensorLevels ROS message. They could either be hard-coded, or defined in a message defined locally to the driver.

The segbot package depends on camera1394, and its doc job is failing:

• http://jenkins.ros.org/job/doc-hydro-segbot/100/

See this message and reply for more details:

• http://lists.ros.org/pipermail/ros-release/2014-April/004437.html
• http://lists.ros.org/pipermail/ros-release/2014-April/004438.html

@dirk-thomas says this is because there is something wrong with the LIBRARIES export in this CMakeLists.txt.

I don't know exactly what's wrong with it.

The problem appeared with introduction of #9.

Due to the blocking method used in Camera1394::readData() libdc1394 will not return control until the data received from camera. The problem can be fixed fairly easy since Camera1394::readData() is already called periodically by main thread.

Also, introduction of non-blocking read method will allow implementation of polled_camera interface (#13).

With the ladybug3, in format 7 mode 7, the images come JPEG compressed. A DC1394 frame is actually 24 images (6*RGGB), compressed, and stacked together.

I am still figuring the details out with PointGrey support, but it seems that changing the ROI does not affect which part of the image we see, but rather the compression factor. Also, I don't know if any other camera has this mode.

Anyway, the data sent from the camera is not strictly speaking an Image. And besides the semantic problem, which I would happily ignore, the main issue is that, due to compression, the number of bytes is different (usually smaller) from what can be computed from the ROI (W_H_D). Meaning that with the current driver, there are plenty of useless bytes that are published.

One idea, probably the simplest, would be to modify Format7::unpackData so that with the proper flags setup (i.e. ladybug_mode_), it would resize the Image.data field so that it would hold as few padding bytes as possible. We'd probably need to set a special encoding string too. Also, the other fields of the image msg would have to be ignored at the subscriber level.

Trying to use a CompressedImage instead of Image, or maybe a new data type (i.e. LadybugImageSet), seems quite difficult (more from an interface perspective than from a coding perspective). The main difficulty is to handle changing from one mode to another at runtime, which means that it would publish to a topic or another accordingly.

Any suggestion?

$ rosrun camera1394 camera1394_node _guid:=00b09d0100e96e58
[ WARN] [1458642111.606965852]: Comparing 00b09d0100e96e58 to 00b09d0100e96e58
[ INFO] [1458642111.665301569]: Found camera with GUID 00b09d0100e96e58
[ INFO] [1458642111.665498984]: camera model: Point Grey Research Blackfly BFLY-U3-03S2C
[ WARN] [1458642111.667959759]: Bayer pattern [ (4)] is invalid.
libdc1394 error: Generic failure: in dc1394_format7_get_max_image_size (format7.c, line 249): Could not get max image sizes

libdc1394 error: Generic failure: in dc1394_format7_get_max_image_size (format7.c, line 249): Could not get max image sizes

libdc1394 error: Generic failure: in dc1394_format7_get_max_image_size (format7.c, line 249): Could not get max image sizes

libdc1394 error: Generic failure: in dc1394_format7_get_max_image_size (format7.c, line 249): Could not get max image sizes

[ INFO] [1458642111.749695479]: Format7 unit size: (4x2), position: (2x2)
[ INFO] [1458642111.750066935]: Format7 region size: (648x488), offset: (0, 0)
[ INFO] [1458642111.788503000]: [00b09d0100e96e58] opened: format7_mode0, 15 fps, 400 Mb/s
[ INFO] [1458642112.130803109]: using default calibration URL
[ INFO] [1458642112.131337272]: camera calibration URL: file:///home/odroid/.ros/camera_info/00b09d0100e96e58.yaml
^C*** Error in `/home/odroid/catkin_ws/devel/lib/camera1394/camera1394_node': corrupted double-linked list: 0x00123668 ***
Aborted

On my ladybug3, I found that I had to turn on a feature before attempting to change the mode to auto or manual (and possibly one push). See below for my quick solution.

bool Features::setMode(dc1394feature_info_t *finfo, dc1394feature_mode_t mode)
{
dc1394feature_t feature = finfo->id;
if (hasMode(finfo, mode))
{
ROS_DEBUG_STREAM("setting feature " << featureName(feature)
<< " mode to " << modeName(mode));
if (finfo->on_off_capable &&
(mode==DC1394_FEATURE_MODE_MANUAL || mode==DC1394_FEATURE_MODE_AUTO
|| mode==DC1394_FEATURE_MODE_ONE_PUSH_AUTO) )
{
if (DC1394_SUCCESS !=
dc1394_feature_set_power(camera_, feature, DC1394_ON))
{
ROS_WARN_STREAM("failed to turn feature " << featureName(feature)
<< " on prior to setting it to mode "
<< modeName(mode));
return false;
}
}
if (DC1394_SUCCESS !=
dc1394_feature_set_mode(camera_, feature, mode))
{
ROS_WARN_STREAM("failed to set feature " << featureName(feature)
<< " mode to " << modeName(mode));
return false;
}
}
else
{
// device does not support this mode for this feature
ROS_DEBUG_STREAM("no " << modeName(mode)
<< " mode for feature " << featureName(feature));
return false;
}
return true;
}

Hi,
while using 2 Basler 1394 cameras, with softwareTrigger, i noticed that the CPU-usage increases tremendeously in SW-Trigger mode.

Setup:

• 2-channel firewire400 pcie card
• intel i5
• 2 basler a622f cameras.
• modified camera1394_trigger_node (triggering 2 cameras)

Example A:
both cams running on internal trigger (camera1394_trigger_node running @1Hz for comparability)

"external_trigger"  = "false"
"software_trigger"  = "false"
"trigger_source"    = "source_0"

Nodelet takes 2% CPU (images @ 14,74 fps)

Example B:
both cams running on SW trigger (camera1394_trigger_node running 1Hz)

"external_trigger"  = "true"
"software_trigger"  = "true"
"trigger_source"    = "source_software"

Nodelet takes 50% CPU (images @ 1fps)

Where/How can i reduce CPU usage? Any ideas?

I believe the current master works with both Hydro and Indigo. It passes pre-release tests on Indigo, but one problem (#38) has been observed that does not seem to occur with the previously-released hydro-devel version.

So, we need more testing. Most of my systems and all of my current development work are still on Precise and Hydro. It will take some time for me to set up a good Indigo test environment.

I could use some test assistance. If you are willing to help with release testing, please:

• build the master branch from source in a catkin workspace
• run tests with any camera models you have available
• report here the devices tried and the results (good or bad)
• open defect issues for any bugs encountered

This implies defining an API for the various trigger configuration parameters. We may choose to change the semantics slightly to make things simpler and easy to explain.

• Hardware triggering: which parameters are required? Which are optional?
• Software triggering: which parameters are required? Which are optional?
• Do users have to set both ~external_trigger and ~software_trigger to do S/W triggering? Why?
• What do the different ~auto_trigger options mean?
• Make sure terminology is clear: does "external" triggering mean the same as "hardware" triggering?
• Should we expose S/W triggering to users before adding the polled_camera interface (#13)?
• Identify sections of the wiki documentation that need updating, like the Road Map and Limitations sections.
• Update the parameters list. Make sure new parameters' descriptions are clear to non-experts.
• Add a tutorial describing how to configure a camera for external H/W triggering.

@bgromov: any other doc requirements?

See also: #9, #12, #14, #16,

Hi,

I am using a Flea3 by pointgrey and I am not able to change any parameter through a launch file and/or a yaml file.
On the other hand, if I change the parameters through the FlyCapture SDK (by pointgrey) I am able to change the parameters. I am also able to change them through rosrun rqt_reconfigure rqt_reconfigure

Do you have any ideas why this happens?

An example of my launch file is the following:

<launch>

  <node pkg="camera1394" type="camera1394_node" name="camera1394_node" >
    
<rosparam file="$(find camera1394)/tests/configCamera.yaml" /> 
<param name="guid" value="00b09d0100ea9271" />
<param name="auto_gain" value="false"/>
<param name="gain" value="0"/>
 
 </node>
</launch>

And my configCamera.yaml file is just (for simplicity):

auto_gain: false
gain: 0.0

Where am I doing a mistake?

Thanks in advance

Hi,

Having the ability to flip or mirror a image from a camera would be very useful (I'm using a FireFly MV on the USB bus) and our hardware mounting is such that I need one camera flipped horizontally.

According to PointGrey's Register Reference, it can be enabled by setting the register IMAGE_DATA_FORMAT(0x1048) , bit 23 to 1 or 0 as required. It will do image flip on-camera in DMA buffers.
https://pixhawk.ethz.ch/_media/dev/electronics/cameras/point_grey_digital_camera_register_reference.pdf

If this change isn't something that can be adapted to mainstream, I'm willing to do it myself, but would like some help on where and how to implement it best. Otherwise, if this can be implemented in software in the driver itself, that'd be awesome too, and would benefit all camera types.

Thanks,
Kabir

This should eliminate the undesired GUI dependencies caused by the old geometry stack.

Specifically the work by @miquelmassot, here:

https://github.com/srv/camera1394stereo

I'm not sure how much the two packages have diverged at this point, but it would be great to have robust stereo support in the base driver rather than stuck in a fork.

Having looked a little bit, it seems the meat of it is the findStereoMethod function, and the stereo extraction taking place in the readData function.

Would you consider a pull request to merge this stuff in? We have Bumblebee cams for testing and would happily update the wiki as well.

It looks like all the dependencies are already wet in Groovy.

I don't want to mess up user workspaces by making this change to Groovy after that version has already been released.

Hi!

I've the firefly mv FMVU-03MTC and I'm already able to publish the image using the camera1394_node. Now I would like to initialize the node with the hardware trigger option. I can't find any examples/documentation of that, can you help me?

inline bool hasTrigger(void)
{
return DC1394_TRUE == feature_set_.feature[DC1394_FEATURE_TRIGGER].available;
}

must be changed to

inline bool hasTrigger(void)
{
return DC1394_TRUE == feature_set_.feature[DC1394_FEATURE_TRIGGER-DC1394_FEATURE_MIN].available;
}

There are some new features targeted for Indigo which require documentation. We may need a doc review. This issue is for tracking and discussion of the work to be done.

I plan to increment the minor number for the Indigo release to 1.10.0. The other updates appear to be bug fixes, with no documentation changes required. I will probably release some of them as 0.9.5 to Hydro.

• Trigger support
• Services to get and set control registers
• Documentation review

@bgromov, @bricerebsamen, @tpet, @mikepurvis, @ktossell: please review this list of completeness. Am I forgetting something?

xref: #32

These new interfaces need unit tests:

• with no camera attached
• with a camera having appropriate registers

See: REP-0135.

This needs to be done carefully, with deprecation warnings and a tick-tock rollout over at least two releases.

Not currently scheduled.

Hi,
I have this problem where sometimes, after pluggin the camera, the image seems to be being read with an offset, and is therefore broken (see attached image).

I dont have this problem with coriander, so I'm not sure if this is a libdc1394 problem or not.
Any ideas? This behaviour is completely annoying and difficult to deal with.

I think there's a pretty serious issue with how camera1394 handles parameters. Currently it uses the dynamic-reconfigure-generated Config class for storing all of the parameters, each of which is roughly truncated between 0 and 4095 (except for gamma which is limited between 0.0 and 10.0). Then when it goes to apply these parameters, it attempts to apply the "absolute" versions which are specified as float values between some a priori unknown ranges. At this point the given parameters might have been truncated by the Config class and it's not even clear if a given parameter is supposed to be in absolute or integer form.

@jack-oquin Have you noticed this issue on any cameras? For me it meant that I had no way of accurately controlling the gamma on a couple of Flea2 sensors.

Hi, I am using a Flea camera and I am launching the following launch file:

<!-- -*- mode: XML -*- -->

<!-- Start the driver for a specific IEEE1394 digital camera.

     this is a test script: NOT FOR GENERAL USE

     arg: camera = base file name of camera YAML parameters
                   (default: unibrain)
-->

<launch>

  <arg name="camera" default="flea" />

  <node pkg="camera1394" type="camera1394_node" name="camera1394_node" >
<rosparam
       file="configCamera.yaml" /> 

<param name="guid" value="00b09d0100ea9271" />
<param name="video_mode" value="format7_mode1" />

  </node>
</launch>

I would like to know why I get the warning
[ WARN] [1522048449.989425952]: Bayer pattern [ (4)] is invalid.

Thanks in advance

NODES
  /
    camera1394_node (camera1394/camera1394_node)

ROS_MASTER_URI=http://SCHIANO-UBUNTU:11311

process[camera1394_node-1]: started with pid [13628]
[ WARN] [1522048449.912873984]: Comparing 00b09d0100ea9271 to 00b09d0100ea9271
[ INFO] [1522048449.986876608]: Found camera with GUID 00b09d0100ea9271
[ INFO] [1522048449.987260096]: camera model: Point Grey Research Flea3 FL3-U3-32S2M
[ WARN] [1522048449.989425952]: Bayer pattern [ (4)] is invalid.