Recommended reading: ROS Sensor msgs, RViz (wiki.ros.org/rviz), Camera on ROS
One of the main goals ROS had set out to achieve was to remove redundant and unnecessary work in robotics. By providing sensible interfaces (ROS messages) and tools that utilize the interfaces, ROS removes lots of unnecessary work that would have been required with sensors.
Please refer to the camera section of ROS.
Observe that the sections are divided into multiple parts. First, there are software and tools that complement or enhance the sensing capabilities of the camera. These packages are generally, if not all, device-independent – that is, they function from the inputs of messages (topics).
Then, there are hardware drivers specific to each camera, or more generally, types of camera. These packages are either written by the manufacturers themselves or other programmers who wanted to connect the devices to ROS. These packages take raw data from the sensors and publishes it to ROS topics, or allows the sensors to be configured using ROS API (services or something called dynamic parameters).
Since the software tools and hardware drivers communicate through the common ROS interface, you can choose to only change one of them if there is an issue. For example, you can swap the cameras and hardware drivers, but still use the same software package for the large part, or vice versa.
Another thing to note is that devices are listed by the connection type (USB, Serial, Ethernet), as the devices also go through the common Linux interfaces for each types as well, generally through the ports (not the network ports discussed below).
The ports (with names like /dev/ttyUSB0) allows the users on Linux to read and write from the devices. Some notable characteristics of the ports are that they are …
- allocated dynamically unless specified otherwise (the first USB device is allocated under /dev/ttyUSB0, the second USB device /dev/ttyUSB1, …)
- Are treated as a file in Linux (which means that all the things that come with files are with ports, like read and write permissions)
Generally, the issue of reading and writing data off these ports will be abstracted away by the drivers (by their purpose).
However, in the cases in which drivers are not provided, the read and write would have to be performed in a specific fashion. For example, the port names specified above indicate (/dev/”tty”) that they are serial ports, which means that you have to communicate them with a specific baud rate (rate of communication), stop bit (signifying end of message), and delimiter (character that indicates the end of message).
For more information on serial port, skim through https://en.wikipedia.org/wiki/Serial_port.
However, as I stated before, we can skip over these complexities and deal with the abstractions of ROS instead.
Please refer to: http://docs.ros.org/api/sensor_msgs/html/msg/Image.html
Like with all ROS messages we have dealt with before, we can do likewise with the ROS image messages. We can assess the header (which contains timestamp, which is necessary to sync up all the sensor data together), put in image data as arrays of ints, and specify the encoding as a string (encoding schemes specify how the row of ints should be read to produce an image).
Other ROS interfaces, as mentioned before, are services (which we can write clients for) and parameters (which can easily be specified when launching the node).
Utilizing ROS interfaces are as simple as they sound – in the package usb_cam (http://wiki.ros.org/usb_cam), you can get images from topic ~<camera_name>/image, set parameters by alongside rosrun like “image_width:=500”, and request that ROS node do somethings by writing clients as specified by the srv files.