ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

API for changing a camera resolution

asked 2018-03-27 05:31:10 -0500

okalachev gravatar image

updated 2018-03-27 05:32:20 -0500

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?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
3

answered 2018-03-27 17:54:55 -0500

fergs gravatar image

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).
edit flag offensive delete link more

Comments

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 ..

gvdhoorn gravatar image gvdhoorn  ( 2018-03-28 02:21:41 -0500 )edit
1

.. 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.

gvdhoorn gravatar image gvdhoorn  ( 2018-03-28 02:22:28 -0500 )edit

When you use subscribeCamera, you get updated image and cameraInfo message in your callback at the same time. So this is OK.

okalachev gravatar image okalachev  ( 2018-03-28 04:39:07 -0500 )edit

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?

gvdhoorn gravatar image gvdhoorn  ( 2018-03-28 04:40:35 -0500 )edit
1

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.

okalachev gravatar image okalachev  ( 2018-03-28 04:46:17 -0500 )edit

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 ..

gvdhoorn gravatar image gvdhoorn  ( 2018-03-28 04:53:44 -0500 )edit

.. 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".

gvdhoorn gravatar image gvdhoorn  ( 2018-03-28 04:54:46 -0500 )edit

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.

okalachev gravatar image okalachev  ( 2018-03-28 05:15:28 -0500 )edit

Question Tools

3 followers

Stats

Asked: 2018-03-27 05:31:10 -0500

Seen: 1,108 times

Last updated: Mar 27 '18