hellantos
commented
1 year ago @livanov93 sorry did not yet add any license as you can see in the files. Did not want to step on anyone's feet here and would not merge it as is. We actually implemented this because we were testing our 6 axis robot with it and activation just gets nasty and kind of unstable with single device controllers. I also heard that some people are already using the control stack with their devices. As I could not foresee if we do breaking changes, I started a new/copy interface. In the end we can merge and maybe deprecate the others at some point or bring over the features to the other interfaces and kill the new one.
Robot System Interface Yes, we could add these features in CIA402System or CANopenSystem. However, the bigger goal is to move from an inheritance to a composition approach for the hardware interface (one interface that covers all device types). This is not yet done here and we only focussed on CIA402 devices, because we need them for tests. In the end the robot system interface should read the urdf and check which node_ids are indicated per joint. Then fetch the right driver type from bus.yml and use that for casting and handling.
Robot Controller (probably obsolete): We thought the robot controller should take care of bringing up the robots drives and settting the correct operation mode on activation. After discussion with Denis, I learned that this should rather be done automatically in hardware interface using perform_switch_mode and on_activate. So in the end the robot controller is obsolete and will be integrated into the system interface. Also the whole mode switching stuff in the other controllers should be obsolete.
General observations reagrding controllers and driver nodes:
- The driver nodes provide debugging functionality, diagnostics etc (services etc. for writing to the nodes manually). These should not be duplicated by a controller.
- The controllers should serve a specific purpose (i.e. forward_command_controller, ...)
- It is possible to use a controller as a kind of driver via the sdo/pdo interfaces that are in the CANopenSystem interface, but this should only ever be done for very simple devices. The cannonical way would be implementing a driver in the ros2_canopen framework.
This pull request redesigns the ros2_control infrastructure, as a number of short comings have appeared during testing with real robots.
There is a need for a robot controller. The device controller is nice, but only interesting for very small setups. A robot system interface that automatically makes all drives of the robot ready to use is necessary.