Makahiya – mechanic, touch detection and music download

Hi everybody,

The end of the project is close now, so we have to make as many things work as possible. At the beginning of the week, we still had 2 problems to solve: the touch detection that didn’t worked well and the music download, that was of very poor quality (very frequently, the music “freezes”, which gives a very bad effect). So the goal of this week was to solve these 2 problems. And we are very close to achieve it.

On Monday morning, I worked on the touch detection, trying to understand where does the problem come from. I performed many tests, with different settings, without any results. When Tanguy arrived, he tried once with the original configuration and it worked (he was able to detect a touch at least). Then, I worked on the mechanic: Alexis had brought us 3 new plants, so we had to choose our preferred one. We made some tests with the servomotors to see how a move of the leaves looks like. It doesn’t turn the plant into a fan, but the move is large enough to be clearly visible. After that, I worked on the roof of the container for the PCB and the servomotors and printed it.
Yesterday, I worked on the music download and on the container for the LEDs. The container looks nice (I will take photos for the next post).

For the music download, I finally found why the music “freezes”: it’s because I’ve put my buffers in flash and I’ve to erase the flash sector before being able to write in it. And this erase operation is so long (and blocking) that it can be heard. Using the flash for the buffer thus can’t be a solution, so i tried to put my buffers in RAM, because there is no reason that it doesn’t work. In the evening, Samuel suggested me some ways to improve my code. So I implemented these ideas and this morning, I tested them. Unfortunately, it didn’t work immediately… And I spent several hours trying to solve crazy problems with FIFO. I finally decided to test the code at each commit written yesterday evening, to see how the results evolved. And at two of them, it worked perfectly… Samuel reviewed the changes made at the following commit and found a mistake (a variable used instead of another one). And all what I’ve implemented yesterday evening worked once this mistake corrected. So now, the music download seems to work (I will perform new tests tomorrow morning to see if it really works everytime).
During the next days, I will merge the code written the past few days in the main branch and prepare our code for the presentation. And I also have to add content to the server.

Makahiya – CAD, wifi & sound

Hi everybody,

Writing my previous post, I realized that I hadn’t tested the reception of data through the WiFi module, only the emission. So on Thursday morning, I did some tests to check this part and it works immediately, which was a good news. Then, I worked (again) on the touch detection part of our project, as it’s a quite important part of it and for the moment, it’s unreliable. Despite many tests and solutions tried, it’s still unreliable. It depends a lot on how the wire is fixed to the leaf and on the leaf itself… We’re now able to detect touches almost every time but we have many false positive also. The variability of the results makes the work on this task very painful. Indeed, it often happens that you think you’ve reached an acceptable solution, you do 2 or 3 tests that work very well, and when you want to show it to someone else, it doesn’t work any more. And if it works one evening, it doesn’t work next morning. More work is thus required to make it work, even though it’s not the most interesting part.

I also worked on reacting to messages sent by the server. It’s now possible to select the color of the leds on the server and to send it to the plant. We faced several problems with Tanguy when doing this part, most of them coming from the database, which sometimes crashes due to an overflow of requests. But now, it seems to work well.

On Friday, I spent most of my time working on the box that will contain our board. I decided to put the PCB and the servomotors in the same box, and the LEDs in another one. The PCB will be placed below the pot while the LEDs will be at the base of the trunk. I’ve 3D printed a first version of the PCB box (without the roof) and the dimensions are good (I took margins to be honest, and I’ll remove them for the next version). This week-end, Alexis has to buy a new plant that we’ll use for the final presentation. So tomorrow, I’ll start to put all our stuff on it.

On Friday evening, we finally received the audio jack plug. We thus could have tested the sound and after some debugging, it worked well. However, the music download doesn’t work for now, so I’ll have a look to it to find where does the problem come from and see if I can solve it.

During the next few days, I’ll work on the mechanic (containers for the PCB and the LEDs, placement of the wires and of the optical fiber), on music download and maybe on the touch detection. And we also have to think about what we want to show during the final presentation.

