[HeRos] Last week

After a long week-end, we finally present our result to Alexis and Sam. It was good but not enough to be attractive for common usage. HeRos are able to communicate with a smartphone by WiFi, display the camera, shot trough IR. The gameplay is not enough developed and thus it is our first goal for the beginning of the week.

Three points:

  • Adapt android application design
  • Improved gameplay
  • Create HeRos identity to identify the project (logo, color, sound …)

Samuel gave us a very good advise today in order to correct the inconvenient disconnection between the HeRos and the smartphone. We currently used TCP protocol but maybe during re-send packet we lose the camera then the connection is interrupted (not closed) during 1-3s. We will implement UDP protocol to avoid re-send packet since we need the camera only at the present time.


[HeRos] ATtiny85

Today, I have flashed my first ATtiny85V with the elnec beeprog programmer. It was really easier as I expected. Now, I would like to flash my application to use it as an extern module. With the bootloader, you have a tool doing this but it is only on widows. I would like to use the uart7 to speak with the ATtiny. However, I see in ChibiOS that neither the Serial Driver neither the UART driver for the UART7 are implemented. I will see tomorrow, what is the best solution with one day left.


[HeRos] After the storm, the sun !

Today was a trying day nevertheless efficient. The reason was that we have solved two problems. The first one referred to my post of yesterday and the second one arrived just after we solved the first problem.

The first problem was that two HeRos were not able to transmit data over the UART to the Pololu. The transistor was probably damaged. We still were able to oscillate but at low frequency since the up time was very long. An other strange fact was on the voltage of the serial RX transmission. When the HeRos was connected to an USB port of the computer we had 3.3V contrary to with a Pololu where we found 2V. Alexis solved the problem by adding a pull-up to the line. Now, we set the pin as open drain and we only drive the low level. The HeRos are able to use the Pololu again.
However, one HeRos was a little bit more damaged. We were not able to drive the RX pin and the maximal voltage was 1.2V. Maybe we will look next week with Alexis in order to bring him back. By the way, we still have no idea how did the Pololu damage our HeRos.

The second problem was easier to solve and a kind of funny (when we understand it, of course). On one Pololu, the camera didn’t work any more except sometimes during a global shot. We concluded after debugging our code that it was good, on top of that the same code was working on other HeRos. We pointed out that the camera only worked when the red led 3 was lighting. After looking on the schema, we saw that the pin is between the Uart3_Rx and Uart3_CTS and we might have a contact.

With all the problems, we are delayed on the external modules but we are still good. I took pictures tonight with Charles, have fun 🙂


Global Shot Demonstration

HeRos touched by a global shot

Direct Shot Demonstration

HeRos touched by a direct shot


HeRos in darkness

HeRos in darkness


[HeRos] Saving Private Ryan

This allusion to the movie is not chance, we have lost 2 HeRos today and we are trying everything to get them back. The problem is that the UART 4 which talks to the Pololu doesn’t work any more. Thus, we are not able to send anything to the Pololu and the HeRos don’t beep or move any more.

What’s happen ?! Charles was working on IR transmission and trying the new body (by the way so sexy :D).

Firstly, just one didn’t respond. He asked Flo to look why and took an other one. However quickly the second stopped working too. As a result, we believed that the Pololu was guilty. We made some test with the oscilloscope and we saw that on the UART from the stm32 to the Pololu we had 2V instead of 3.3V. Moreover we saw that during the transmission we went to 0, but the signal had difficulty to be back high quickly. Alexandre, a member of the robotic club, were in A406 and we asked him if he understood something. He explained us that the pull up might be damaged since even at the end of a transmission the signal took too much time to be back high. In order to see the difference, I looked at the oscilloscope the UART when the baud rate was set to 6200. The voltage was still 2 V but now the signal were almost able to be high (1.8V).

Alexis advised me to test the PCB without a Pololu. I picked a cable with one side with an USB and the other side with wires in the air. I soldered the wires on the base were we put in the pololu and I made new test with the computer.

Test HeRos without Pololu

I got one good news, I have 3.3V again! But the UART still doesn’t work:

Message on UART 4

Set of messages on the UART

A message with high baud rate

A message with high baud rate

A message with low baud rate

A low baud rate message


I will ask Alexis help because I am overwhelmed.

Today, I installed a Windows Virtual Box. I need it to to use one software to flash the ATtiny with a boot loader and a second software to use the boot loader in order to flash my Application. However, I am a little confused so I will ask a teacher instead of doing a mistake.
Here links :
The machine : http://www.elnec.com/products/device-programmers/beeprog
Boot loader : http://jtxp.org/tech/tinysafeboot_en.htm

See you tomorrow with better news I hope 🙂


[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.


[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


[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.

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] Coming back with a working camera


Since Thursday night, kudly project was able to get a picture from the camera ov2640. As a consequence, I was under pressure. Quickly, I configured the camera and patched the DCMI driver (cf Julien’s posts) like the kudly project. With the logic analyzer, it seemed to work but I wasn’t sure. My biggest problem was : how to get the jpeg out of the serial port…

I used arch on the desktop computer in A406 and I was using Minicom to communicate through the serial port. Minicom is simple but not enough friendly (for me). Moreover, I was angry against arch since it always set the ttyPort with sudo permissions. After complaining to Alexis, he told me to look old mails with the keyword “udev”. And the magic was effictive,  I just had to add rules to udev to set the ttyACM0 port with no sudo permissions.

The first image was not get with mine computer but flo computer. On his mac, he used coolterm which allows to save/see the data in hexadecimal. Now, I ‘m using cutecom. I can see the JPEG file in hexa (beginning is \ff\d8 and the end is \ff\d9).

What is next ?

  • Be sure that the camera take new picture every time
  • Use the dcmi in continue mode in order to get all the pictures sending by the camera ( I will adapt the camera clock because now we get 28 fps and we just need 25 fps)
  • Use the DMA with two buffers : one is written by the DCMA and the second one is sending with the wifi and it is commuted every picture.
    I don’t have to cut a picture as the size in jpeg is very small (4-10 kb) and a buffer is bigger.
  • Sending the whole through the wifi (first test are encouraging)


[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…


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


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 🙂