Reference frame of visual odometry

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Reference frame of visual odometry

dmkarage
Hi,

I am trying to compare the localization accuracy between RTAB-Map with only visual odometry (xtion pro used) and  wheel odometry on a Tiago robot. I know that I cannot combine them without an EKF. However I would like to see how close these two odometries are. The "world" reference frame for wheel odometry is the frame at the starting position in which i turn on the robot, called "odom". Could you let me know which one is the "world" reference frame of Rtab-Map's visual odometry? It seems that visual odometry computes a relative displacement rather than a displacement with respect to a "fixed" frame. Is there a way to set as reference frame for the visual odometry the very same "world" frame of the wheel odometry?

Thank you in advance
Reply | Threaded
Open this post in threaded view
|

Re: Reference frame of visual odometry

matlabbe
Administrator
Hi,

If wheel odometry and visual odometry are initialized at the same time, they should start on the same pose (Identity transform).

It is also possible to reset visual odometry at a specified pose, see reset_odom_to_pose service in Visual Odometry section.

Not sure what your /world reference means, but if you are going to compare two odometries at the same time (showing both TF at the same time in RVIZ), the TF tree would look like this:
      /------>/base_link_wheel (transform published by wheel odometry)
     /
/odom 
     \
      \------->/base_link (transform published by visual odometry) -----> /camera_link ----> /camera_rgb_optical_link
 
The trick is to initialize visual odometry intial pose (/odom -> /base_link) to same value than the wheel odometry (/odom -> /base_link_wheel) using the service above.

cheers,
Mathieu
Reply | Threaded
Open this post in threaded view
|

Re: Reference frame of visual odometry

dmkarage
Hi Matlabbe and thank you for your answer,

I see the trick now. However I would like this service to be called every time that I start Rtabmap, as the robot can be at a random position in the map. So I want Rtabmap and wheel odometry to start at the  same pose. How can I do that? Where should I call the service?

Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: Reference frame of visual odometry

matlabbe
Administrator
Hi,

You may create a Service Client node that could do something like this:
1- Sleep 5-10 sec at start (to make sure that all nodes are started on roslaunch)
2- Subscribe to TF "/odom -> /base_link_wheel"
3- Call service /rtabmap/reset_odom_to_pose of type rtabmap_ros::ResetPose with the previous transform (to transform TF quaternion to roll/pitch/yaw, see here)

cheers,
Mathieu
Reply | Threaded
Open this post in threaded view
|

Re: Reference frame of visual odometry

dmkarage
Hi Matlabbe,

once again thanks for the reply. I still have troubles to fully understand where the visual odometry is calculated. If for example i set "frame_id = base_link", does it mean that the algorithm thinks that the camera is mounted on the base_link, or it  calculates the visual odometry on the actual camera frame and then does the transformation to the base_link?

kind regards
Reply | Threaded
Open this post in threaded view
|

Re: Reference frame of visual odometry

matlabbe
Administrator
Hi,

For a TF configuration like this and frame_id=base_link:
/base_link -> /camera_link -> /camera_rgb_optical_link

Odometry will transform 3D points seen in the camera frame /camera_rgb_optical_link into /base_link frame, then do computation. So yes, in a way it "thinks" that the camera is on /base_link. You will get /odom -> /base_link. Note that if TF between /base_link and /camera_link changes (e.g., the head of the robot turns and the camera is on it), the 3D points will still be correctly transformed in /base_link frame (the odometry will not turn if /camera_link is turning and not /base_link).

If frame_id=camera_link, you will get /odom -> /camera_link, which is wrong as /base_link is the fixed frame. Well, the frame_id should be the main fixed frame of the robot (in some examples it is /base_footprint).

cheers,
Mathieu