[Documentation] [TitleIndex] [WordIndex

Reminder

Tips and tricks

How fast is the tracking?

Each time a new pose is computed, a new pose is published. Therefore, to see your tracking frequency you can run:

$ rostopic hz /tracker_mbt/result

There is no ideal tracking frequency as it depends on how fast your object moves. However, if the frequency is less than ~25hz, the tracking will probably fail.

The tracking initialization fails

If the initialization using the GUI fails, it is either due to the model (bad format, failed to parse...) or due the camera calibration parameters.

The tracker uses the K and P matrices information as well as the camera distorsion model. Make sure that your camera is correctly calibrated (using camera_calibration for instance). See also the message documentation sensor_msgs/CameraInfo.

The tracking fails at the first iteration after initialization

Make sure the model normals are correctly set. The tracker eliminates invisible faces. If normals are wrong, the tracker will remove all the object faces.

My tracking is too slow!

Several factors can slow down your tracking.

First, you will never be able to track at a higher frequency than the rectified image topic frequency. Tracking is only done once per image and stops until a new image is received.

Therefore, you should take a look at your rectified image topic frequency by running:

# Topic name should be changed to match the topic you use.
$ rostopic hz /camera/image_rect

Once you have checked that the tracking frequency is way lower than the rectified image topic frequency, it means that you may have problem.

Use image_transport to use compressed video streams

If the tracker is on a remote machine, you may use the additional _image_transport parameter to use compressed video streams. See image_transport documentation for more details about compressed streams.

It will reduce the amount of data passing through the network but will induce a delay in the transmission and add CPU load on the remote machine which has to compress the flow.

However, do not use it when launching the tracker node. The camera device and tracker node should be on the same machine to avoid delays and in this case, it is not necessary to compress the stream. On the opposite, it will decrease the tracking quality.

On the opposite, you can used compressed streams for the client and viewer. It is not recommended for the client as it may decrease the click precision but is highly recommended for the viewer.

The viewer ensures that the projected object pose and camera data are synchronized which mean that even if a delay is induced by the stream compression, displayed information will remain consistent.

The camera calibration is crucial

The main idea behind the virtual visual servoing is to project lines from a 3d model and compare them with the image lines. If the camera rectification is bad, it will be impossible to find a pose where the projected lines and the real one are at the same location. Therefore the algorithm will fail.


2019-10-12 13:16