interaction-lab / interaction-lab/HARMONI
Global rosparam/namespace refactor
- Dominant language
- Python
- Stars
- 10
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Description
We are using global rosparams in many instances where we should be using rosparams which are relative to some namespace (nodes and groups can have their own namespaces in launch files).
> Names that start with a "/" are global -- they are considered fully resolved. Global names should be avoided as much as possible as they limit code portability.
[Namespace Reference](http://wiki.ros.org/Names)
[Useful overview of roslaunch structure recommendations](http://wiki.ros.org/roslaunch/Tutorials/Roslaunch%20tips%20for%20larger%20projects)
_For example:_
When services are instantiated they often have an `/instance_id` rosparam in their launch file or in their code. The problem is, if two services somehow launch at the same time, they could overwrite each other's rosparam value (race condition) resulting in possible instancing bugs.
Similarly, we are often setting custom parameter names for each service instead of using the most obvious name and making it relative to the namespace of that service.
Fixing this issue will require a refactor of many of the main() functions in nodes and their associated launch files. A correct example is provided in the `harmoni_face_detector` service. **In addition, the use of a constants file for Namespaces should be refactored. The Namespaces can be stored in launch files or possibly a global launch include.**
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.