Missing Local orientation per joint in the body tracking module

[Hydran00]

Preliminary Checks

• This issue is not a duplicate. Before opening a new issue, please search existing issues.
• This issue is not a question, bug report, or anything other than a feature request directly related to this project.

Proposal

Hi,
I noticed that the body tracking module shown here also provides Local orientation per joint which are needed by the application I am developing which is avatar real-time animation.

The problem is that I cannot find this variable in the topic /zed/zed_node/body_trk/skeletons. This is also confirmed by the fact that the msg definition does not show that field.

I tried the zed-unity-livelink and in the json sent by the application that variable is present, but since I need to use ROS2 I would like to know if it is possible to have this feature in the ROS wrapper.

Am I missing something?

Use-Case

No response

Anything else?

No response

[StephanHasler]

We also need the local orientation of the joints.
It would be nice, if you add it to the zed_wrapper.

We used the Kinect Azure for body-tracking under ROS1, where the orientation was included.
Now we switch to ROS2 and ZED, which is easy because of the nice zed_wrapper.
But we would need the orientation for our applications.

[Myzhar]

This feature is on the agenda, but it's currently a low priority and not scheduled due to the minimal demand. The ZED SDK contains this information; you can alter the ZED ROS2 Wrapper code to enable this feature if you require it soon.

[StephanHasler]

Thanks for your reply. I just added it to the wrapper. It works. I get the local and global orientation(s).
I can contribute the code. More crucial is of course, to discuss where to best store the data inside the Object message.

Currently, I defined a Quaternion message and then added to the skeleton3d something like:
zed_msgs/Quaternion orientation[70]

Just tell me, when help is needed!

[StephanHasler]

I decided to use some ROS standard types in the Object message now:

# 6D pose of each joint relative to its parent joint
geometry_msgs/Pose[70] local_joint_poses

# 6D global pose
geometry_msgs/Pose global_root_pose

One could also include the joint_poses in world/camera coordinates.
Currently, one has to compute that using knowledge about the kinematic chain of each joint (at least that is how I understand it).