ROS2 SDK Server

Hello everyone :slight_smile:

I am currently working on Reachy with the ROS2 driver. Here is what i get when running the ros2 service list command:


Some services mentioned in are not present in the above list. For example, I don’t see the service called StreamFullBodyCartesianCommands (which could be really useful for my application).
I am thus wondering if it is normal or not ? The reachy_sdk_server folder is located in my reachy_ws/src folder and I pulled recently the github repo to be sure to be up to date.
If I am not mistaken, all the services, nodes and topics are initialized when turning on the computer. Or should we call a specific command to make available the so called GRPC services handled ?

The Reachy I am working with is originally a 2019 version, but the software was updated by pollen robotics recently while the hardware still mainly corresponds to a 2019 version. Could this be the reason explaining why some of these services are not available ?

Thank you in advance,

Hi Romain,

That’s normal, StreamFullBodyCartesianCommands is a grpc service that we use for the Python and C# SDK and not a ROS service. The list of service showed in the readme of reachy_sdk_server is a list of grpc services.

What would you want to do with your application? Maybe we can help you!

Hi Simon and thank you for your answer, I understand better now !

So if we want to have a ROS high level service similar to the StreamFullBodyCartesianCommands grpc service that, sets the joints to the requested positions given targets in cartesian coordinate system, we need to implement it by ourselves by calling one by one the appropriate and provided Reachy ROS2 driver services, topics etc ?

Moving the head given a x, y, z cartesian coordinate would then requires for example to call the service look_vector_to_quaternion, then use the outputed quaternion to call the head inverse kinematics service to get the corresponding neck disk positions, then call the set_joint_compliancy service to set each disk non compliant and finally publish to the topic joint_goals the neck disk positions obtained with the head inverse kinematic service. Am I right ?


Or maybe an even simpler way would be to create a service running reachy sdk python code directly. Would it be possible to connect to reachy inside a service callback using the ReachySDK class ?


Hi Romain,

To answer your questions one by one.


Yes exactly. That is actually what the look_at method from ReachySDK is doing.

I don’t know if it’s possible but I wouldn’t recommend doing that. ReachySDK is on top of all the ROS stuff so using it at the same level as ROS would probably cause issues.

Maybe the thread System Architecture Overview could give you a better understanding of how Reachy’s software is organised !

1 Like

Got it, thank you for your help :slight_smile:



I implemented something similar to the StreamFullBodyCartesianCommands grpc service and I have now new questions for you :smiley:

The first one is about the control of the velocity of the movements. I’ve seen on the documentation that one can specify a speed limit of the motors in rpm. How can we specify this in ROS ? When publishing a JointState message on the joint_goals topic, I tried to specify the velocity field (in rad/s) but it seems to have no impact on the resulting movement of Reachy. I’ve seen that the goto function of the reachy sdk server allows to specify the duration of a motion which is in a way related to its velocity. However this high level function is quite different as, if i’m not mistaken, its a set of consecutive small movements to follow an interpolated trajectory. In that case, I would assume that the control of the duration of the overall trajectory is made by changing the time between all the small movements, I am right ?

The second question is about the inverse kinematics services of the head and the arms. When I call the inverse kinematics service of the arm, I can directly use the response of this service as a message to publish on the joint_goals topic. Basically, i can do this:

msg = IK_arm_response.joint_position

However, this does not work with the head. The reason is that the orbita inverse kinematics service return a response where the name array is [“disk_top”, “disk_middle”, “disk_bottom”] while the joint_goals topic accept the name array [“neck_disk_top”, “neck_disk_middle”, “neck_disk_bottom”]. Thus I have to do:

msg = IK_head_response.disk_position

// correction of the name array = [“neck_disk_top”, “neck_disk_middle”, “neck_disk_bottom”]

Is it done on purpose or is it a bug ?

Thank you again for your precious help.