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

Revision history [back]

It is possible for a process to spawn another process (see man 3 exec on Linux). A (better, IMHO) alternative is using the appropriate API to start/stop the recording from the initial process.

Launch file can only spawn ROS binaries (a binary located in a ROS package) but it is trivial to wrap any binary into a ROS binary. Python SubProcess can help here or you can also use the "system" function call.

A more general comment is: in ROS, a classical method for designing an infrastructure is:

  1. Launch all the nodes. They start in an "idle" state where they do nothing.
  2. Under an external event (like the reception of a request from some kind of supervisor), they will start working (in this case recording).

In this case, you really have two layers with a one way communication. The ROS Launch layer and the nodes layer. There is no way to "communicate" with ROS launch or making it do smart stuff such as stopping nodes on an event.

IMHO this is not a limitation and ROS launch is very well as it is, but it forces you to adopt the previously described point of view when you design your own architecture :)

It is possible for a process to spawn another process (see man 3 exec on Linux). A (better, IMHO) alternative is using the appropriate API to start/stop the recording from the initial process.

Launch file can only spawn ROS binaries (a binary located in a ROS package) but it is trivial to wrap any binary into a ROS binary. Python SubProcess can help here or you can also use the "system" function call.

A more general comment is: in ROS, a classical method for designing an infrastructure is:

  1. Launch all the nodes. They start in an "idle" state where they do nothing.
  2. Under an external event (like the reception of a request from some kind of supervisor), they will start working (in this case recording).
  3. Under another external even the behavior may be stopped and restarted but the node never die.

In this case, you really have two layers with a one way communication. The ROS Launch layer and the nodes layer. There is no way to "communicate" with ROS launch or making it do smart stuff such as stopping nodes on an event.

IMHO this is not a limitation and ROS launch is very well as it is, but it forces you to adopt the previously described point of view when you design your own architecture :)

It is possible for a process to spawn another process (see man 3 exec on Linux). A (better, IMHO) alternative is using the appropriate API to start/stop the recording from the initial process.

Launch file can only spawn ROS binaries (a binary located in a ROS package) but it is trivial to wrap any binary into a ROS binary. Python SubProcess can help here there or you can also use the "system" function call.

A more general comment is: in ROS, a classical method for designing an infrastructure is:

  1. Launch all the nodes. They start in an "idle" state where they do nothing.
  2. Under an external event (like the reception of a request from some kind of supervisor), they will start working (in this case recording).
  3. Under another external even the behavior may be stopped and restarted but the node never die.dies.

In this case, you really have two layers with a one way communication. The ROS Launch layer and the nodes layer. There is no way to "communicate" with ROS launch or making it do smart stuff such as stopping nodes on an event.

IMHO this is not a limitation and ROS launch is very well as it is, but it forces you to adopt the previously described point of view when you design your own architecture :)