AR tag tracking in ROS node works but positions are totally wack perhaps due to no depth info from my usb_cam node?

[Mark Johnston]

Incorporating the ar_track_alvar into my bot I am pleased to see the ar_pose_marker topic publishing one or more AR tags I place in front of my webcam.

My question is that I am not using my Xtion or other cam with depth info and am using the usb_cam module (explained in Patricks Ros 1 for indigo book just updated).

Although I see it correctly identify my numbers 1-8 for the AR tags the position and orientation tags seem to be junk with totally wack numbers like they are just not every updated and are junk.

Has anybody hit this and if so what info can you offer?    Thanks

Details of my Issue for those who are curious:

Platform:  BeagleBone Black on Ubuntu 14.04.1  with ROS Indigo.  (the old 32-bit ram align bugs have been fixed around Groovy if you question that so it's running ok for me)

I want to use the webcam as this is very small bot and I cannot run my power hungry Xtion.  So I am hoping somebody has done this and knows if position for at least x-y centroid is possible to get even though the webcam would not offer z info.

Specifically I am using the ar_indiv_no_kinect.launch launch which allows me to map the camera <remap from="usb_cam/image_raw" to="/camera/rgb/image_color" />

I do get the apparently 'classic' errors, one per frame from usb_cam driver that are like this but they seem 'sort of benign' and then I get an error that I think is from ar

FROM usb_cam I think:       [swscaler @ 0x6a1c0] No accelerated colorspace conversion found from yuv422p to rgb24.

FROM ar code I think:         [ERROR] [1424508775.140493951]: "camera_link" passed to lookupTransform argument target_frame does not exist.

I am able to both monitor the video and display data on my topics and control my bot from javascript interface so lots of stuff is working well, just moving forward a bit more.

Thanks

Mark Johnston

[Patrick Goebel]

Hi Mark,

The" lookupTransform" error was due to the fact that in the
usb_cam.launch file, the camera frame was set to "head_cam" instead of
the more generic "camera_link". I have updated that launch file in the
rbx1 repository to use "camera_link" instead. Please do a "git pull" in
your rbx1 repository to get the update. No need to do a catkin_make
afterward.

Having said all that, I just tried the ar_indiv_no_kinect.launch file
with my USB camera and an AR tag that works fine with my Xtion camera
and I got the same null result that you did. So I don't have an answer
for you and you might try posting an issue on
https://github.com/sniekum/ar_track_alvar/issues.

--patrick

[Mark Johnston]

Thanks Patrick.   The mod you mention does remove the one error but still I don't get x or y or orientation in any way yet it finds tags nicely (rotated or not).

I have posted a question here:    https://github.com/sniekum/ar_track_alvar/issues/43

Mark 

[Mark Johnston]

Scott replied that simple webcam would be fine to still offer x and y and orientation so that is my main concern.   

The active ar_track_alvar thread on github  with more of my input and making mention of Patrick's quick test can be found here:

https://github.com/sniekum/ar_track_alvar/issues/43#issuecomment-75451809

His reply make me question if usb_cam node is mis-configured on my end or if I should maybe try the older  uvccam (or similar name which I had bad luck with before).

Scott thinks maybe TF tree connecting camera frame and output frame may be bad that leads to my issue (in his words as seen later in this post)

In a quick test by Patrick, he notes he is also seeing null values for x and y from usb_cam so that is maybe the issue here.

I think there is more to the exact format of camera_link or some other subtle settings issue for both myself and Patrick's quick test he replies to below

Scott's reply on github thread mentioned earlier in this post:

Actually, ar_track_alvar uses the size/distortion of the tag in the image
to calculate depth of the tag, even without a kinect. So you should be
getting a fully 6-DOF pose estimate. Hard to say what is wrong though from
the limited info I have about your situation. Sounds like something might
be wrong in the TF tree connecting your camera frame and output frame.