Download as a PDF

to grab an image and process some of it at 60 fps with a latency of less
than two frames image processing was the most likely cause of the latency.
Of course, locating the ball with two frames latency is not running all of
vision with 2 frames latency.
Having determined that the latency problem was not hardware
I was faced with a very important decision. The code for the Vision
2002 was very large and was able to run RoboCup Main Vision, a Ball
Vision system and RoboFlag Vision. It also had a complex Graphical User
Interface with a number of threads running simultaneously. In addition,
the documentation of this code was minimal and not very comprehensive.
I could spend my time fixing and documenting the Vision 2002 system
or I could develop a new system. Vision 2002 did work and with some
investigating it might be possible to locate the latency problem if it was
in an algorithm. On the other hand, if the problem was because of its
architecture or graphical user interface (GUI) it would be very hard to
locate and correct without making major changes. It was this uncertainty
in the cause of the latency that resulted in my decision to develop a system
from the ground up using the Vision 2002 system as much as possible.
I began to add components of the Vision 2002 system to the vision
test environment that I wrote to test the latency of the system. I timed
each piece of code to see how long it took and also the latency of the
complete test environment. With every Vision 2002 component that was
added, the processing time began to creep closer to the absolute limit of
16 ms but the latency remained below 2 frames. Finally when I attempted
to segment four colors the latency of the system became unstable and the
time of the loop was just over 16 ms. The cause the latency was known
for certain. Vision 2002 did too much processing of the image; it would
have to be reduced to reduce the latency of the system.
Knowing the cause of the problem was just the beginning.
iv