redundant? robot description

[mhubii]

Essentially the issue is that this package contains robot description files:

https:/ARC-OPT/wbc_ros/tree/main/models

Ideally, the robot description should live separately, as this package is supposed to support any ROS capable robot, i.e. be hardware agnostic.

This issue is further reflected in the configurations (which assumes the ros2 launch command is run from a specific directory, this is generally not the case for overlaid workspaces etc..):

wbc_ros/config/cartesian_space_example/iiwa_controllers.yaml

Line 33 in 40ff8a3

robot_model:

I can't track down the entire rabbit hole but then this is parsed as parameter

wbc_ros/src/whole_body_controller.cpp

Line 127 in 40ff8a3

RobotModelConfig robot_model_cfg;

This can easily break stuff, while the robot description is readily available as topic through the robot_state_publisher, or should be available via get_robot_description of ControllerInterfaceBase

https:/ros-controls/ros2_control/blob/eb4c19d9edb846a3ad31b932b78339115cae52ce/controller_interface/include/controller_interface/controller_interface_base.hpp#L172

E.g. how can you guarantee that the controller manager access the same description as the controller this way?

This is how the controller should really be accessing the robot description:

https:/ros-controls/ros2_controllers/blob/57c50e584e33b316dd64801916cf6d951e0cff5b/joint_state_broadcaster/src/joint_state_broadcaster.cpp#L168C30-L168C51

Now here is a biased example (since I am the author of the package), however you could install (I understand that this isn't currently shipped under the ros index..)

https:/lbr-stack/lbr_fri_ros2_stack/

Then do a mock launch a la

ros2 launch lbr_bringup mock.launch.py \
    model:=iiwa7 \
    ctrl_cfg_pkg:=wbc_ros \
    ctrl_cfg:=config/joint_space_example/iiwa_controllers.yaml \
    ctrl:=whole_body_controller

Then run rviz

ros2 launch lbr_bringup rviz.launch.py \
    rviz_config_pkg:=lbr_bringup \
    rviz_config:=config/mock.rviz

Hardware would then automatically run via replacing mock.launch.py through hardware.launch.py. Same should apply to Universal Robots etc