1 \documentclass[a4paper,oribibl
]{llncs
}
6 \title{Speeding up a Digital Camera
}
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
}
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.
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.
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.
46 \section{Introduction
}
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
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
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.
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.
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.
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.
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
}}}}$
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$ \\
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 \\
113 Cycles per pixel &
230 &
459 &
918 &
1861
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.
127 \centering \includegraphics[height=
3cm
]{ball_072
}
128 \caption{Example image taken with the EyeCam
}
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
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.
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.
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
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) \\
169 Parport pin &
{\sc strobe
}(
1) &
{\sc slctin
}(
17) &
{\sc init
}(
16)
170 &
{\sc busy
}(
11) &
{\sc ack
}(
10)
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.
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
189 \section{The
{\sc fifo
}}
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.
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
209 \includegraphics[height=
3.5cm
]{fifo-simple2
}
210 \caption{Outline of
{\sc fifo
} buffer
}
211 \label{fig:fifo-outline
}
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.
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
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.
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.
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.
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
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
}
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.
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.
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.
298 \begin{minipage
}[c
]{0.5\textwidth}
299 \centering \includegraphics[height=
3.5cm
]{fifo-side
}
301 \begin{minipage
}[c
]{0.5\textwidth}
302 \centering \includegraphics[height=
3.5cm
]{fifo-back
}
304 \caption{Camera and
{\sc fifo
} test board
}
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
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
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.''
331 and were thus unable to investigate any further. Our local
332 distributor could not help us at all.
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
346 \includegraphics[height=
1.5cm
]{bad-read-shape
}
347 \caption{The not too square
{\sc autofdxt
} read shape
}
348 \label{fig:bad-shape
}
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.
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
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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.
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
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.
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.
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:
479 \item[{\tt int CAMRawFrameSize(void)
}]
481 Get the size of the raw camera frames. This size would be different
482 for different camera types.
484 \item[{\tt int CAMPutBuffer(BYTE *buffer)
}]
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
490 \item[{\tt int CAMBufferReady(void)
}]
492 Return true (
1) if one complete image is available, and false (
0) if
495 \item[{\tt BYTE *CAMGetBuffer(void)
}]
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
502 \item[{\tt CAMBuffer2ColImage(BYTE *buffer, colimage *cimg)
}]
504 Convert one raw camera frame to the standard
24 bit image format.
506 \item[{\tt int CAMRelease(void)
}]
508 Stop the camera and disable parport interrupt.
512 A user application could then use double buffering and avoid any
513 unneeded pixel copying with C source like this:
516 int buffersize = CAMRawFrameSize();
517 BYTE *buffer1 = malloc(buffersize);
518 BYTE *buffer2 = malloc(buffersize);
519 /* Initialize camera and prepare double buffering */
521 CAMPutBuffer(buffer1);
522 CAMPutBuffer(buffer2);
524 if (CAMBufferReady())
{
525 BYTE *rawframe = CAMGetBuffer();
526 /* process raw frame */
527 CAMPutBuffer(rawframe);
535 \section{Conclusion and future work
}
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
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
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.
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.
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.
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.
576 \begin{thebibliography
}{}
578 \bibitem[VV6300
]{vlsi:vv6300
}
580 VV6300, Low Resolution Digital CMOS Image Sensor (
1998).
582 \bibitem[AM7203A
]{amd:am7203a
}
583 Advanced Micro Devices:
584 Am7203A, High Density First-In First-Out (FIFO)
2048x9Bit CMOS
587 \bibitem[ST16C552
]{startech:st16c552
}
589 ST16C552, Universal Asynchronous Receiver/Transmitter with FIFO and
590 Parallel Printer Port with Power Down Capability (
1996).
592 \bibitem[EyeCam
]{mcalpine:eyecam
}
594 Image Processing and CMOS Camera Integration with the EyeBot
595 Platform, Honours Dissertation (
1999).
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
}
602 \bibitem[CPU32
]{mc68300:cpu32
}
604 M683000 Family CPU32 Central Processor Unit Reference Manual (
1990).
606 \bibitem[StrongARM
]{intel:sa1100
}
608 Intel StrongARM SA-
1100 Microprocessor for Portable Applications (
1999)
610 \end{thebibliography
}
612 \section*
{Acknowledgments and contact information
}
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.
620 Thanks to Ken Cormack at STMicroelectronics for valuable information
621 on the VV6300 sensor, despite the company policy to not help the low
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
}.
628 Information on the EyeCam and the Eyebot is available from\\
629 \url{http://www.ee.uwa.edu.au/~braunl/eyebot/
}.
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.
639 From: Gerhard Kraetschmar <gkk@acm.org>
640 Date: Thu,
22 Jun
2000 23:
33:
16 +
0200
641 Message-Id: <
3952861C
.22CE96DD@acm.org>
643 Subject: Notification of Workshop RoboCup-
2000 submission
647 we regret to inform your paper has not been accepted for presentation
648 at the RoboCup-
2000 Workshop.
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
653 We had a large number of high quality submissions and an acceptance
654 rate of about
30% for oral presentation.
656 Reviews of your articles are attached below.
658 We look forward to a very exciting and successful workshop and
659 sincerely hope that you will be able to attend.
662 Peter, Tucker, and Gerhard
664 ==============================================================
665 RoboCup
2000 Paper Review Form
668 Title: Speeding up a digital camera
669 Authors: Reinholdtsen, Humble
673 ___ Accept ___ Marginal accept ___ Marginal reject X Reject
675 Confidence in your recommendation:
676 X High ___ Medium ___ Low
678 Is the paper a good fit to the symposium?
679 ___ Yes ___ Somewhat X No ___ Unsure
681 Is the work sufficiently novel to warrant publication?
682 ___ Yes X Somewhat ___ No ___ Unsure
684 Does it provide a reasonable amount of detail for a workshop paper?
685 ___ Yes X Somewhat ___ No ___ Unsure
687 Are the implementation and experimentation sufficient? (if
688 applicable) Keep in mind that the paper may describe work in
690 ___ Yes X Somewhat ___ No ___ Unsure
692 Are the technical sections well-formed and accurate?
693 ___ Yes X Somewhat ___ No ___ Unsure
695 Is the presentation well organized?
696 ___ Yes ___ Somewhat X No ___ Unsure
698 Is the literature survey adequate for a conference paper?
699 ___ Yes ___ Somewhat X No ___ Unsure
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.
709 When revising this paper, what do you think the author(s) should give
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.
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.
722 ==============================================================
724 ==============================================================
725 RoboCup
2000 Paper Review Form
727 Please return your reviews by June
5th,
2000 to gkk@acm.org
730 Title: Speeding up a digital camera
731 Authors: Reinholdsten, Humble
738 ___ Accept ___ Marginal accept ___ Marginal reject x___ Reject
740 Confidence in your recommendation:
741 x___ High ___ Medium ___ Low
743 Is the paper a good fit to the symposium?
744 ___ Yes ___ Somewhat x ___ No ___ Unsure
746 Is the work sufficiently novel to warrant publication?
747 ___ Yes ___ Somewhat x___ No ___ Unsure
749 Does it provide a reasonable amount of detail for a workshop paper?
750 x___ Yes ___ Somewhat ___ No ___ Unsure
752 Are the implementation and experimentation sufficient? (if
753 applicable) Keep in mind that the paper may describe work in
755 ___ Yes x___ Somewhat ___ No ___ Unsure
757 Are the technical sections well-formed and accurate?
758 ___ Yes x___ Somewhat ___ No ___ Unsure
760 Is the presentation well organized?
761 ___ Yes x___ Somewhat ___ No ___ Unsure
763 Is the literature survey adequate for a conference paper?
764 ___ Yes x___ Somewhat ___ No ___ Unsure
766 What did you like best about this paper?
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.
774 When revising this paper, what do you think the author(s) should give
778 Other comments for authors (elaborate on any negative rankings above):
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 ==============================================================