Velocity when robot is moving and person is steady

[lcluz]

Hi again :) I'm having another problem and this time with the velocities that come from the tracker. What is happening is that when a person is steady and the robot is moving, it assumes that the person is moving, probably because the position on base_link frame changes. since everything is calculated in this frame. Right? Is this possible? Can you help in any way, saying how to overcome this?

Thank you very much.

Luís

[lucasb-eyer]

Which tracker are you using? bayes_people_tracker or mdl_people_tracker?

[cdondrup]

Bayes people tracker with his own detector.

The problem is, as you said the base_link. The easiest way of overcoming this is to create a map and choose /map as the frame of reference. Currently, the ego motion of the robot is not considered using the tracker other than by using a static tf frame. Instead of /map you could also try your odometry frame which is stationary (if you do not reset it at runtime) as well.

[lcluz]

Ok, that's what I thought. But I think I read that no matter what the frame is, the calculations are always done on "base_link" frame, am I wrong? Another way i thought could help overcome this problem is subtracting the robot's velocity to the velocity that the tracker is outputting. Does this make sense?

[cdondrup]

The velocity should be based on the difference in position of the human from t_n to t_{n+1}. So using /map or /odom should prevent this. I know that I have a hard coded base_link in there (shame! :bell: :bell: :bell:) but that is only for the distance between the robot and the human afaik. I am currently at a conference so don't really have the means/time to look into this. From the 5/9, I could have a look why that is.

However, I am 90% sure that the velocity should be ~0 when using map. It will never be exactly 0 due to the update frequency of tf but should be rather close. If you can't get it to work, I'll have a look in a few days.

[lcluz]

What I did was changing the target_frame param to "/map", but it seems that is still applying the filter on base_link. What i did was: private_node_handle.param("target_frame", target_frame, std::string("/map")); and change my detections from base_link to map. should be only this, right?

[cdondrup]

Normally, you don't have to change your detections. If they are in base_link, then they will be transformed to what ever you set in the target_frame by the tracker. If they are in base_link and you just change the frame id to map, then the system assumes they are in map but they are actually in base_link. So make sure that the framed_id of your detector message correctly reflects the origin coordinate system of your detections and let the tracker transform them to map. If you, for example, use a laser based detector, you can user the laser frame. Just make sure it is correctly displayed in rviz using the correct frame.

If you do not have a map, use /odom

[lcluz]

What I mean changing my detections is transforming them from base_link to map, so everything is already in the right frame_id when entering the tracker. By changing the target frame to /map I still have the same thing as before. What comes out of the tracker is still on /base_link frame.

[lcluz]

What I'm getting in the topic /people_tracker/people is still on /base_link frame_id, even if i change the target_frame to /map.

header: seq: 6810 stamp: secs: 1472549074 nsecs: 596731901 frame_id: /base_link people:

• name: c1279c0b-8693-5cc0-abb2-68f62de71548 position: x: 1.04233826326 y: -0.561836417343 z: 0.0 velocity: x: -0.103574421128 y: -0.134073609083 z: 0.0 reliability: 1.0 tagnames: ['uuid'] tags: ['c1279c0b-8693-5cc0-abb2-68f62de71548']

[cdondrup]

OK, I'll have a look at that next week.

[lcluz]

Well...I was not changing the target_frame param in the roslaunch. I only changed it in your code, thinking that it was hard coded. My bad, I'm sorry for bothering you. Thanks for the quick replies. :) you can close this.

Luís

[cdondrup]

Even better. Glad you found it :) Let me know if anything else is amiss.