Differences

This shows you the differences between two versions of the page.

--- cs:cameras:start [2016/08/21 19:17]
Brandon Kallaher created
+++ cs:cameras:start [2022/09/29 20:48] (current)
Justin Pilgrim [Running With ROS]
@@ Line 6: / Line 6: @@
   * The cameras come with an SDK which contains configuration software and programmable interfaces for the camera. You can access it on their website.
-===== Setup =====
+===== Datasheets =====
+{{ :cs:cameras:basic_specs-flea3-gige.pdf |}} \\
+{{ :cs:cameras:fl3-ge-imaging-performance.pdf |}} \\
+{{ :cs:cameras:fl3-ge_gettingstarted.pdf |}} \\
+{{ :cs:cameras:flea3-ge-technical-reference.pdf |}}
+===== First Time Setup =====
   * Since the cameras are ethernet cameras the only thing you need for setup is an ethernet connection and a 12V power supply. The cameras take a few seconds to boot up and usually give themselves a default IP that is not on the network. You can use the flycap software to detect the cameras and add them to the network.
@@ Line 17: / Line 24: @@
   * The packet delay should also be changed to account for the packet size increase. It should be the lowest delay that does not cause consistency errors depending on the setup. This can be tested by configuring the delay and running the cameras for about 5 minutes. If the cameras report no loss then those settings are optimal.
   * Be aware that the jumbo packet size cannot usually be maxed out. (On my system I could only get to ~7000 byte packets before the stream would freeze) In order to get optimal settings you have to play with the packet size and delay until you get the highest estimated bandwidth without errors.
+===Serial Numbers===
+  * Left:
+  * Right: 14406634
 ===== Camera Settings =====
@@ Line 26: / Line 37: @@
 ===== Problems / Fixes =====
-  * PGR cameras have issues on linux with large packet types. In order to fix this the buffer needs to be increased. A fix is here: [[https://www.ptgrey.com/KB/10016|Linux Streaming Fix]]
+  * PGR cameras have issues on linux with large packet types. In order to fix this the buffer needs to be increased.
+===Linux Streaming Fix:===
+Derived from here: [[https://www.ptgrey.com/KB/10016|Linux Streaming Fix]]
+CAUSE:
+When streaming images from a GigE Vision camera on Linux Ubuntu 8.04 systems, a high number of lost data packets may be observed. In FlyCapture SDK applications, dropped packets result in IMAGE_CONSISTENCY_ERRORS returned.
+ANSWER:
+To fix, try one or both of the following:
+Increase packet delay time using the FlyCapture2 API or the FlyCap2 program.
+Increase the amount of memory Linux uses for receive buffers using the sysctl interface. Whereas the system standard (default) and maximum values for this buffer default to 128 KB and 120 KB respectively, increasing both of these parameters to 1 MB significantly improves image streaming results.
+Note: On some ARM boards, you may need to increase the receive buffer size to greater than 1 MB before noticing improved streaming results. Increasing the buffer size can enhance receive performance, but it also uses more memory.
+The following sysctl command updates the receive buffer memory settings:
+  sudo sysctl -w net.core.rmem_max=1048576 net.core.rmem_default=1048576
+Note: In order for these changes to persist after system reboots, the following lines must be manually added to the bottom of the /etc/sysctl.conf file:
+  net.core.rmem_max=1048576
+  net.core.rmem_default=1048576
+Once changes are persisted, they can be reloaded at any time by running the following command in sysctl:
+  sudo sysctl -p
+==== Running With ROS ====
+Point Grey supplies drivers for our Gig E cameras. You will need to have installed them:
+  sudo aptitude install ros-indigo-pointgrey-camera-driver
+If you would like to simply enumerate the cameras connected to the network, run:
+  rosrun pointgrey_camera_driver list_cameras
+Sometimes the cameras are a little fiddly and you may need to cycle power to them before they show up on this list. After you have confirmed that any and all cameras you would like to use are connected, you can manually begin publishing of the images from each camera:
+  roslaunch pointgrey_camera_driver camera.launch
+This can become a little tedious after a while, so the current Robosub repository contains a launch file of its own. This can be used as follows:
+  roslaunch robosub cameras.launch
+The cameras should begin publishing on the **/camera/[left|right|bottom]/image** topic. If you wish to change the serial number used for the left/right camera simply remap it when launching.
+  roslaunch robosub cameras.launch left_serial:=12345678 right_serial:=12345679
+In the future, a downward facing camera is also planned to be added, though many of the steps will be similar.
+One more note, when using the Point Grey drivers, the cameras will publish a [[https://github.com/ros-drivers/pointgrey_camera_driver/blob/master/wfov_camera_msgs/msg/WFOVImage.msg|WFOVImage]] message so many standard ros systems may not be able to use the data without it being republished. A republisher has been implemented in the Robosub repository and can be run with the following command:
+  rosrun robosub camera_repub
+This will republish the [[https://github.com/ros-drivers/pointgrey_camera_driver/blob/master/wfov_camera_msgs/msg/WFOVImage.msg|WFOVImage message]] messages as [[http://docs.ros.org/api/sensor_msgs/html/msg/Image.html|sensor_msgs/Image]] messages on the **/camera/[left|right|bottom]/undistorted** topic which aligns with the undistortion nodes so nodes are agnostic as to whether or not undistortion is being performed.
+{{bryant-koshu-mech-copy.jpg}}

User Tools

Differences

Page Tools

Palouse RoboSub Technical Documentation

Site Tools