local cost map screwed up when camera moves down

[mzillich]

Hi,
when the camera starts moving down (after looking at people), the cost map gets a huge obstacle, which seems to be just the floor. Could this be related to tilt angles not being synchronised with octomap somewhere?

[ghost]

Hi Michael,

I guess it is. I noticed the same problem during the rehearsal at IPA in March. The only idea I had at that time was to increase the update frequency of the costmaps, which is set to 5.0Hz (there's a parameter called update_frequency in _{global,local}costmap_params.yaml). I haven't tried at IPA and unfortunately I can't from here right now because I don't have the motor for the kinect link. Just to let you know, I'm not sure whether this works or not because the system now is designed to stop updating the costmap when the angle of the kinect (as recorded in the dynamixel_msg) is different from the navigation angle. It might be, that there are some delays in subscribing to that message/updating due to the complexity of the nav stack, and this is enough to produce that. It can also depend on the quality of the calibration of the kinect though.

[mzillich]

Hi,
ok, we will do a better kinect calibration. But this really seems to be about the dynamics.
Do you need the angle to be equal to navigation angle?
Maybe it is better if the tilt controller somehow issues a message "kinect not moving", and this then is the OK for updating.

[ghost]

We decided to set a navigation angle because it is better to prevent the robot to update the costmap while the kinect is tilting up and the humans are interacting. It's better to have a good view of the floor to properly add and clear obstacles, which is not the case of the kinect tilted up.

Maybe instead of a navigation angle we can set a range...

[ipa-rmb]

Has this already been resolved now?