ros4hri / hri_fullbody

A ROS4HRI-conformant node to track and extract 2D and 3D skeletons of humans from RGB/RGB-D cameras
Apache License 2.0
12 stars 4 forks source link

3D Skeleton not Detected #1

Closed Darken23 closed 1 year ago

Darken23 commented 1 year ago

Hi i get a "No transform from [body_rluhf] to [head_rluhf]" eg in the 3D Skeleton Plugin. in

I have installed hri_msgs,hri_rviz,human_description,libhri,pyhri packages manually.

The commands i run are: roscore rosrun usb_cam usb_cam_node /usb_cam/image_raw:=/camera/color/image_raw /usb_cam/camera_info:=/camera_info roslaunch hri_fullbody hri_fullbody.launch rviz

In the terminal i get "It was not possible to estimate body position." error This is the output i get in rviz:

Screenshot from 2022-11-08 14-03-26

LorenzoFerriniCodes commented 1 year ago

Hi @Darken23,

It might be a problem related to your camera calibration. Is the camera you're using properly calibrated? You can check it reading what's published on the camera info topic (i.e., /camera/color/camera_info in your case): if the K, R and P matrices are all 0s, then you should be able to solve the problem calibrating the camera.

Darken23 commented 1 year ago

Hi @LorenzoFerriniCodes u were right i was getting 0 matrices.I calibrated my camera using a chessboard paper,and the result was better,i was able to see the human urdf but i was getting responce movement only from my legs.What's the ideal option at fixed frame?

LorenzoFerriniCodes commented 1 year ago

Good to know that you got better results @Darken23!

About the fixed frame: there's not really a good option or a bad option. If you want to visualise the 3D skeleton it needs to be a frame that's in the same frame tree as the body one: for instance, common choices are the robot base link frame or the camera link.

About the non-responsive behaviour from the upper body: which version of ikpy have you installed? I noticed some months ago that with version 3.3 there was a non-responsive behaviour for the upper body (here the issue I opened). If you currently have the 3.3 version try with a previous one (for instance, ikpy 3.2.2 is working for me) and let me know if that solves your problem :)

Darken23 commented 1 year ago

Thank you @LorenzoFerriniCodes the ikpy version fixed the upper body movement.I dont see the camera_link option at fixed frame.Also should i be able to move around in rviz cause the urdf can only stay still at the moment. This is the output: Screenshot from 2022-11-10 16-58-35

LorenzoFerriniCodes commented 1 year ago

Great @Darken23!

The Skeleton is not moving as the reference frame you set in rviz is the body frame and a body never moves with respect to itself. Since you're using the usb_cam node, you should be able to generate a camera frame by setting the camera_frame_id parameter when starting the node, for instance: rosrun usb_cam usb_cam_node /usb_cam/image_raw:=/camera/color/image_raw /usb_cam/camera_info:=/camera_info camera_frame_id:=usb_cam

Then, setting usb_cam as fixed frame, you should be able to visualise the body displacement.

Darken23 commented 1 year ago

I tried it but in my case i think it is ~camera_frame_id (string, default: "head_camera").I selected head_camera fixed frame and i could move around the rviz but the rotation was wrong: Screenshot from 2022-11-11 14-13-44

Fixed it adding static_transform_publisher in the launch file and changed the roll argument

LorenzoFerriniCodes commented 1 year ago

Sorry for the late answer!

Exactly, the transform is expressed with respect to an optical frame (that is, your camera optical frame). The body frame z axis and camera optical frame y axis are always supposed to be parallel.

Darken23 commented 1 year ago

Thank you @LorenzoFerriniCodes you have been a big help to me.