[billbo911]

Originally Posted by Jared Russell

....

A common use-case for an onboard camera is for automated alignment to a vision target. In this case, the target is not moving and (in theory*) you only need a single image to compute the transform between your robot and the target. Once you have computed this transform, you can use other sensors (ex. gyro) to close the loop. Camera-in-the-loop control schemes suffer from latency, low (control) bandwidth, and timing jitter, whereas using the camera to derive a setpoint for faster sensors sidesteps these problems.

* In practice, multiple sources of error (intrinsic and extrinsic calibration of the camera, detection errors, robot odometry errors) will mean that you probably want to take a sequence of frames as you turn/move towards the target and iteratively refine your estimate of where the target is.

If I remember correctly, this is exactly how the example vision code for Breakaway operated under LabView.
It acquired a single image. Then it located the concentric circles in the image. Then it calculated how many degrees off center the center of the circles was.
It then passed that number of degrees to a second control loop that rotated the robot the given number of degrees using a gyro as feedback. This process was then repeated until the number of degrees error, as provided by the image processing loop, was smaller than a given threshold.
This iterative process, quite often, could be performed in a single pass if the rotating control loop was calibrated properly.