[HeRos] Adjustment with FPS

This morning, I’ve implemented a function which counts the number of frames sent to the phone. I was with the format QCIF and I saw 14 fps. Flo was so surprised that he decided to count on the phone. And with no surprise he found 14 fps. The video is good but not fluid at all.

The first way of getting frame and sending to the phone was :
– a thread asks the dcmi to get a frame then he waits
– an other thread takes the image and sends it to the phone then he waits

We would like to implement a double buffers. The purpose is to get a frame with the DCMI while the last image was sent (at the same time). It was not so hard but a little other change made my life harder. I firstly removed (in the dcmi driver function) the second buffer for the DMA since I always called the function and used only the first one. But with that code, it was working for a time (for 1s to 10s ) however then the thread was blocked for ever. And it was really hard to follow it with GDB. That the reason why I took so much time today on the fps…

For a conclusion, we made test with 27 fps from the camera (I am now able to count the fps from the camera without counting it with the logic analyzer == usefull) :
– In QCIF : we have 20-22 fps
– In CIF : we have 14 fps (the uart is not enough fast)

When we overuse (or just try) the fps can be quiet good but there are a lot of chance to have a failure (2 or 3 times less fps) or even wifi deconnection.

Eric

[HeRos] Sweet Camera

Today, no big image any more but a lot of small ones! I started the day by rewriting my code. I changed the organization and I added a lot of functions in the shell. Through the shell you are able now to change the size (even during streaming!!), to send the images to the wifi or to the computer and to stop/start capture of one or many images.

Today seems easy but during the whole afternoon, I was under the pressure of Flo. Since I was rewriting my code, I made some mistakes and I finished with delay. In the beginning of the afternoon, Flo was able to display the images on the smartphone. But it didn’t look fluid, normal it was 7 fps ^^.  My new mission was to set all the formats (Smaller than CIF 352×288) with a frequency bigger than 24 fps (but not too much, baud rates are precious).

Around 6pm, it was done, we were able to stream with a fluid video! I finished the day with merging my work in Development and I change the code to be “Plug and Play” and thus I play since … battery died 🙂

Tomorrow, we will present our first prototype

Eric

[HeRos] Improve the camera capture

Yesterday, I’ve found a new source in internet which provides the registers to set in order to get bigger screen. I’m not able to capture 800×600 or 1600×1200.

http://sourceforge.net/p/nuttx/git/ci/a72d404bf6ca85b27f74d93ee901ff35db57703f/tree/nuttx/drivers/video/ov2640.c
The quality is good :

First medium capture

Captured with the ov2640

When I got this picture, I immediately try the full size 1600×1200. I receive something but I lost the beginning of the frame (\ff\d8). However, I still can find the end of the trame in the output hex files.
The difficulty was that the picture was too pig to stay in the two buffers and the dma overwritten the first buffer when it finished to fill the second.
It was time to use the interrupt callback. There are two callbacks :

  • DMA callback : every time a buffer is filled (first or second) this function is called
  • Frame end callback : when a frame is totally captured

At every DMA callback, an another thread is in charge to send the buffer 1 or 2 through the serial port. When the Frame End callback is called, I send the last buffer.

The result is not perfect :

Image in HD

Biggest size with the ov2640

PS : I can send through the serial port which goes to the wifi. But I suspect that the android app are not able to print all the jpeg received. The same picture stay at the screen. I have tested yesterday that every capture is different.

[HeRos] Faster camera configuration

This morning, I asked myself why I needed 10 seconds to configure the camera. After looking with the logic analyzer, I saw that the SCCB communication used a 250 Hz frequency.

Flo explained to me that chThdWaitMicroseconds doesn’t work in ChibiOS. Thus, the minimum wait time is 1 ms. Charles had the same problem yesterday. In order to wait a smaller time, he used GPT.

I changed the driver to wait a smaller time with GPT. Now, the time to configure the camera is reasonable.

Here the file : https://gist.github.com/Morikko/523c4e8a5bc85ceef224

 

[HeRos] Sick and late…

Hello,

I’m still working on the camera. Today, I configured the camera in JPEG mode. I used the same source as Julien.

http://tech.munts.com/MCU/Frameworks/ARM/stm32f4/libs/STM32F4xx_DSP_StdPeriph_Lib_V1.1.0/Project/STM32F4xx_StdPeriph_Examples/DCMI/DCMI_CameraExample/

However, my pixel clock is not at 24 MHz like the input clock but around 7.7 kHz.

I speak with Julien and he said that he has made some adaptations. I will see with him tomorrow to know what kind of adaptation.

Since last week end, I’m ill. Thus, I’m always tired. I am becoming late on the camera. I am expecting that tomorrow the disease will be over. I want to come back in order to attack the last week of ROSE.

Good night 🙂

New eye

We started the day by understanding the LIN protocol. We will use it to communicate between the robot and the extarnal module. I firstly chose just a mono jack with 2 wires. Samuel and Alexis told us that it would be easier to split the data and the power supply. As a consequence, we have changed for stereo jack with 3 wires. The unit in the external module is a ATtiny87.

Another surprise, Samuel try the WiFi chip. Bad news, the driver is not finished. We can’t use the SPI for transferring data, we have to use the serial port for controlling order and transferring data.
Goodbye the 10M/s, we have to analyze the camera again.

Firstly, we have chosen a GumStix Caspa VL. However, the resolution is 752×480 and each pixel contains 10 bits.
752*480*10 =3,609,600 bits for just one image !! Moreover flo sent a mail on the GumStix mailing list, he asked how we can manage the problem with the STM32F4 processor. In five minutes, he got the answer: that it’s too difficult! Let’s find an other camera.

Welcome to the new camera: OV2640. On top of that, the OV2640 camera supports JPEG. Thus, we will have lighter picture 🙂
A project using a OV2640 with a STM32F4 : openMV

Eric