Subscribe To Robotics | IntroDuction | History | Home

Friends Dont Forget To check the archieve at the left end of the page

Make Your Own Robot Tutoials

Simple Beetle Bot | Wired Robot | Combat Robot | Solar Engine |

Beam Symet | Photopopper | Beam Trimet | Line Follower |

Latest Updates
Driver Less Car | I-Sobot | MotherBoard | MicroController | Artificial Brain |

Camera Sensors Hardware | Remote Control Working


Sunday, April 6, 2008

Camera Sensor Hardware

In recent years we have experienced a shift in camera sensor technology. The previously dominant CCD (charge coupled device) sensor chips are now being overtaken by the cheaper to produce CMOS (complementary metal oxide semiconductor) sensor chips.

The brightness sensitivity range for CMOS sensors is typically larger than that of CCD sensors by several orders of magnitude.For interfacing to an embedded system, however, this does not make a difference. Most sensors provide several different interfacing protocols that can be selected via software.

On the one hand, this allows a more versatile hardware design, but on the other hand sensors become as complex as another microcontroller system and therefore software design becomes quite involved. Typical hardware interfaces for camera sensors are 16bit parallel, 8bit parallel, 4bit parallel, or serial.

In addition, a number of control signals have to be provided from the controller. Only a few sensors buffer the image data and allow arbitrarily slow reading from the controller via handshaking. This is an ideal solution for slower controllers. However, the standard camera chip provides its own clock signal and sends the full image data as a stream with some frame-start signal. This means the controller CPU has to be fast enough to keep up with the data stream.

The parameters that can be set in software vary between sensor chips. Most common are the setting of frame rate, image start in (x,y), image size in (x,y), brightness, contrast, color intensity, and auto-brightness. The simplest camera interface to a CPU is shown in Figure below.

The camera clock is linked to a CPU interrupt, while the parallel camera data output is connected directly to the data bus. Every single image byte from the camera will cause an interrupt at the CPU, which will then enable the camera output and read one image data byte from the data bus Every interrupt creates considerable overhead, since system registers have to be saved and restored on the stack.Starting and returning from an interrupt takes about 10 times the execution time of a normal command, depending on the microcontroller used. Therefore, creating one interrupt per image byte is not the best possible solution. It would be better to buffer a number of bytes and then use an interrupt much less frequently to do a bulk data transfer of
image data.

Figure below shows this approach using a FIFO buffer for intermediate storing of image data. The advantage of a FIFO buffer is that it supports unsynchronized read and write in parallel.So while the camera is writing data to the FIFO buffer, the CPU can read data out, with the remaining buffer contents staying undisturbed.The camera output is linked to the FIFO input, with the camera’s pixel clock triggering the FIFO write line. From the CPU side, the FIFO data output is connected to the system’s data bus, with the chip select triggering the FIFO read line. The FIFO provides three additional status lines:

• Empty flag

• Full flag

• Half full flag

These digital outputs of the FIFO can be used to control the bulk reading of
data from the FIFO. Since there is a continuous data stream going into the
FIFO, the most important of these lines in our application is the half full flag,
which we connected to a CPU interrupt line. Whenever the FIFO is half full,
we initiate a bulk read operation of 50% of the FIFO’s contents. Assuming the
CPU responds quickly enough, the full flag should never be activated, since
this would indicate an imminent loss of image data.

No comments: