Revision history [back]

I don't want the node to process images when the robot is moving. so this parameter is there so i can tell the node "now i want you to actually process an image"

It would appear that you have the following situation:

1. camera (driver) that continuously publishes sensor_msgs/Image messages to a topic
2. physical camera is mounted on the robot EEF
3. image processing should happen only when requested

The question you posted seems to be an example of an xy-problem: you're asking about a detail of a solution you've picked, instead of about the actual problem.

I would propose to implement what you describe in the following way:

1. write a service or action server and expose a ProcessImage service or action (I would suggest to use a more descriptive name, this is of course just an example)
2. in the service/action callback, use rospy.wait_for_message(..) (docs) to retrieve a single Image from the camera stream
3. process the image according to whatever parameters have been passed as part of the service request or the action goal
4. return the result of the processing to the caller

Such a setup would seem to cover all your requirements: it only processes images when requested and it only works on the "latest data".

In addition it doesn't require any bookkeeping in your node, no disabling of callbacks, no queue_size tweaking, does not poll the parameter server at a high frequency and uses appropriate communication patterns for the interaction between service consumer and provider.

I don't want the node to process images when the robot is moving. so this parameter is there so i can tell the node "now i want you to actually process an image"

It would appear that you have the following situation:

1. camera (driver) that continuously publishes sensor_msgs/Image messages to a topic
2. physical camera is mounted on the robot EEF
3. image processing should happen only when requested

The question you posted seems to be an example of an xy-problem: you're asking about a detail of a solution you've picked, instead of about the actual problem.

I would propose to implement what you describe in the following way:

1. write a service or action server and expose a ProcessImage service or action (I would suggest to use a more descriptive name, this is of course just an example)
2. in the service/action callback, use rospy.wait_for_message(..) (docs) to retrieve a single Image from the camera stream
3. process the image according to whatever parameters have been passed as part of the service request or the action goal
4. return the result of the processing to the caller

Such a setup would seem to cover all your requirements: it only processes images when requested and it only works on the "latest data".

In addition it doesn't require any bookkeeping in your node, no disabling of callbacks, no queue_size tweaking, does not poll the parameter server at a high frequency and uses appropriate communication patterns for the interaction between service consumer and provider.

I don't want the node to process images when the robot is moving. so this parameter is there so i can tell the node "now i want you to actually process an image"

It would appear that you have the following situation:

1. camera (driver) that continuously publishes sensor_msgs/Image messages to a topic
2. physical camera is mounted on the robot EEF
3. image processing should happen only when requested

The question you posted seems to be an example of an xy-problem: you're asking about a detail of a solution you've picked, instead of about the actual problem.problem. The answers you receive are then focused on the implementation detail, instead of the bigger picture.

I would propose to implement what you describe in the following way:

1. write a service or action server and expose a ProcessImage service or action (I would suggest to use a more descriptive name, this is of course just an example)
2. in the service/action callback, use rospy.wait_for_message(..) (docs) to retrieve a single Image from the camera stream
3. process the image according to whatever parameters have been passed as part of the service request or the action goal
4. return the result of the processing to the caller

Such a setup would seem to cover all your requirements: it only processes images when requested and it only works on the "latest data".

In addition it doesn't require any bookkeeping in your node, no disabling of callbacks, no queue_size tweaking, does not poll the parameter server at a high frequency and uses appropriate communication patterns for the interaction between service consumer and provider.

There does not seem to be a need to store Images at all in the service provider, nor is there a need to be notified of each and every message that gets published to the camera's topic. If the camera driver was not publishing continuously, this would be a different matter, but as it stands now I believe sampling a single message from the continuous stream whenever it is needed makes the most sense.