ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

ROS2 usb_cam, imgui, image manipulation nodes



I’ve spent some time over the past few weeks learning ros2 and converting a few ros1 nodes to ros2 bouncy- so far at only a superficial level:

USB cameras usb_cam (which would more accurately be called v4l2_cam and have less confusion with uvc_cam). Camera parameter setting was offloaded to v4l2ucp below.

It would be nice to push this as a branch into ros-drivers/ros2-drivers.

I wonder if the sort of user & application integrating a webcam is not interested ros2 at this point? I haven’t touched uvc_camera in a while but I could try converting that next if there are advantages (image format conversion is easier?). v4l2ucp is based on the non-ros v4l2ucp utility but here is a non-gui ros interface to v4l devices that can alter settings like exposure or contrast on the same device being used by usb_cam (or any other software using a /dev/video).

ImGui - ROS UI using imgui ‘Bloat-free Immediate Mode Graphical User interface for C++ with minimal dependencies’. Currently it can display std_msgs topic values and simple plots, and images, and publish to same std_msgs with slider controls- all of which are created via service calls. The resting cpu usage is higher than a native gui but it ought to scale better for lots of graphics (especially 3D graphics later) and changing values. I’m currently using the SDL2 + OpenGL3 backend but could separate that out so any backend could be integrated.

I’d really like to eventually develop node graph viewing or even editing like in .

For use with v4l2ucp there is a script that reads parameters set for the type, min, & max of each parameter the v4l device supports (probably should make them delivered in response to a service call instead) and then calls the imgui_ros service call to create a slider or dropdown menu to change the parameter via a topic (though ros parameters instead of topics probably are better for this).

Image Manipulation

iir_image - subscribe to a number of image topics and combine them with parameter coefficients (e.g. 0.5 * image_0 + 0.5 * image_1). Or instead of multiple topics keep a buffer of received image on one topic and use the coefficients to combine the current image with images from the past.

roto_zoom - rotate and scale an image.

save_image - save a sequence of images with a parameter defined prefix and add a node start time timestamp and a sequence number to the file name. Capture all images received or only 1 when a trigger message is received.

resize - resize image and add vertical or horizontal black bars (letterbox) if the output size aspect ratio is different than input.


The launch files use argparse to get command line parameters into yaml files in /tmp/ for loading by ros2 nodes:

Some notes on using and converting ros1 to ros2 bouncy are here - there is too much to follow up on immediately as I encounter it, anything without a good workaround I’ll probably get back to later especially if it hasn’t been addressed in crystal.


To quote your gist:

The intent is to develop/learn how to convert ros1 packages first along with the entire workflow of building and debugging and deploying and then take advantage of ros2 features.

Would you say what you have so far is mostly the first part (learning ROS2 workflow, etc.)? Do you have an idea regarding what you’d like to do in order to take advantage of ROS2 features?


Would you say what you have so far is mostly the first part (learning ROS2 workflow, etc.)?

I’ve gotten to where I can be productive building basic systems involving image processing, topics, services, parameters and user i/o without much slowing down to figure out basics, and haven’t encountered anything insurmountable that would result in deferring adopting ros2 until the next release or spending a lot of time diving into the underlying ros2 libraries.

Do you have an idea regarding what you’d like to do in order to take advantage of ROS2 features?

The composition of nodes into processes and minimization of copies would come first. After that the communication profiles. I expect to run into performance issues with my current minimal functionality approach that will drive those, though it’s possible performance issues that could be solved with unused ros2 features will cause odd behavior and inexplicable failures- and the tools to determine that either don’t exist yet or aren’t sufficiently disseminated.