With the recent trends for industrial applications, ROS2 is going to be used as a common “language” alternative, taking advantage of the open architecture controller (OAC) concept. However, the challenges will always be present, considering the contribution from the robot manufacturers (official) or the community (unofficial). Thus, the identification of common challenges using ROS2 to develop applications based on manipulators is important for future or current developments in the area, aiming to simplify the adoption of robotics tools based on open-source initiatives.
In my experience, I find these challenges most concerning:
- Debugging: in general having lots of nodes interacting with other nodes, debugging one of them is not super easy (especially if you’re trying to fix a race condition or a deadlock). Pyhton is not too bad, but with C++ is quite a hurdle to set up the environment to debug a node.
- Output terminal: also related to debugging, the terminal is flooded with information, and when something crashes is not always obvious which node failed, and why (in our configuration, one node dying kills all the others)
- Too many parameters and config files: this provides a powerful framework, but a simple config change must be set across different files, and it’s easy to forget one of them.
- Motion planning: it’s difficult to get a motion planner (for manipulators) that works out of the box in complex scenarios, and it takes a lot of time to carefully adjust the parameters to optimize the results (especially when doc for those parameters is bad/outdated/non-existant)
1 Like