0
$\begingroup$

Rosanswers logo

What is the standard ROS way for implementing on-the-fly resolution changing for a camera node?

I haven't found any official articles on this, also I haven't found any popular camera nodes, supporting this. This feature is critical for my application, I want to implement it for e. g. cv_camera, but what should be the API?

Should it be dynamic_reconfigure parameters? Actually, I have never seen such parameters in a real-live package.

Or should it be some ROS service? set_camera_info, maybe?

Or maybe just standard parameters should be used, so the node should poll them periodically?


Originally posted by okalachev on ROS Answers with karma: 11 on 2018-03-27

Post score: 1

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

I don't think there is much of a standard around this, because most robots don't have run-time reconfigurable cameras (the resolution is often encoded in the launch file). dynamic_reconfigure is probably the most popular approach although most of the time it is used for parameters like white balance. One example is the Intel Realsense drivers.

I'd generally avoid "standard parameters" for this, since you probably want the feedback that things have changed. I'd suggest there are 4 possible ways which would all be "ROS-like":

  • ROS Service -- probably the simplest and most straight forward, you definitely get a response that things have completed. In general, services are a good idea if the service will return almost immediately. If it is a longer running operation, you might want to look at:
  • ROS Actions -- this is like a service, but implements a full state machine over several topics. It can be interrupted (unlike a service). The code complexity will be a bit higher than a service.
  • Dynamic reconfigure -- if you want to be able to use GUI tools like rqt_reconfigure, this might be the best option. The downside I could see with this approach is that you could get "partial changes" after you change each parameter with a tool like rqt_reconfigure. You might have to encode a lot of logic to handle that, to avoid sending bad updates down.
  • image_pipeline - if you have several "standard" configurations, this might be a possible approach. This is commonly found on a lot of robots which have a fixed camera resolution but want to offer downsampled versions for certain operations (e.g. inserting into a costmap). The image_pipeline package has a number of nodes/nodelets that can sample/convert your images. The upside is that there is no "switching" cost, the downside is that more processing might take place (although lazy subscribers can help here, as I believe all of the image_pipeline nodes/nodelets will stop doing work if they have no subscribers).

Originally posted by fergs with karma: 13902 on 2018-03-27

This answer was ACCEPTED on the original site

Post score: 3


Original comments

Comment by gvdhoorn on 2018-03-28:
I think one of the reasons there is no standard API is next to the things @fergs already mentioned, consumers of camera driver output mght not be capable of dealing with dynamically changing resolutions of images they receive. They should, but they might not. And it's not just images, afaik ..

Comment by gvdhoorn on 2018-03-28:
.. camera calibration is resolution dependent as well, so that would need to be updated too. Consumers of that need to be made aware of changes. I'm not sure the current image_transport and image_pipeline nodes/libs are setup for that.

Comment by okalachev on 2018-03-28:
When you use subscribeCamera, you get updated image and cameraInfo message in your callback at the same time. So this is OK.

Comment by gvdhoorn on 2018-03-28:
True, but that doesn't necessarily mean that every consumer always uses the latest version of those msgs. If the assumption (until now) has been that CameraInfo doesn't change, why not cache the first one and keep using that?

Comment by okalachev on 2018-03-28:
I believe, that all of the standard CV nodes use the latest cameraInfo message. You should do that because of two reasons: camera resolution may change; camera lens settings may change (optical zoom, etc).

So, if there are nodes, that do cache camera info, they are incorrect.

Comment by gvdhoorn on 2018-03-28:
I'm not saying that your approach is wrong, or that you're not correct. I'm saying that -- given my experience with humans writing computer programs -- that there may be quite some nodes that have (implicit) assumptions about how all of this works. Those may be wrong, true. I'm just trying to ..

Comment by gvdhoorn on 2018-03-28:
.. make clear that adding support for dynamically changing resolutions in a camera driver may not be all that is needed for this to work properly. You need to take the entire pipeline into account.

This is a similar discussion as with "dynamically updating robot_description".

Comment by okalachev on 2018-03-28:
Yes, this is clear. The code, I need to work with images does it correctly, with the last camera info message. The open source nodes I examined, worked the same.

Comment by fergs on 2018-03-28:
@gvdhoorn that is a great point about downstream consumers and camera_info/calibration.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.