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.
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.
On Monday, I started to review my code and clean it. I found that the touch detection algorithm was not adapted for 2 sensors, so I modified it (double the size of all the buffers, add one parameter to each function,…) And this day, we finally received our PCB. With Alexis, we made the first tests and discovered 2 mistakes: the power jack is connected in the wrong sense and the pins of the SWD aren’t mapped properly on the connector. For the first problem, Alexis inversed the wires coming from the power block, and for the second he made a patch.
After that, we flashed our program and began to test the components. The Bluetooth worked immediately, and the communication with the capacitive sensor was also immediately functional. Tanguy had to make some corrections for the LEDs and I spent some time trying to understand why I wasn’t able to communicate with the WiFi module. The problem was desperately stupid: I set the pins in the wrong alternate function (the alternate functions table was organized in a different way than the others I had seen but I hadn’t noticed it before yesterday). Now, the Wi-Fi works well (I’ve forgotten to test the reception of messages with websockets so I hope I won’t have any problems with that).
The next component I tested is the capacitive sensor. The communication worked well but I wasn’t able to detect any touch. I investigated a bit, reviewed the configuration values and decided not only to copy the one that worked for the demo board but to evaluate the appropriate ones for our board. First problem with that: we use the internal oscillator of these sensors and its frequency is used in the formulas. But the datasheet only says that this frequency is between 35 and 55 MHz, which is a rather large interval. The second problem I faced is : how to know the capacitance of a banana leaf? With Tanguy, we went to see a professor who could have helped us, but he didn’t find any relevant way to perform this measure. So I decided to redo some tests with the demo board and my own configuration to see if it worked. Then, I did some new tests with our board and this time, the values read were much more coherent. So, it was a good news. The problem now is that the algorithm I wrote some months ago to detect touches doesn’t work with these values so I will have to work a little on this to make it work.
During the end of the week, I will work on the touch detection algorithm, on the “mechanic” (container for the boards, the servomotors and the LEDs,…) and on the code that will run on the board during the presentation.
The beginning of this week has been quite productive. Indeed, I managed to have different tasks reaching a functional state.
First, I worked on the server. I added several pages to provide an interface that allows the user to trigger all the actions that the plant can perform. I also improved the login/logout functionality. For the front-end, after some discussion with my classmates, I chose to use Bootstrap. It allowed me to have an acceptable-looking website in a short time.
On Tuesday, we received the new FDC evaluation board (for the capacitive sensor). This time, I connected the pins very carefully, entirely reviewed my code and tested it. After some minor correction, I was able to configure the sensor and to read data by polling it. After that, because polling is a bad thing and that in that case, it can be avoided, I implemented the part of the driver that waits for an interrupt (that signals that a new set of data is available). With this, the driver seems operational to me. Next step will be to connect it with the detection algorithm I wrote a few months ago.
Finally, I also worked on the Wi-Fi module. I greatly improved the websocket part of the driver and after the corrections made by Tanguy on the server side of the websockets, it worked very well. Like with the capacitive sensor, it was done by polling the module. And in this case also it was possible to avoid it by using an interrupt. So I tried to implement this part of the driver. I had some problems to find a pin on which the pulldown resistor worked (because on the 2 first I tried, there was a pull-up somewhere on the board…). And I had also some (stupid) mistakes on my code that make me lose some time. But it forced me to carefully review my code and thus to improve it, so it’s been useful. So now, websockets are fully operational. I also improved a lot the management of the errors and started to implement the decoding of the commands that will be received through the websocket. As one of these commands is to play a music downloaded from the server, I tried to re-use the code I’d already written for this. And the last error re-appeared unfortunately: the Wi-Fi module takes too much time to answer to my requests. And I don’t have any idea of possible origins of this problem. I will try tomorrow with another Wi-Fi network to see if it changes something, but I don’t hope too much.
The end of the week will be dedicated to solving the problem with the music and to connect the detection algorithm with the capacitive sensor driver: assembling several parts together in fact. It’s the beginning of the integration phase and this is a good news.
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.
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).
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.
As said in my previous post, I’ve worked on the Wi-Fi module. And it works very well. Using the module itself was much easier than expected. I just have to send commands to it on a serial connection to make it works. And it’s very easy to show a nice user interface to select the proper Wi-Fi network to connect to because it’s already provided by the OS embedded in the module.
I had more problems to configure the UART bus on the development board, even though it seems a very simple task. Most of the problems were quite stupid. For instance, on the Olimex E407 board, the pin number 8 on the Port D connector doesn’t correspond to GPIOD8 !! Because pins 1 and 2 are Vcc and GND. Once you discover it, you realize that you’ve spent the last hour working for nothing, really.
But now, everything works fine: I’m able to connect to my Wi-Fi network, to read web pages and to use the API of our server to update the database.
Now, I’ll continue to work with the Wi-Fi module and try to make it connect to the websockets Tanguy has created on our server.
Since last Sunday, I worked on the PCB and on the server. First, on the PCB, I did a complete check of both the schematic and the routing, to find the remaining errors. Alexis also did it on his side, and we both found errors. After having corrected them, I gave my approval to send the PCB to the factory, and so did Tanguy. We should have received them in 8 working days. But as we don’t really need them during Christmas holidays, a longer delay is possible (which is good as it reduces the cost). So our PCBs have still not been sent. But we received 2 evaluation boards for the Wi-Fi module. Thanks to them, we’ll have the opportunity to develop the driver to control the Wi-Fi connection with ChibiOS. Alexis will also solder an evaluation board for the Bluetooth module, so that we can also work on it during the holidays.
After having finished my work on the PCB, I spent several hours on the server. I faced many problems with
git subrepo, and thanks to Perceval help, I manage to get rid of it. So now, it’s much easier to work with Heroku. I’ve added authentication to our server and I tried to add links between the tables in our database. But I faced several problems, some due to the facts that I didn’t wrote all the code (Tanguy is also working on the server) and that I assumed things that happened to be different (for instance, we use a Postgre database on Heroku but a SQLite one for Continuous Integration because Tanguy has the impression that it’s not possible to install a Postgre database in the test environment).
As working on almost the same thing at the same time seems to be a rather bad solution, I will probably start to work on the Wi-Fi module and let Tanguy continue his work on the server. So by the end of the week, I will learn how ZentriOS works and start to write the driver that will control the Wi-Fi module.