This demonstration shows SROS sending nontrivial amounts of data, namely, a webcam stream. To run this demonstration, it is necessary to rebuild SROS by following the instructions in the main package page but using this rosinstall file instead, which will also bring in OpenCV3. These instructions use OpenCV3 and cv_bridge to stream data from the first available webcam, convert them to ROS sensor_msgs/Image messages, send them to another ROS program (rospy_image_view.py), convert them back to OpenCV images and render them again using OpenCV's built-in viewer.
The main reason for using this separate rosinstall file is because adding OpenCV to the build significantly increases its complexity, both in terms of dependencies and just plain compile time. My poor little Raspberry Pi 3 has been working on this build for the past 5 hours, including one out-of-memory error and subsequent kernel panic! On a modern laptop the build should take about ten minutes.
srosrun sros_demos rospy_webcam.py
srosrun sros_demos rospy_image_view.py
As before, it is critical that if security is desired (i.e., this traffic will go over an insecure network), after the initial run to distribute the keys to rospy_webcam and rospy_image_view, during subsequent runs sroscore must not be invoked with the --keyserver switch to prevent the unsecured keyserver from being launched.
SSL causes some additional CPU load because it has to encrypt and decrypt traffic. To see the difference between SROS and "classic" ROS, just remove the s prefix from the commands being run in each terminal (i.e., just use "classic" roscore and rosrun). On a typical test machine, we see about about a 20-25% increase in CPU usage for each program when SSL is enabled to encrypt a 1-megapixel webcam at 30 frames/sec. In single-core terms, on a typical Core-i5 laptop, the sender program CPU usage jumps from 24% to 29%, and the receiver program jumps from 14% to 19%.