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

Eric

[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] Tests with the first Design and IR configuration

These last 2 days I worked on designing the armor of our PCB. I printed it during yesterday’s night, and this morning I spent a lot of time in order to make the PCB fit in the armor because the armor a bit too small (1-2 mm). I finally found a way and i have been able to test the PCB within the armor.

The IR global emissions worked very well, but I had some trouble with the HL diode supposed to fire direct shots. In fact at the beginning the shot could miss even if the 2 HeRos were close. The problem had been solved by re-emitting the shot. Now when you fire a direct shot, 2 frames are sent (but don’t worry it’s still count as one shot when you’re hit ^^).

We have also another problem. In fact the HL diode, even with a lens, doesn’t emit in a straight way. We’re trying to find a way to solve this problem, maybe we’re going to print a cylinder that would permits to lead the IR.

Now let’s print the 2nd version of the design to have it for tomorrow 😉

[HeRos] Game server up and working!

Hi everyone!

Today I implemented a game server using Parse.com. Now we can create games, join games, detect when an ally has healed us or an enemy has shot us and we can see our health points updated at every shot. The server isn’t finished yet since some features are not implemented. For instance the end of a game isn’t yet defined, and the characteristics of HeRos (lvl, experience, etc) aren’t either. More about that tomorrow!

Until next time!

[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] IR working well, now taking care of the design

Hi,

During the end of last week, I spent most of my time improving the IR part of our project. Now everything’s working great, each frame received is sorted in order to see if it has not been already received by another receptors in the previous milliseconds. Frames are then send to the phone via Wi-fi or to the computer through the serial usb.

Today was a great day, we have been able to stream video via wi-fi to the smartphone !! It was so cool to see our little HeRos hanging out on the table and streaming video with its camera ! Soon we’ll have everything ready to start playing with our Heros 😉

I spent most of the day designing the look of our HeRos. I had to remember how to use Solidworks (I used it 2 or 3 times in preparatory school) but it was fun to imagine how our little baby’s style 😉 Here is a picture, enjoy 😉  :Capture d'écran de 2015-04-13 20-27-21

[HeRos] Streaming at 24fps!

Hello again everyone!

We’re now streaming at 24fps, with a better version of the app:

Until next time!

[HeRos] Video Streaming at last!

Hi everyone!

Today we’ve finally managed to stream video via WiFi to the Android app:

Until next time!

[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] Camera and IR working!

Hi everyone!

Today we finalized IR capabilities and it’s working great! Charles implemented a CRC in every transmission and I had to use virtual timers to fix delays between every type of shots. We’re also getting feedback to the app when we’re shot and can see the identity of the shooter.

With Rico we finally got a picture on the Android app! It isn’t streaming yet because we seem to be getting the same image over and over again, as if the buffers weren’t being overwritten. Rico will try to figure out why that is and to correct it!

On monday we’ll get started on the secondary modules and the 3d design. This weekend I’ll also implement backend capability for the app (database, server) using Parse.com which I’ve already used on another app and should serve our purpose quite well. Next week I’ll also work on making streaming work well with the app, and maybe on movement control to make it smoother and more precise, probably with a virtual joystick.

Until next time!