|
| 1 | +This is a demonstration of the Quality of Service (QoS) features of ROS 2 using Python. |
| 2 | +There are two programs implemented here: cam2image_py, and showimage_py. Note that in |
| 3 | +order for these programs to work, an OpenCV binding for Python3 must be available. As |
| 4 | +of this writing (January 11, 2017), only OpenCV 3 or later supports Python3. Instructions |
| 5 | +for compiling OpenCV3 for Python3 are available here: |
| 6 | + |
| 7 | +http://stackoverflow.com/questions/20953273/install-opencv-for-python-3-3 |
| 8 | + |
| 9 | +The condensed rundown that works on Ubuntu16.04 and will install to /usr/local is: |
| 10 | +$ sudo apt install python3 build-essential cmake git libgtk2.0-dev pkg-config libavcodec-dev libavformat-dev libswscale-dev python3.5-dev libpython3-dev python3-numpy libtbb2 libtbb-dev libjpeg-dev libpng-dev libtiff-dev libjasper-dev libdc1394-22-dev |
| 11 | +$ git clone https://github.com/opencv/opencv |
| 12 | +$ cd opencv |
| 13 | +$ git checkout 3.2.0 |
| 14 | +$ mkdir release |
| 15 | +$ cd release |
| 16 | +$ cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local .. |
| 17 | +$ make -j8 |
| 18 | +$ sudo make install |
| 19 | + |
| 20 | +CAM2IMAGE_PY |
| 21 | +------------ |
| 22 | +This is a Python program that will take data from an attached camera, and publish the |
| 23 | +data to a topic called "image", with the type sensor_msgs::msg::Image. If a camera |
| 24 | +isn't available, this program can also generate a default image and smoothly "move" |
| 25 | +it across the screen, simulating motion. The usage output from the program looks like |
| 26 | +this: |
| 27 | + |
| 28 | +usage: cam2image_py.py [-h] [-b] [-d QUEUE_DEPTH] [-f FREQUENCY] [-k {0,1}] |
| 29 | + [-r {0,1}] [-s {0,1}] [-x WIDTH] [-y HEIGHT] |
| 30 | + |
| 31 | +optional arguments: |
| 32 | + -h, --help show this help message and exit |
| 33 | + -b, --burger Produce images of burgers rather than connecting to a |
| 34 | + camera (default: False) |
| 35 | + -d QUEUE_DEPTH, --depth QUEUE_DEPTH |
| 36 | + Queue depth (default: 10) |
| 37 | + -f FREQUENCY, --frequency FREQUENCY |
| 38 | + Publish frequency in Hz (default: 30) |
| 39 | + -k {0,1}, --keep {0,1} |
| 40 | + History QoS setting, 0 - keep last sample, 1 - keep |
| 41 | + all the samples (default: 1) |
| 42 | + -r {0,1}, --reliability {0,1} |
| 43 | + Reliability QoS setting, 0 - best effort, 1 - reliable |
| 44 | + (default: 1) |
| 45 | + -s {0,1}, --show {0,1} |
| 46 | + Show the camera stream (default: 0) |
| 47 | + -x WIDTH, --width WIDTH |
| 48 | + Image width (default: 320) |
| 49 | + -y HEIGHT, --height HEIGHT |
| 50 | + Image height (default: 240) |
| 51 | + |
| 52 | +The -d, -k, and -r parameters control various aspects of the QoS implementation, and |
| 53 | +are the most interesting to play with when testing out QoS. |
| 54 | + |
| 55 | +Note that this program also subscribes to a topic called "flip_image" of type |
| 56 | +std_msgs::msg::Bool. If flip_image is set to False, the data coming out of the camera |
| 57 | +is sent as usual. If flip_image is set to True, the data coming out of the camera is |
| 58 | +flipped around the Y axis. |
| 59 | + |
| 60 | +If the -s parameter is set to 1, then this program opens up a (local) window to show |
| 61 | +the images that are being published. However, these images are *not* coming in through |
| 62 | +the ROS 2 pub/sub model, so this window cannot show off the QoS parameters (it is mostly |
| 63 | +useful for debugging). See SHOWIMAGE_PY below for a program that can show QoS over the |
| 64 | +pub/sub model. |
| 65 | + |
| 66 | +SHOWIMAGE_PY |
| 67 | +------------ |
| 68 | +This is a Python program that subscribes to the "image" topic, waiting for data. As |
| 69 | +new data comes in, this program accepts the data and can optionally render it to |
| 70 | +the screen. The usage output from the program looks like this: |
| 71 | + |
| 72 | +usage: showimage_py.py [-h] [-d QUEUE_DEPTH] [-k {0,1}] [-r {0,1}] [-s {0,1}] |
| 73 | + |
| 74 | +optional arguments: |
| 75 | + -h, --help show this help message and exit |
| 76 | + -d QUEUE_DEPTH, --depth QUEUE_DEPTH |
| 77 | + Queue depth (default: 10) |
| 78 | + -k {0,1}, --keep {0,1} |
| 79 | + History QoS setting, 0 - keep last sample, 1 - keep |
| 80 | + all the samples (default: 1) |
| 81 | + -r {0,1}, --reliability {0,1} |
| 82 | + Reliability QoS setting, 0 - best effort, 1 - reliable |
| 83 | + (default: 1) |
| 84 | + -s {0,1}, --show {0,1} |
| 85 | + Show the camera stream (default: 0) |
| 86 | + |
| 87 | +The -d, -k, and -r parameters control various aspects of the QoS implementation, and |
| 88 | +are the most interesting to play with when testing out QoS. |
| 89 | + |
| 90 | +If the -s parameter is set to 1, then this program opens up a window to show the images |
| 91 | +that have been received over the ROS 2 pub/sub model. This program should be used |
| 92 | +in conjunction with CAM2IMAGE_PY to demonstrate the ROS 2 QoS capabilities over lossy/slow |
| 93 | +links. |
| 94 | + |
| 95 | +EXAMPLE USAGE |
| 96 | +------------- |
| 97 | +To use the above programs, you would run them something like the following: |
| 98 | + |
| 99 | +# In the first terminal, run the data publisher. This will connect to the 1st camera |
| 100 | +# available, and print out "Publishing image #" for each image it publishes. |
| 101 | +$ python3 cam2image_py.py |
| 102 | + |
| 103 | +# In a second terminal, run the data subscriber. This will subscribe to the "image" |
| 104 | +# topic and render any frames it receives. |
| 105 | +$ python3 showimage_py.py -s 1 |
| 106 | + |
| 107 | +# If you don't have a local camera, you can use the -b parameter to generate data on |
| 108 | +# the fly rather than get data from a camera: |
| 109 | +$ python3 cam2image_py.py -b |
0 commit comments