ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
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:
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 :)
2 | No.2 Revision |
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:
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 :)
3 | No.3 Revision |
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:
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 :)