Today, we have continue to work on the MEMS micro with Alexis, and Samuel has also participated to the code. I would like to thank for their help.
We have changed the filter since yesterday and now, the ST Microelectronics PDM library is used. We have implemented a loudness detector whick sends an event when the loudness goes over the specified threshold.
For the test, the concerning thread was nearly the only one working running but tomorrow, I will test it in parallel to the others ones. These future results will indicate to us if we will be able to capture a usefull sound during the game, and also if the voice recognition will be possible. To be continued…
Moreover, this morning, I have finished some modifications of the 3D Model. Nevertheless, we were not lucky with the 3D printer today. In addition to the lack of 3D filament, we got problems, 3 times, with the printer because of knots on the filament. We tried and succeed a really tricky stuff, with the Expelliarose team, to roll up a coil of 3D printing filament on an other coil, suitable with the 3D printer used. I give you our tools and let you guess the process : a broom, a coat rack, a pen, a drill, … It was a very funny and interesting teamwork.
Now, it’s time to sleep for me. Bye !
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
HeRos touched by a global shot
HeRos touched by a direct shot
HeRos in darkness
Today began terribly. We had 2 PCBs that just couldn’t communicate with Pololu and we didn’t know why. Then this morning another one got wrong. We analyzed what was coming from the Serial Port of our PCB that was supposed to communicate with the Pololu and saw that the signal just couldn’t increase up to 3.3v anymore when it was emitting a signal. The P transistor has fried. Alexis helped us solving the problem by adding a pull up resistor to have a correct signal. This worked pretty well on the first 2 PCBs that were damaged, but not on the 3rd one.
After this bad morning, I spent the day working on IR matters. In fact our HL diode (used for direct shots) is not enough directive. This is a problem because you could fire another HeRos even if you didn’t aim correctly. I was thinking about a special cylinder printed in 3d to direct the IR but it appears the IR goes through the material used by the 3D printer (PLA). I was seeking new material to make a cylinder when Alexis told be a simple 4 color pen could be able to direct the IR. I tried it and it worked perfectly, now your direct shot are precise.
I changed the design in function and then studied the range of our IR shots. Global Shots are received up to 3,5 m and direct shots up to 10m, so this will make it for the game.
We also tried with Eric to see if it was possible to play in the dark with our HeRos, the result is quite fun :
Today was interesting… We started the day with two PCBs not working: the UART with the Pololu didn’t work since yesterday. And then a third PCB started exhibiting the same symptoms. After a long investigation, it turns out that a transistor on the TX pin of the UART is fried and by adding a pull-up resistor, Alexis managed to get two PCBs working again. Unfortunately the third one is beyond repair and the processor is going to have to be replaced.
Then I worked on improving the app interface and stability and the server. The app also has some nice sound effects now from various sources: Star Wars (that new teaser felt good, didn’t it? ), Portal, even one from Mario! It’s all working pretty well. One issue remains: when only one of us is connected to a HeRos, we have 28fps streaming, no problem. But when two of us are connected at the same time, the framerate becomes unstable and has sudden drops. Whether it’s due to interferences or the number of people using the A406 hotspot, we don’t know yet. We’ll do more testing tomorrow.
Until next time!
This was an eventful journey !
After debugging on a non-functional strip (the soldering had ruptured, so we couldn’t display anything), and displaying well-corrected …black images, we now have a thing !
Yesterday we managed to stream data from the server, and to play a sound while downloading it (yay !).
Nonetheless, we are facing a big issue : the data doesn’t come as quick as we want. The sound of the wifi is always halting and thus very dirty…
It seems that the mailbox we are using to communicate with the codec clears out too quickly, and then the codec has to wait for a while for some data which makes the sound dirty.
We are also going on the applications side, what Kudly will be able to do after all the features will be completed :
We hope most of these features will be working by Monday morning !
Yesterday, we’ve worked on the microphone with Alexis. As using the I2S protocol is more practical for us but it isn’t implemented on the 2.5.6 version of ChibiOS, we decided to add its implementation, available on Chibios 3. Once the good configurations set, we finally succeded in making the clock and the data transfer work.
After this, we added a processing to make the raw data useful. For this, we used a library that implements decimation signal processing and a low pass filter. In this way, the microphone capture the sound
Now, we just have to apply a band pass filter to delete some unuseful data. The next step will be the sound recognition
PS : Thanks again to Alexis, for his HUGE help.
So today I remade a little part of my yesterday measurements (what was quite quick since i just focused at the at the most non aligned points that we could see at the plot). I soldered another connector for one of our half spheres and traduced the maths of the article we are using to represent the spherical points into functions. Probably we are going to use them very soon when making figure rotations.
That’s it for today.
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.
I got one good news, I have 3.3V again! But the UART still doesn’t work:
Set of messages on the UART
A message with high 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
I have find out what the weird bugs on hte I2C were. A pull-up resistor was deconected, and because of that the SCL pin was all the time low (And the STM32 thank that the bus was all the time busy…). Now that the resistor is back, the I2C bus works fine, and thus the IMU works fine. After discussion with Samuel, we have decided to disabled gyroscope, and set the rate of refreshing accelerometer data to 1.25Hz (in order to save power). We will detect if there was a move by analysing the change on absolute valors of the acceleration on the 3 axis. After some test on the card, it seems to work well, we will try with the card on Kudly as soon as possible
I have also worked with Marc on the ausio streaming. He’s in charge of the wifi part (recuparating datas from the server), and I’m in charge of the codec part (transform the datas in audible sound). After a lot of trouble, we have succed to recognize the should we should hear, but with a bad quality. We think it’s because the codec does not receive data fast enough. We will try tomorrow to have a better sound quality… But now it’s time to sleep