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:
https://github.com/lucasw/usb_cam/tree/bouncy 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?).
https://github.com/lucasw/v4l2ucp/tree/bouncy 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).
https://github.com/lucasw/imgui_ros/tree/bouncy - ROS UI using imgui https://github.com/ocornut/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 https://github.com/ocornut/imgui/issues/306#issuecomment-439653417 .
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).
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 https://gist.github.com/lucasw/76a903f98bce3179da6282baf9021f30 - 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.