Revision history [back]

Decoupling handling incoming msgs from actually processing them is an often used approach in ROS. Your cb can just append incoming msgs to a queue, which a separate thread processes. You could also think about adding a time or length field to your msgs, to syn processing to time.

Decoupling handling incoming msgs from actually processing them is an often used approach in ROS. Your cb can just append incoming msgs to a queue, which a separate thread processes. You could also think about adding a time or length field to your msgs, to syn sync processing to time.

I understand that callbacks should not be blocked, but I really can't see any other way to do this. I've update the question with more information.

Decoupling handling incoming msgs from actually processing them is an often used approach in ROS. Your cb can just append incoming msgs to a queue, which a separate thread processes. You could also think about adding a time or length field to your msgs, to sync processing to time. Provided enough accuracy (and synchronised clocks), you'd end up with a sort-of trajectory.

Edit:

[..] Essentially I have to manually jog the robot by small increments when the first message is sent until the next message is sent.

That last line suggests a state machine: NOT_JOGGING and JOGGING. The output of the state machine would be determined by the state. The transition between the states is then guarded by your input msgs. Seems straightforward enough to me?

Edit2:

So essentially create a secondary thread that monitors some global variables and sends the necessary jog commands to the robot. And have the cb just update those variables.

Depends on how 'clean' you want this. You could use a producer-consumer pattern between your state machine (SM) and your node. The SM then consumes incoming events as part of its update loop. Transitions are triggered based on input in the queue, etc. Callbacks write events to SM queue.