Makahiya – websockets, music & server

Hi everybody,

During the last 3 days, I worked on the websockets, the music downloading and a bit on the server.

As said in my previous post, I had some problems with the websockets: sometimes the connection between the plant and the server couldn’t be established and I didn’t know why. So on Thursday morning, I carefully reviewed my code and made several tests in order to find the origin of this problem. What appeared from these tests is that when one connection was succesfully established, I had to wait for a certain amount of time in order to have another successful connection. So I made the tests by properly disconnecting the plant from the websocket instead of simply shutting it down. And this solved the problem. On the server, there is a mechanism that periodically checks if the plant is connected to the websocket and if not, close it. But if I try to reconnect the plant to the websocket before it has been closed, it creates problems and most of the time doesn’t work. It was a good news to finally solve this problem.

On Friday, I worked a little on the server, to improve it’s appearance and make it send messages to the plant. But the tests I did to check if my modifications worked well didn’t cover all the cases and Tanguy had to make some corrections after having run other tests.

After that, I decided to work again on the music download. But this time, I tried to first download it in Flash and when the flash is full, read the music from the flash. I used Arnaud’s code (that he had himself taken from someone else) to write in flash and implemented this idea. And it worked well: on Friday evening, I was able to download 900ko of music and to play it. After that, I tried to use the flash as a circular buffer in order to be able to play longer music. And on Saturday afternoon, I managed to do it. There is still one (small) problems: the sound sometimes ‘freezes’ for some milliseconds so I will try to find the origin of this problem if I have time.

Before we receive the PCB (which should happen tomorrow afternoon), I will integrate the wifi code in the dev branch, the one that holds the code that will be flashed on the PCB. And as soon as we receive our PCB we will test them and finalize our project: add the whole logic (properly react when the user ask for turning on a led for instance).

SwARM toward the end

Hi everyone,

So today was a good day we defined the big steps for the choreographies : we will make some basics movements synchronize with music. I made a medley after much and much discussion about which music to choose. You can find it here.

Also I finish IMU implementation (finally ><) and merged it in dev. I will add threads and interruption support tomorrow. 🙂

Also we will perform our final presentation in Thevenin amphitheater because it offer sufficient place to do some choreography with around 6 – 10 robots and everyone in here will see it from slightly above which is great.

By the way it seems that we will only make 6 robots because we only have 6 batteries and their is no more in Farnell's stocks…

But overall it is very cheerfull to see our project taking some formss like Paul can pilote wheels, Arnaud can locate a decawave, Alban can locate a led… 🙂

that's all, good night.

Makahiya – music download & RTT

Hi everybody,

Since last Wednesday, I spent most of my time working on the music download. And it still doesn’t work, unfortunately. On Thursday, I found that on many set of bytes sent by the WiFi module to the microprocessor, one or two bytes were not received properly. But the ‘end of frame’ bytes were received, so this loss occurred in the middle of the frame. After some inquiry, I found that a noise error was raised by the serial driver. Alexis first advised me to directly connect the GROUND of the 2 boards, but this doesn’t solved the problem. Then, again following his advice, I grouped the RX, TX and GND wires together, again without any visible results. I also tried to slow down the UART speed from 921600 baud to 115200 baud. With that baudrate, communication works well (no more bytes loss) but the sound still doesn’t look like music. Some initial buffering of data seems to improve a bit the problem (the sound looks more or less like the original music during the first seconds). For me, this confirm my opinion of a transmission rate which is too slow. But it shouldn’t be the case as 115200 baud is supposed to be enough for a mp3 encoded at 96kbps. More work is thus needed on this topic.

On Friday afternoon, we had to make a presentation of the advancement of the project.

