ICub + Gazebo + joint states on ROS1

[omareldardear]

as requested by @pattacini
I write the issue here.

Bug description
I am trying to have the joint states (iCub Gazebo)published on ROS and visualizing it on Rviz Following what is mentioned in the documentation
-> https://icub-tech-iit.github.io/documentation/icub_ros/#what-is-ros-tf
and the README on icub-models
-> https://github.com/robotology/icub-models/blob/master/iCub_manual/ros/README.md

I am not really familiar with the process, so I am not sure if I missing something or if there is a bug.
I have added the wrapper line in the configuration file of yarprobotinterface (no_legs.xml)
<xi:include href="wrappers/motorControl/icub_ros_wrapper.xml" />

no topics appeared on ROS

Thanks in advance.

Steps to reproduce
OS: Ubuntu 20.04
ROS1 Noetic
Superbuild: v2024.08.0
Gazebo 11
Using the following process

ROS_MASTER_URI set correctly on bashrc

$roscore
$yarpserver --ros
$gazebo
Placing iCub Model -> iCubGazeboV2_5 (no_hands)
$yarprobotinterface --context gazeboCartesianControl --config no_legs.xml
$rostopic echo

no topics for iCubSim here

Additional context
no_legs.xml

<device name="torso" type="remote_controlboard">
    <param name="remote"> /icubSim/torso </param>
    <param name="local"> /gazeboCartesianControl/torso </param>
    <param name="writeStrict"> on </param>
</device>

<device name="left_arm" type="remote_controlboard">
    <param name="remote"> /icubSim/left_arm </param>
    <param name="local"> /gazeboCartesianControl/left_arm </param>
    <param name="writeStrict"> on </param>
</device>

<device name="right_arm" type="remote_controlboard">
    <param name="remote"> /icubSim/right_arm </param>
    <param name="local"> /gazeboCartesianControl/right_arm </param>
    <param name="writeStrict"> on </param>
</device>

<xi:include href="./cartesian/left_arm_cartesian.xml" />
<xi:include href="./cartesian/right_arm_cartesian.xml" />


 <!-- ROS -->
<xi:include href="wrappers/motorControl/icub_ros_wrapper.xml" />

[martinaxgloria]

Hi @omareldardear, thanks for opening this issue!

As @pattacini said, we don't support ROS1 any longer since it is almost EOL. Unfortunately, the documentation you read is a bit outdated and we plan to revise it in order to update the instructions to use our robots with the newer ROS2. As soon as we have completed this activity, we will let you know so you can provide us with your feedback on that. Thank you so much for your support and collaboration!

In the meantime, if it is somehow related to what you were looking for, you can rely on the README.md of this repository in which some instructions to use YARP-based robots with MoveIt 2: this is a really useful tool for ROS2 to do motion planning, kinematics, control, and so on. Moreover, in the README.md you can find some example to be run that explains better the potentiality of this tool

If you have any further questions, please don’t hesitate to ask.

[plinioMoreno]

Hi all,

Do you have a broad estimate on when you will have YARP-ROS2 support available?

[traversaro]

Hi all,

Do you have a broad estimate on when you will have YARP-ROS2 support available?

Hi @plinioMoreno, most of the YARP-ROS 2 compatibility has been developed in the form of Network Wrapper Server (NWS) or Network Wrapper Clients (NWC) devices that write or read information from ROS 2 topics and make them available via the C++ YARP devices interfaces, and this functionality is provided in https://github.com/robotology/yarp-devices-ros2, that saw its first release today: https://github.com/robotology/yarp-devices-ros2/releases/tag/v1.0.0 . The yarp-devices-ros2 is a dependency of this repo, and the plan is to integrate it in the 2024.11.0 release of the robotology-distro (that realistically will be released in the first half of December 2024), where robotology/robotology-superbuild#1746 is a preliminary draft PR of this integration.

Note that due to the fact that ROS 2 (differently from ROS 1) is based on an abstraction layer (rmw) that abstract the detail of the underlying protocol actually used for communication, no work on using the YARP library and API to write on the ROS 2 topics is planned, as it was instead the case for the TCPROS (the protocol underlying ROS 1) implementation available in yarp itself.

Is this the YARP-ROS2 support you had in mind, or you were thinking of something else?

[plinioMoreno]

Hi @traversaro, the work you have been doing seem to cover most of the use-cases that we have for our robot Vizzy (right arm and left arm). In fact, the availability of the ros2_control interface is great. Since the ros2_control is attached to the control hardware, I guess that you will not be able to control from YARP and ROS at the same time, right?

I am asking this because of the special case of the iKinGazeController of Vizzy. Currently, we have an actionlib server (implemented in ROS1) for controlling the gaze point, and we interface with YARP by writing to the port /iKinGazeCtrl/xd:i. If we follow the same approach on ROS2, we don't want to have the head motors available on ros2_control, do we? But from the rviz visualization point of view, we want to be able to "read" the motors' encoder values and publish the values in the joint_states topic.

What I see from the yarp-devices-ros2, you have to implement a specific interface for each type of message, so we will have to implement an NWS or NWC according to the type of message.

The only use-case from our side that is not covered, is the simple Server Service that we implemented to move the arms down of our robot. We will have to implement it as a regular NWS, but from the ros view would not be a service, but a node that receives a pre-defined message that triggers the arms down action.

Thanks for the detailed answer!

[martinaxgloria]

Hi @plinioMoreno!

Since the ros2_control is attached to the control hardware, I guess that you will not be able to control from YARP and ROS at the same time, right?

If I understood your question, you can use YARP and ros2_control at the same time. In fact, the nws/nwc for yarp are organized into separate wrappers (for example controlBoard_nws_yarp and controlBoard_nws_ros). In this way, you can attach multiple wrappers to the same device,so you can have a wrapper for yarp and another one for ros2, include them to the same configuration file you use to launch the yarprobotinterface and have both the controls at the same time.

If we follow the same approach on ROS2, we don't want to have the head motors available on ros2_control, do we? But from the rviz visualization point of view, we want to be able to "read" the motors' encoder values and publish the values in the joint_states topic.

Yes, you can have a mixed approach.

What I see from the yarp-devices-ros2, you have to implement a specific interface for each type of message, so we will have to implement an NWS or NWC according to the type of message.

In yarp-devices-ros2 you can find some implemented ros2 nws/nwc (here you can find some documentation) and some custom msgs and srv to communicate with the yarp layer

The only use-case from our side that is not covered, is the simple Server Service that we implemented to move the arms down of our robot. We will have to implement it as a regular NWS, but from the ros view would not be a service, but a node that receives a pre-defined message that triggers the arms down action.

From the ros2 side, if you want to use xcub_moveit2 to do this kind of action, you can use some examples you can find in the repo as a starting point. For example, in the README.md use case you can find the instructions to launch two basic demos (grasp and circle). These movements are actually planned and executed in the cartesian space using TRAC-IK as the IK solver and are implemented as a ros2 node that receives a pose to be reached in space and uses the rviz MotionPlanning plugin to trigger the action from the rviz GUI

Please, let me know if I misunderstood your questions or if you have further curiosities don't hesitate to ask