ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

It is very likely that the monocular odometry of libviso2 does not work in your environment as it lacks features on the ground and your camera performs pure rotations without translation.

Monocular odometry and SLAM systems cannot estimate motion or position on a metric scale. All estimates are relative to some unknown scaling factor. libviso2 overcomes this by assuming a fixed transformation from the ground plane to the camera (parameters camera_height and camera_pitch). To introduce these values in each iteration the ground plane has to be estimated. That is why features on the ground are mandatory for the odometer to work.

Roughly the steps are the following:

  1. Find F matrix from point correspondences using RANSAC and 8-point algorithm
  2. Compute E matrix using the camera calibration
  3. Compute 3D points and R|t up to scale
  4. Estimate the ground plane in the 3D points
  5. Use camera_height and camera_pitch to scale points and R|t

In your case the odometer will fail at point 4. Unfortunately libviso2 does not provide sufficient introspection to signal this error to the user.

Another problem occurs when the camera performs just pure rotation: even if there are enough features, the linear system to calculate the F matrix degenerates.

To solve your problem you could either make sure that your environment has enough features and that your robot does not perform pure rotations or use a SLAM system such as PTAM which keeps a history and can use this to localize the camera in situations where no new 3D points could be calculated due to F matrix degeneration. A third option would be to use a stereo system with the stereo odometry of libviso2 as this does not need to estimate the ground plane and works for pure rotations, too.

Be aware that libviso2 was designed for wide angle cameras mounted on cars. I will add that information to the wiki to clarify these limitations.

It is very likely that the monocular odometry of libviso2 does not work in your environment as it lacks features on the ground and your camera performs pure rotations without translation.

Monocular odometry and SLAM systems cannot estimate motion or position on a metric scale. All estimates are relative to some unknown scaling factor. libviso2 overcomes this by assuming a fixed transformation from the ground plane to the camera (parameters camera_height and camera_pitch). To introduce these values in each iteration the ground plane has to be estimated. That is why features on the ground are mandatory for the odometer to work.

Roughly the steps are the following:

  1. Find F matrix from point correspondences using RANSAC and 8-point algorithm
  2. Compute E matrix using the camera calibration
  3. Compute 3D points and R|t up to scale
  4. Estimate the ground plane in the 3D points
  5. Use camera_height and camera_pitch to scale points and R|t

In your case the odometer will fail at point 4. Unfortunately libviso2 does not provide sufficient introspection to signal this error to the user.

Another problem occurs when the camera performs just pure rotation: even if there are enough features, the linear system to calculate the F matrix degenerates.

To solve your problem you could either make sure that your environment has enough features and that your robot camera does not perform pure rotations or use a SLAM system such as PTAM which keeps a history and can use this to localize the camera in situations where no new 3D points could be calculated due to F matrix degeneration. A third option would be to use a stereo system with the stereo odometry of libviso2 as this does not need to estimate the ground plane and works for pure rotations, too.

Be aware that libviso2 was designed for wide angle cameras mounted on cars. I will add that information to the wiki to clarify these limitations.