Yesterday afternoon, I worked on RTT, a function offered by the SEGGER probes to create a bidirectional serial communication through the debug wires. Using it to send and receive messages is really fast forward, but I wanted to be able to use it transparently in ChibiOS, like a common serial link. So I had a look at how to implement the Base Sequential Stream interface. This took me some time because of the RTT Client proposed by SEGGER. In fact, this tool sends ‘\n’ when you press ‘Return’, and ChibiOS shell waits for a ‘\r’. For the moment, I simply convert ‘\n’ to ‘\r’ before sending it to the shell but this is not a definitive solution, just a temporary bandage.

Next week, I will work on combining the capacitive sensor with my algorithm used to detect touches and on the music download, until we receive our PCB (we still don’t know when they will arrive).

Makahiya – Wi-Fi and music (again)

Hi everybody,

Yesterday and today, I worked on the Wi-Fi connection and more precisely on downloading a music from the server. As said in my last post, I had some problems of rate. And they are more complex to solve than expected. I was becoming crazy yesterday afternoon, because despite all my efforts and all the improvements I could do, there were still problems. Thus, I decided to make a break and not to touch this part again before at least one week.

But Samuel answered to a question I’d asked on the mailing list, suggesting me to measure the time spent on the blocking functions. As it was quite easy to do, I decided to do it this morning, just to see. And, due to some magical effect, the download of the music worked quite well. So I regained courage and made some cleaning on my code. The sound is not perfect, but now the music is received until the end in most cases, and the error management system doest its work pretty well.

I won’t continue to improve it now as it’s enough for the moment. So this afternoon, I had a look to the websockets implemented by Tanguy on the server, to see how it works. During the second part of this week, I will either work on implementing the connection to the websockets on the board and the reception of commands or start to implement the driver to control the capacitive touch sensors, I don’t know yet. My objective is that these 2 things are finished by the end of the holidays. It’s quite ambitious because I won’t have so many time to work, but that’s my target.

Makahiya – Wi-Fi and music

Guten tag von Munich,

On Thursday and Friday, I spent almost all my time working on the Wi-Fi module, trying to understand why I wasn’t able to play music received from the network (and even not able to properly download it completely). On Friday evening, Samuel entirely reviewed the related code with me and helped me correct several mistakes, mainly in the code of the audio part. And it was the right thing to do because now, it works much better: I can receive music (at least the beginning) and play it.

The sound is still not perfect so I have to understand where this problem comes from, but I’m quite confident I will find a way to solve it in the next few days (when I’ll be back to Paris). In fact, I didn’t check the code related to the audio part because I assumed it to be correct as it worked when I transmitted the music on the serial line. But it wasn’t…

So the morality is: if you have something that doesn’t work as it should, review all the code related to it, even the parts that you trust, because you can find there mistakes that previous tests didn’t found.

During the next few days, I’ll try to solve the 2 remaining problems: I can’t download the whole music (downloading abruptly stops at a certain point, that doesn’t seem always the same) and the sound is quite bad (probably due to a lack of data at certain moments, if the download or the exchange between the Wi-Fi module and the micro-processor is too slow).

Makahiya – Wi-Fi

Hi everybody,

During this first part of the week, I worked on the Wi-Fi module. Unfortunately, I didn’t managed to reach my goal, which was to play music streamed from the server on the development board.
However, I did some things. Command return codes are now properly handled by the program and it’s much easier to communicate with the Wi-Fi module through the development board. For the music, I’m able to receive the data (some data in fact, I have to check if there are differences between data received and the actual content of the audio file). The first problem (which I think will be solved automatically when I would find a solution to make the music player work) is that when I just tried to download the music, I receive a continuous stream of data, without end (at least not in 5 minutes of downloading, for a music that last about 4 minutes…). Second problem is that when I start to decode the input stream (from mp3 to pcm), it stops downloading the rest of the file, whereas these actions are performed in 2 separate threads.

The second part of this week will thus be dedicated (for me) to look for the origin of these problems. And we should also add some automatic tests (at least check that the code compiles) for the Continuous Integration. This will be done after the Wi-Fi/music problem is solved, so probably during the holidays.