]> pere.pagekite.me Git - homepage.git/blob - mypapers/eyecam-fifo/eyecam-fifo.tex
A bit more.
[homepage.git] / mypapers / eyecam-fifo / eyecam-fifo.tex
1 \documentclass[a4paper,oribibl]{llncs}
2
3 \usepackage{graphicx}
4 \usepackage{isolatin1}
5
6 \title{Speeding up a Digital Camera}
7 \date{2000-05-01}
8 \author{Petter Reinholdtsen \and Stephen T. Humble}
9 \institute{University of Western Australia\\
10 Mobile Robots Lab at The Center for Intelligent Information Processing}
11
12
13 % Make sure \href works in play LaTeX as well.
14 \def\hyperlink#1#2{\special{html:<a href="\##1">}#2\special{html:</a>}}
15 % Incorrect link name in \TeX\ because # can't be passed properly to a special.
16 \def\hypertarget#1#2{\special{html:<a name="#1">}#2\special{html:</a>}}
17 \def\email#1{\special{html:<a href="mailto:#1">}#1\special{html:</a>}}
18 \def\newpage{\special{html:<hr>}}
19 \long\def\tthdump#1{#1} % Do nothing. The following are not done for TtH.
20 \tthdump{%
21 \def\title#1{\bgroup\leftskip 0 pt plus1fill \rightskip 0 pt plus1fill
22 \pretolerance=100000 \lefthyphenmin=20 \righthyphenmin=20
23 \noindent #1 \par\egroup}% Centers a possibly multi-line title.
24 \let\author=\title % Actually smaller font than title in \LaTeX.
25 \input epsf % PD package defines \epsfbox for figure inclusion
26 % Macro for http reference inclusion, per hypertex.
27 \def\href#1#2{\special{html:<a href="#1">}#2\special{html:</a>}}
28 \def\urlend#1{#1\endgroup}
29 \def\url{\begingroup \tt
30 \catcode`\_=13 % Don't know why this works.
31 \catcode`\~=11 \catcode`\#=11 \catcode`\^=11
32 \catcode`\$=11 \catcode`\&=11 \catcode`\%=11
33 \urlend}% \url for plain \TeX.
34 }
35
36 \begin{document}
37 \maketitle
38
39 \begin{abstract}
40 To get real time performance when connecting the EyeCam, a VV6300
41 digital camera to the parallel port of the Eyebot with a reasonable
42 slow MC68332 CPU, we added flow control by designing a first in
43 first out buffer to put between the camera and the CPU.
44 \end{abstract}
45
46 \section{Introduction}
47
48 The Eyebot is a Motorola 68332 based robot controller with on-board
49 camera support and various input and output connections available.
50 Initially it used grey scale and color QuickCams. When Connectix
51 introduced QuickCam VC without releasing the protocol specification
52 and hence made it impossible to write drivers, an alternative was
53 needed.
54
55 The solution was designing the EyeCam, specially made for the Eyebot
56 and giving much better image quality. The problem was that the frame
57 rate dropped to 3.7 frames per second. The reason for this is that
58 the EyeCam lacks flow control, and the CPU must synchronize with the
59 camera to read the data. This results in approximately 20.000
60 interrupts for every frame, one for every byte transfered from the
61 camera. The EyeCam is capable of running at 60 frames per second, but
62 this speed was to fast for the CPU. Processing one interrupt takes to
63 long, and the data presented by the camera is no longer there when the
64 CPU tries to read.
65
66 Several solutions to this problem was suggested, among these where
67 connecting the camera directly to the memory bus, dual ported memory
68 and adding flow control using a digital {\sc fifo}. This paper
69 describes the last solution.
70
71 \section{The camera}
72
73 The EyeCam is made from the VISION VV6300 CMOS Image sensor
74 \cite{vlsi:vv6300} and a small support circuit to connect it to the
75 parallel port (parport). The camera sensor is no longer produced and
76 will be replaced with VV6301. The two sensors are supposed to be
77 compatible. As we don't have a VV6301 sensor yet, all our tests are
78 done with the older VV6300.
79
80 Configuration is done using serial communication on pin {\sc scl} and
81 {\sc sda}. Frame start is signaled on the falling edge of pin {\sc
82 fst} and every byte is signaled ready on the falling edge of pin
83 {\sc qck}. The frequency of {\sc qck} is specified using a clock
84 divider, and the camera is capable of up to 60 frames per second.
85
86 The camera frame rate is controlled using a clock divisor given as
87 $2^n$. This clock divisor sets the pixel frequency as shown in table
88 \ref{table:clock-divisor}. With our camera setup, the {\sc qck}
89 signal will qualify data on the falling edge with this frequency. If
90 we assume equal spacing between rising and falling edge, the period
91 $t$ between falling and rising edge on {\sc qck} can be found from the
92 frequency $f_{\mathrm{{\sc qck}}}$ in Hz: $t = {1 \over
93 2f_{\mathrm{{\sc qck}}}}$. We verified the assumption by checking
94 the {\sc qck} signal with an oscilloscope.
95
96 The number of CPU cycles $c$ available to read out the data before
97 they disappear is then easily calculated using this period $t$ and the
98 CPU frequency $f_{\mathrm{{\sc cpu}}}$ in Hz: $c = {t \times
99 f_{\mathrm{{\sc cpu}}}}$
100
101 \begin{table}
102 \centering
103 \caption{Camera timings with 14.318 MHz crystal and 8 bit mode}
104 \label{table:clock-divisor}
105 \begin{tabular}{r|r|r|r|r}
106 Clock Divisor & $2^0$ & $2^1$ & $2^2$ & $2^3$ \\
107 \hline
108 Data rate (kHz) & 895 & 448 & 224 & 112 \\
109 Frame rate (fps) & 29.99 & 15.01 & 7.5 & 3.75 \\
110 Data present $t$ (ns) & 559 & 1120 & 2230 & 4460 \\
111 Cycles data present $c$ & 19 & 39 & 78 & 156 \\
112 \hline
113 Cycles per pixel & 230 & 459 & 918 & 1861
114 \end{tabular}
115 \end{table}
116
117 Table \ref{table:clock-divisor} show the results for the possible
118 clock divisors, assuming CPU running at 35 MHz. When we know that the
119 CPU32 platform uses up to 92 cycles to enter and 24 cycles to exit the
120 interrupt handler \cite{mc68300:cpu32}, and the original optimized
121 EyeCam driver \cite{mcalpine:eyecam} uses 78 cycles to process one
122 byte, it is quite impressive that the original EyeCam driver is
123 working. It is also obvious that there is no way to increase the
124 frame rate above 3.7 with the current driver design.
125
126 \begin{figure}
127 \centering \includegraphics[height=3cm]{ball_072}
128 \caption{Example image taken with the EyeCam}
129 \label{fig:outview}
130 \end{figure}
131
132 The camera supports two image formats ($160 \times 120$ and $164
133 \times 124$), different transfer modes and 4 and 8 bit pixel sampling.
134 Each color pixel is the result of combining four camera pixels, one
135 red, two green and one blue byte. One image is thus approximately 20
136 kB.
137
138 {\sc qck} and {\sc fst} can be configured in different modes to change
139 which edge qualifies the data, and whether control information should
140 be qualified as well. The image byte size (as qualified by {\sc qck})
141 will change when the mode changes. We found the image size to be
142 20336 bytes when only image data is qualified and 22352 bytes when
143 both control and image data are qualified.
144
145 We run the camera in max resolution and 8 bit pixel sampling. The
146 frame rate can be doubled by using 4 bit pixel sampling, but when we
147 tried to use this mode at 3.7 frames per second, the pixel noise made
148 the images useless. We do not know why and have not yet tried using
149 the 4 bit mode at other frame rates.
150
151 The limited processing speed of the current Eyebot platform is a real
152 challenge. Still assuming 35 MHz CPU speed, and image size at $82
153 \times 62$ pixels, the number of cycles available to process one pixel
154 at $r$ frames per second is given by the following formula: $n =
155 {f_\mathrm{{\sc cpu}} \over {82 \times 62 \times r}}$. The inspiring result
156 is available in table \ref{table:clock-divisor}. When we know that
157 CPU32 instructions uses approximately 10 cycles to complete on the
158 average, real time image processing with even 1861 cycles seems a bit
159 hard.
160
161 \begin{table}
162 \centering
163 \caption{Camera to PC parallel port control connections}
164 \label{table:connections}
165 \begin{tabular}{r|r|r|r|r|r|r}
166 Camera pin & {\sc scl}(1) & {\sc sda}(14) & {\sc sin}(11)
167 & {\sc fst}(12) & {\sc qck}(10) \\
168 \hline
169 Parport pin & {\sc strobe}(1) & {\sc slctin}(17) & {\sc init}(16)
170 & {\sc busy}(11) & {\sc ack}(10)
171 \end{tabular}
172 \end{table}
173
174 The camera control pins are connected to the parport as described in
175 table \ref{table:connections}. The parport is set up to generate
176 interrupts and {\sc qck} is connected to {\sc ack} to trigger the
177 interrupt when data is ready.
178
179 While working with the {\sc fifo}, we discovered a design flaw in the
180 EyeCam. The PC parport interrupt is triggering on the rising edge
181 (0V$\rightarrow$5V) of {\sc ack}, while the camera qualifies data on
182 the falling edge (5V$\rightarrow$0V) of {\sc qck}. We are not quite
183 sure why the camera could work anyway, and intend to do some testing
184 as soon as we find time. The easiest way to test this would be to
185 swap {\sc fst} and {\sc qck}, and run the camera in a different mode
186 where {\sc fst} is the inverted {\sc qck}. We have not investigated
187 this any further
188
189 \section{The {\sc fifo}}
190
191 The basic idea of the {\sc fifo} buffer is to add flow control to the
192 data stream coming from the camera. The camera write data into the
193 {\sc fifo} at it's configured pace, and the CPU reads them out again
194 when it has time, and as fast as it can.
195
196 Digital {\sc fifo}s are available with different capacities and with
197 different speed requirements. We only needed to store 8 bits. The
198 {\sc fifo} access time was around 20-50 ns, with the faster {\sc
199 fifo}s being a lot more expensive than their slower alternatives.
200 Our access time requirements, as given in table
201 \ref{table:clock-divisor}, would be in the range 500 to 4500 ns. We
202 did not find any 8 bit {\sc fifo}s, and settled on a $9 \times 1024$
203 bit 55 ns access time {\sc fifo} in the IC 7200 family for our initial
204 testings. It was cheap and easily available over the counter from
205 Radio Spares.
206
207 \begin{figure}
208 \centering
209 \includegraphics[height=3.5cm]{fifo-simple2}
210 \caption{Outline of {\sc fifo} buffer}
211 \label{fig:fifo-outline}
212 \end{figure}
213
214 The {\sc fifo} has five control lines going in; read, write, reset,
215 retransmit and expand. All of these are active low. When running the
216 {\sc fifo} in single mode, we do not use retransmit ({\sc rt}) and
217 expand (XI), and these are connected to 5V and 0V respectively. The
218 first documentation we got was a bit confusing on this subject, but
219 after some testing we found this to work.
220
221 The {\sc fifo} needs to be reset before it is used, and one must make
222 sure the read and write signals are high when reset is taken low. Not
223 doing proper reset give unpredictable results and gave us a lot of
224 problems in the beginning. The {\sc fifo} has tree control lines
225 going out; empty, half-full and full. On the falling edge of the
226 half-full line, the {\sc fifo} is half full and we can start reading.
227 When the full line goes low then the {\sc fifo} is throwing away all
228 the new data.
229
230 The first design decision was how to connect the {\sc fifo}. We
231 decided to continue using the parport, to make it easier to test the
232 new buffer. This would make it possible to plug it in between the
233 current EyeCam and the parport. The next question was how to connect
234 the {\sc fifo} to the parport and the camera.
235
236 The camera side was fairly straight forward. The camera data clock
237 ({\sc qck}) needed to connect to the {\sc fifo} write pin. We needed
238 to make sure they worked with the same edge, and the documentation
239 (and the oscilloscope) told us that this was the case. The data
240 signals where connected to {\sc fifo} data pin 0-7 and the
241 configuration serial lines where connected directly to the parport as
242 before. We did not quite know how to connect the camera frame start
243 ({\sc fst}) signal, and tried various solutions. More on these later.
244
245 Reading the parport specification \cite{startech:st16c552}, we choose
246 to connect the {\sc fifo} control lines reset ({\sc rs}), read ({\sc
247 r}), empty ({\sc ef}), half-full ({\sc hf}) and full ({\sc ff}) as
248 shown on figure \ref{fig:fifo-outline}. We decided to connect camera
249 frame start ({\sc fst}) to $D_8$ and passing it though the {\sc fifo}
250 to parport {\sc busy} much later.
251
252 Our first idea for {\sc fst} was to connect it as shown on figure
253 \ref{fig:fst-init-reset}. This way the {\sc fifo} would only be reset
254 between frames if the parport {\sc init} was low. This would also
255 make sure the {\sc fifo} always started reading from the camera on
256 frame start. The only problem with using this approach would add one
257 extra chip to the buffer board, making the buffer bigger and a bit
258 more expensive, so the choice was easy when we found a way to do
259 without this chip.
260
261 \begin{figure}
262 \centering
263 \includegraphics[width=3.5cm]{fst-init-reset}
264 \caption{{\sc fst} and {\sc init} connected to {\sc rs}.}
265 \label{fig:fst-init-reset}
266 \end{figure}
267
268 We tried connecting the {\sc fst} directly to the parport {\sc busy},
269 but was unable to find the proper frame start using this approach. We
270 finally decided to connect the {\sc fst} to the extra data pin and
271 change the camera mode to toggle {\sc qck} (and therefore write)
272 during both control and image data. We later discovered that checking
273 the {\sc busy} line during read was to slow for our purposes and
274 choose a software only approach for frame synchronization.
275
276 During our initial testing we used a hand-soldered test board with a
277 1k {\sc fifo}. The initial testing went OK, but the board was fragile
278 and we often needed to re-solder broken wires. Later when we had
279 refined the design a bit, we ran into large problems getting the {\sc
280 fifo} to work properly. We believed this to come from long cables
281 and problems with {\sc fifo} reset, and where close to giving up when
282 we decided to test with another {\sc fifo} -- this time a 2k {\sc
283 fifo}. This time the board started working again, and we concluded
284 that the original {\sc fifo} was fried.
285
286 After testing the control lines and struggling with interrupts for a
287 while, we concluded that the current design should work and got our
288 local electronic workshop to make a proper {\sc fifo} test board. The
289 only hardware design-question left was where to place the connectors.
290 The obvious two options where discussed; placing it on the camera and
291 placing it on the parport. We ended up placing it on the parport to
292 avoid adding more weight to the camera. The camera connector is as
293 close to the center of the robot as possible to make sure the cable
294 would be as short as possible.
295
296 \begin{figure}
297 \centering
298 \begin{minipage}[c]{0.5\textwidth}
299 \centering \includegraphics[height=3.5cm]{fifo-side}
300 \end{minipage}%
301 \begin{minipage}[c]{0.5\textwidth}
302 \centering \includegraphics[height=3.5cm]{fifo-back}
303 \end{minipage}
304 \caption{Camera and {\sc fifo} test board}
305 \end{figure}
306
307 With a proper test board available, things worked even better. At
308 this stage we where not sure which edge would trigger the parport
309 interrupt so we included a jumper to switch from inverted and
310 non-inverted half-full flag. We later found out that the PC parport
311 trigger on the rising edge of {\sc ack}, and ended up connecting the
312 inverted {\sc hf} to {\sc ack}. The response time of the inverter can
313 be ignored, as the half-full flag is set only around 20 times per
314 frame.
315
316 We tried to use the camera chip ({\sc ce}) enable pin to stop the
317 camera from transmitting data to the {\sc fifo} when the full flag
318 came up, but this did not work. When we connected {\sc ff} to {\sc
319 ce}, only black images would come out of the camera. We tried
320 contacting VLSI Vision Ltd (which was acquired by STMicroelectronics
321 in early 1999), to ask about more details on this sparsely documented
322 part of the camera. We got one reply with valuable information, but
323 was also informed that
324
325 \begin{quote}
326 ``STMicroelectronics operates a policy of offering direct support to
327 high volume customers only. Support to low volume customers like
328 yourselves is generally supplied by local distributors.''
329 \end{quote}
330
331 and were thus unable to investigate any further. Our local
332 distributor could not help us at all.
333
334 The buffer still did not work properly. After a few seconds the
335 images would turn black, white or with a dithered pattern. When
336 checking in the oscilloscope, it seemed like the data did not make it
337 past the {\sc fifo}. The control signals worked OK, the half-full
338 flag would signal the driver as expected, but the data was missing.
339 Looking at the {\sc autofdxt} read pin, we suspected a problem with
340 the shape of the read signal. When running at full speed, the signal
341 would be too short and not very square, see figure
342 \ref{fig:bad-shape}.
343
344 \begin{figure}
345 \centering
346 \includegraphics[height=1.5cm]{bad-read-shape}
347 \caption{The not too square {\sc autofdxt} read shape}
348 \label{fig:bad-shape}
349 \end{figure}
350
351 We tried a few things to make the read signal better, but neither
352 pull-up resistors nor buffers would make it any better.
353
354 During this process we discovered another hardware bug. The Eyebot MK
355 3 has pull-up resistors on the open drain parport UART control lines.
356 It also has a pull-up resistor on parport data pin 2, as a user
357 discovered and reported. While we were checking this bug, we found
358 that this pull-up was supposed to connect to {\sc slctin}, and by
359 accident also discovered that the UART has internal pull-up resistors
360 on all the open drain lines. We removed both the bogus and the
361 duplicate pull-up resistors. This did not fix the problem with the
362 read signal.
363
364 As we knew we where pushing the limit for the parallel port, we
365 decided to try connecting the read line to one of the Eyebots digital
366 output lines. This would give us a proper square read signal and the
367 {\sc fifo} would keep working. The only problem with this approach
368 was that the digital output lines where already used for controlling
369 the wheel motors, and keeping both the camera driver and the motor
370 drivers off each others feet would be to slow.
371
372 Our next try was using one of the Eyebots TPU lines to drive the read
373 pin. These proved to be to slow. We could not get them to read out
374 from the {\sc fifo} any faster than approximately 200 kHz.
375
376 When deciding how much data to store in the {\sc fifo}, one needed to
377 think of a few things. The most important consideration is how much
378 time is needed for the CPU to start reading from the {\sc fifo}. This
379 must be less then the time it takes to fill up the second half the
380 {\sc fifo}. This time depends on the interrupt activation time, the
381 {\sc fifo} size $S_{\mathrm{{\sc fifo}}}$ and the camera write speed
382 $f_{\mathrm{{\sc qck}}}$ and should be as high as possible.
383
384 The next thing to consider is how much latency the {\sc fifo} adds to
385 the images. When the complete image has been written to the {\sc
386 fifo}, it will only be available in memory after it is read out.
387 This depends on the interrupt activation time and CPU readout speed,
388 and should be as low as possible.
389
390 To make sure the camera interrupt does not interfere with the other
391 system interrupts, one call to the interrupt handler should be as
392 short as possible, yet each call should do enough work to reduce the
393 overhead per byte transfered.
394
395 One must make sure the {\sc fifo} half-full flag is set when one image
396 is complete. When the frame size $S_{\mathrm{frame}}$ isn't a
397 multiple of half the {\sc fifo} size, the simplest way to fix this is
398 to read out the image size modulo half the {\sc fifo} size when
399 starting to read one frame. This will make sure the last half-full
400 flag is set when the last byte of the image is written to the {\sc
401 fifo}. The number of {\sc fifo} readouts and thus the number of
402 interrupts will be $\lceil {2 S_{\mathrm{frame}} \over S_{\mathrm{{\sc
403 fifo}}}} \rceil$.
404
405 \section{The driver}
406
407 We choose to implement the {\sc fifo} driver with the same API as the
408 current RoBIOS camera functions \cite{robios:library}. The API
409 consists of CAMInit() to set up the camera plus CAMGetImage() and
410 CAMGetColImage() to get a 4 bit grey scale or 24 bit color image from
411 the camera.
412
413 The camera original driver consists of two separate layers, one layer
414 is the interrupt handler fetching bytes into one ``raw'' buffer, and
415 one layer to process the ``raw'' bytes into the expected image format.
416
417 While writing the driver, we ran into a few problems. The most
418 annoying was trying to get information out of confusing and incorrect
419 documentation \cite{startech:st16c552}. It was hard to find out which
420 control lines where active low, and we ended up testing every pin.
421 The {\sc fifo} outline summarized our findings, with a line about the
422 pins that are active low.
423
424 The first prototype driver did not use interrupts, but would only
425 reset the {\sc fifo} and wait for the half-full flag to come up before
426 reading out as fast as possible. This first naive C version was able
427 to read at approximately 250 kHz, and we later managed to optimize the
428 C code to read at approximately 330 kHz. This driver would constantly
429 loose frame synchronization, as the {\sc fifo} went full between the
430 reading periods when the images where processed and displayed. To
431 solve this problem we needed to get the interrupt triggering going.
432
433 It was very hard to get the half-full flag to trigger the interrupt.
434 The first problem was finding the correct edge which triggered the
435 interrupt. When this was finally solved by adding an inverter between
436 {\sc hf} and {\sc ack}, we discovered a new problem. Even if the
437 interrupts where configured and enabled, the driver would only
438 sometimes start as it should. It was as if the first half-full signal
439 was ignored, and the driver would block forever as the {\sc fifo}
440 already was full and no new interrupt would be triggered.
441
442 The only solution to this problem was to add timeouts to the code and
443 stop the camera and reset the {\sc fifo} when a timeout occurred.
444 With this in place, the interrupts would work as expected after only a
445 few resets.
446
447 When we got the interrupt handling working, we discovered that serial
448 communication no longer worked. If we stopped the camera interrupt,
449 everything worked as normal. The current RoBIOS 3.1 API does not have
450 a function to signal that the camera is no longer needed. We suggest
451 adding a function CAMRelease() to make it possible to stop the camera
452 to save battery and stop wasting CPU-cycles processing interrupts when
453 no one will be using the images. This would also make it possible to
454 ``enable'' serial communication.
455
456 To let the camera driver handle any {\sc fifo} size, and automatically
457 detect the presence of a {\sc fifo}, we came up with the following
458 procedure. We configure and start the camera and let it fill up the
459 {\sc fifo} (with a timeout until the full flag is set). Then we stop
460 the camera and start reading out the data until the empty flag is set.
461 The number of bytes read should then be the size of the {\sc fifo}.
462 If this procedure fails, timing out while filling up the {\sc fifo},
463 or being unable to empty the {\sc fifo}, the camera is stopped and we
464 assume there is no {\sc fifo} present.
465
466 With the current API, the image data needs to be stored in a image
467 buffer before it is copied into the user supplied image buffer. The
468 current camera API also requires the image bytes to be shuffled to
469 match the 24 bit image format. To save processing time, and avoid
470 copying data, we suggest changing the API to let the user supply
471 ``raw'' image buffers which are returned when the image bytes are
472 fetched from the camera. Then it will be up to the programmer if he
473 wants to use the ``raw'' camera data or transform it into the standard
474 24 bit image format. We therefore propose the following addition to
475 the RoBIOS camera API:
476
477 \begin{description}
478
479 \item[{\tt int CAMRawFrameSize(void)}]
480
481 Get the size of the raw camera frames. This size would be different
482 for different camera types.
483
484 \item[{\tt int CAMPutBuffer(BYTE *buffer)}]
485
486 Give one memory block to the camera driver. The memory block must
487 have at least the size of the returned value from {\tt
488 CAMRawFrameSize()}.
489
490 \item[{\tt int CAMBufferReady(void)}]
491
492 Return true (1) if one complete image is available, and false (0) if
493 no image is ready.
494
495 \item[{\tt BYTE *CAMGetBuffer(void)}]
496
497 Get one camera frame from the camera driver. Block if no camera
498 frame is available yet, but there are buffers available to fill.
499 Return {\tt NULL} if there are no more raw camera frames available
500 to fill.
501
502 \item[{\tt CAMBuffer2ColImage(BYTE *buffer, colimage *cimg)}]
503
504 Convert one raw camera frame to the standard 24 bit image format.
505
506 \item[{\tt int CAMRelease(void)}]
507
508 Stop the camera and disable parport interrupt.
509
510 \end{description}
511
512 A user application could then use double buffering and avoid any
513 unneeded pixel copying with C source like this:
514
515 \begin{verbatim}
516 int buffersize = CAMRawFrameSize();
517 BYTE *buffer1 = malloc(buffersize);
518 BYTE *buffer2 = malloc(buffersize);
519 /* Initialize camera and prepare double buffering */
520 CAMInit(NORMAL);
521 CAMPutBuffer(buffer1);
522 CAMPutBuffer(buffer2);
523 while (1) {
524 if (CAMBufferReady()) {
525 BYTE *rawframe = CAMGetBuffer();
526 /* process raw frame */
527 CAMPutBuffer(rawframe);
528 }
529 }
530 CAMRelease()
531 free(buffer1);
532 free(buffer2);
533 \end{verbatim}
534
535 \section{Conclusion and future work}
536
537 Adding a simple {\sc fifo} between the EyeCam and the Eyebot improved
538 the frame rate and brought us closer to the fundamental limitations of
539 the platform. Adding flow control to the camera made it possible to
540 fetch images faster then it is possible to intelligently process them
541 on a 35 MHz CPU.
542
543 It would be possible to increase the frame rate even further by
544 connecting the {\sc fifo} directly to the CPU bus in such a way that
545 every read from the {\sc fifo} automatically strobed the read pin.
546 This way the readout speed would be limited by the speed of one
547 instruction, instead of the current approach where the read pin must
548 be manually toggled.
549
550 One way to do this is to connect the parport chip select ({\sc csp})
551 and one extra address line to the read pin in such a way that the read
552 pin goes low every time the mirrored parport data address is read.
553 This requires memory mirroring to work. We have not investigated
554 this, as it requires hardware modifications to the Eyebot controller.
555 Another approach would be to bypass the parport completely, making
556 sure the {\sc fifo} presents data on the low 8 bits on the data bus.
557
558 It might be possible to speed up {\sc fifo} reset by connecting the
559 inverted {\sc fifo} reset line to the camera soft reset (SIN) pin.
560 This way the camera and the {\sc fifo} would be reset using one pin,
561 and without the need to stop the camera. This requires that setting
562 the SIN high also sets {\sc qck} high.
563
564 Decreasing the image resolution will give more time to process each
565 pixel, and there are a few simple approaches. By changing the camera
566 mode to use ``slow {\sc qck}'', only every second byte would be
567 written to the {\sc fifo}, and the resolution would be reduced to $40
568 \times 60$ pixels. This might buy us some extra processing power.
569
570 We do however believe the only solution would be to upgrade the CPU to
571 a faster and more powerful one is the only solution to be able to do
572 real time image processing on the Eyebot. A few alternatives are
573 available, and we suggest checking out the StrongARM ST-1100
574 \cite{intel:sa1100} closely.
575
576 \begin{thebibliography}{}
577
578 \bibitem[VV6300]{vlsi:vv6300}
579 VLSI VISION Limited:
580 VV6300, Low Resolution Digital CMOS Image Sensor (1998).
581
582 \bibitem[AM7203A]{amd:am7203a}
583 Advanced Micro Devices:
584 Am7203A, High Density First-In First-Out (FIFO) 2048x9Bit CMOS
585 Memory (1992).
586
587 \bibitem[ST16C552]{startech:st16c552}
588 Startech:
589 ST16C552, Universal Asynchronous Receiver/Transmitter with FIFO and
590 Parallel Printer Port with Power Down Capability (1996).
591
592 \bibitem[EyeCam]{mcalpine:eyecam}
593 McAlpine, Paul R.:
594 Image Processing and CMOS Camera Integration with the EyeBot
595 Platform, Honours Dissertation (1999).
596
597 \bibitem[RoBIOS]{robios:library}
598 T. Bräunl, K. Schmitt, T Lampart:
599 Eyebot RoBIOS library documentation (1998).
600 \url{http://www.ee.uwa.edu.au/~braunl/eyebot/ftp/ROBIOS/library.html}
601
602 \bibitem[CPU32]{mc68300:cpu32}
603 Motorola:
604 M683000 Family CPU32 Central Processor Unit Reference Manual (1990).
605
606 \bibitem[StrongARM]{intel:sa1100}
607 Intel:
608 Intel StrongARM SA-1100 Microprocessor for Portable Applications (1999)
609
610 \end{thebibliography}
611
612 \section*{Acknowledgments and contact information}
613
614 Thanks to Thomas Bräunl, Director of the Mobile Robots Lab and creator
615 of the EyeBot robot family, for giving us the possibility to play with
616 the robots in the first place. Thanks to Klaus Schmitt for all his
617 help with the parport interrupt handling. Thanks to Ivan Naubronner
618 for giving all his help on the electronic design.
619
620 Thanks to Ken Cormack at STMicroelectronics for valuable information
621 on the VV6300 sensor, despite the company policy to not help the low
622 volume costumers.
623
624 Petter Reinholdtsen can be reached via email to
625 \email{pere@td.org.uit.no}. Stephen T. Humble can be reached via
626 email to \email{steve@newton.dialix.com.au}.
627
628 Information on the EyeCam and the Eyebot is available from\\
629 \url{http://www.ee.uwa.edu.au/~braunl/eyebot/}.
630
631 \newpage
632
633 This article was rejected when submitted for RoboCup 200 workshop.
634 Here is the rejection letter. I was initially planning to update the
635 paper based on the comments, but later discovered I would never take
636 the time required to do it.
637
638 \begin{verbatim}
639 From: Gerhard Kraetschmar <gkk@acm.org>
640 Date: Thu, 22 Jun 2000 23:33:16 +0200
641 Message-Id: <3952861C.22CE96DD@acm.org>
642 To: pere@hungry.com
643 Subject: Notification of Workshop RoboCup-2000 submission
644
645 Dear author,
646
647 we regret to inform your paper has not been accepted for presentation
648 at the RoboCup-2000 Workshop.
649
650 Because the number of submissions to this workshop has grown
651 in recent years, we have had to decline many papers that would have been
652 accepted previously.
653 We had a large number of high quality submissions and an acceptance
654 rate of about 30% for oral presentation.
655
656 Reviews of your articles are attached below.
657
658 We look forward to a very exciting and successful workshop and
659 sincerely hope that you will be able to attend.
660
661 Best regards,
662 Peter, Tucker, and Gerhard
663
664 ==============================================================
665 RoboCup 2000 Paper Review Form
666
667 Code: RK-9
668 Title: Speeding up a digital camera
669 Authors: Reinholdtsen, Humble
670
671 COMMENTS FOR AUTHORS
672 Recommendation:
673 ___ Accept ___ Marginal accept ___ Marginal reject X Reject
674
675 Confidence in your recommendation:
676 X High ___ Medium ___ Low
677
678 Is the paper a good fit to the symposium?
679 ___ Yes ___ Somewhat X No ___ Unsure
680
681 Is the work sufficiently novel to warrant publication?
682 ___ Yes X Somewhat ___ No ___ Unsure
683
684 Does it provide a reasonable amount of detail for a workshop paper?
685 ___ Yes X Somewhat ___ No ___ Unsure
686
687 Are the implementation and experimentation sufficient? (if
688 applicable) Keep in mind that the paper may describe work in
689 progress.
690 ___ Yes X Somewhat ___ No ___ Unsure
691
692 Are the technical sections well-formed and accurate?
693 ___ Yes X Somewhat ___ No ___ Unsure
694
695 Is the presentation well organized?
696 ___ Yes ___ Somewhat X No ___ Unsure
697
698 Is the literature survey adequate for a conference paper?
699 ___ Yes ___ Somewhat X No ___ Unsure
700
701 What did you like best about this paper?
702 It may be an interesting paper about designing digital cameras,
703 provided the paper is cleaned up by removing all "fairy tale" style
704 and narration about partial failures (which may be good in a tutorial
705 paper, but not in a scientific one).
706 However, the only reference to the RoboCup is the picture in fig.1,
707 whose quality is quite questionable anyway.
708
709 When revising this paper, what do you think the author(s) should give
710 highest priority to?
711 If the paper is accepted, it should definitely point out much more
712 clearly what contribution this work may provide to RoboCup teams and
713 RoboCup-related research.
714 English should also be revised.
715
716 Other comments for authors (elaborate on any negative rankings above):
717 The paper is of very marginal interest to the RoboCup community,
718 unless some specific experimentation is carried out. But that would
719 mean re-writing almost the whole paper. In this format, the RoboCup
720 workshop audience is not the right target for this paper.
721
722 ==============================================================
723
724 ==============================================================
725 RoboCup 2000 Paper Review Form
726
727 Please return your reviews by June 5th, 2000 to gkk@acm.org
728
729 Code: RK-9
730 Title: Speeding up a digital camera
731 Authors: Reinholdsten, Humble
732
733
734 COMMENTS FOR AUTHORS
735
736
737 Recommendation:
738 ___ Accept ___ Marginal accept ___ Marginal reject x___ Reject
739
740 Confidence in your recommendation:
741 x___ High ___ Medium ___ Low
742
743 Is the paper a good fit to the symposium?
744 ___ Yes ___ Somewhat x ___ No ___ Unsure
745
746 Is the work sufficiently novel to warrant publication?
747 ___ Yes ___ Somewhat x___ No ___ Unsure
748
749 Does it provide a reasonable amount of detail for a workshop paper?
750 x___ Yes ___ Somewhat ___ No ___ Unsure
751
752 Are the implementation and experimentation sufficient? (if
753 applicable) Keep in mind that the paper may describe work in
754 progress.
755 ___ Yes x___ Somewhat ___ No ___ Unsure
756
757 Are the technical sections well-formed and accurate?
758 ___ Yes x___ Somewhat ___ No ___ Unsure
759
760 Is the presentation well organized?
761 ___ Yes x___ Somewhat ___ No ___ Unsure
762
763 Is the literature survey adequate for a conference paper?
764 ___ Yes x___ Somewhat ___ No ___ Unsure
765
766 What did you like best about this paper?
767
768 I'm a hardware hobbyist, so I like the work that was done to interface
769 a digital camera to a simple microprocessor. But using a FIFO to
770 accomodate peripherals with that are asynchronous to the system bus is
771 a very standard idea. It is also not appropriate for this workshop.
772
773
774 When revising this paper, what do you think the author(s) should give
775 highest priority to?
776
777
778 Other comments for authors (elaborate on any negative rankings above):
779
780 I like the work, but it would be better suited to a hardware
781 conference specifically devoted to microprocessor issues. If you're
782 looking for a better image processor, you might try DSP chips like the
783 Analog Devices ADSP2181, which have direct DMA from external devices
784 into internal memory, and much more processing power.
785 ==============================================================
786 \end{verbatim}
787
788 \end{document}
789 % LocalWords: EyeCam