It remains less than 36 hours before final presentation and there are still some things to do, but I’m confident in the fact that we’ll be ready on time.
During the last few days, for the software part, I worked on the final debug and improvements of our code. This morning, I finally found why the server crashes so often: in fact, I never closed the SQL sessions I opened, because I didn’t know that it was necessary to do so. So now, the server doesn’t crash anymore. And we have added a timeout on the websocket connections, with a keep-alive message, in order to detect when the plant has been disconnected. And it solved many problems.
For the hardware part, I soldered several leds, tested several heatsink and tried to find a good solution for the servomotors. Indeed, it was hard to find a good place for them, one that allows the wires to freely move up and down. In fact, the problem was that the leaves didn’t have enough strength to pull the wire if this one went through the ground or in a pipe with angles. I finally decided to put the servos at the top of the pot, so that the wires only cross air.
Finally, I also prepared a first version of the slides that we will show on Friday during the presentation.
Tomorrow, we will prepare the show for Friday and finish to equip the plants.
NB: Tanguy has just implemented the code that allows the plant to tweet when a leaf is touched.
The last 4 days have been dedicated to integrate all the components of our project, bind them together and make the final corrections.
I’ve soldered several leds and with Tanguy, we made some tests with the leds container I had printed. The leds are really powerful, so powerful in fact that they heat too much and destroy themselves if we don’t put a heatsink. I’ve tried to add a small one, which improved a bit the dissipation, but a bigger is likely to be required if the leds stays turned on for more than a few seconds.
Yesterday, I’ve also added the mechanism that allows the user to program the reaction of the plant when he/she touches one of the leaves. It’s possible to control the leds, the servos and the alarm ring tone and to add loops combining all these elements.
Now, all the features that we wanted to have in our project seem to work, even though the touch detection doesn’t work as well as expected.
Next week, we will finalize the mechanical pieces, equip a plant with all our stuff and prepare Friday’s presentation.
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.
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).
Since last post, I worked on the capacitive sensor and on alarms.
For the capacitive sensors, I integrated the algorithm previously developed. It works pretty well with the sensors pad of the evaluation board: I’m able to detect touches. I didn’t encounter specific problems for this integration. Next step will be to finely tune the algorithm settings with the sensors glued to the leaves, but I’ve estimated that it’s better to do it directly with the PCB as I have other tasks and problems to solve before.
The other topic which occupied my time is the addition of alarms. Indeed, we want to be able to use our plant as an alarm clock with both sound and light. First, I tried to implement this mechanism on the server side (and the commands would have been sent to the plant at the awakening time). After several hours of vain intents, I made a break and thought that in fact, it could be interesting to have a more reliable alarm clock, one that doesn’t depend on the internet connection. And thus, it was no more necessary to implement the timer on the server. So I implemented only the settings selection on the server and the alarm is created directly on the plant side. When you create your alarm, you send a list of commands to the plant that will be executed at the awakening date. These commands belongs to 3 categories: sound to play (for the moment, you have the choice between 3 ringtones), lights to turn on and servomotors to move. Doing and testing this functionality showed me that I wasn’t able to play several music sequentially, so I had to correct this point (it was simple).
During the end of the week, I want to solve the last major remaining problem: the connection to the websocket which doesn’t work perfectly. It works sometimes, and sometimes not. So I want to find what is the cause of this strange behaviour and to correct it.
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).
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.
During the last three days, I focused on the server. Indeed, I want it to be ready (or at least functional) before we receive our PCB (which should occur next week). I found it not so easy as I didn’t know anything about web development. But it’s interesting.
For user authentication, we use the user’s Google account. To manage the OAuth2 process, I chose to use the Velruse library. But I had a problem: when the user was already logged to a Google account, the account selection page didn’t appear thus not allowing him/her to choose another account… Samuel found that it was possible to add a parameter in the request to force this display of this page, but the Velruse library doesn’t provide the opportunity to add extra parameters. So, again with Samuel’s help, I patched the library in order to add this ‘prompt’ parameter. As this patch hasn’t been applied to the whole library and doesn’t provide a way to change the value of this parameter, I didn’t release it publicly. Maybe I will do it later.
I also spent some time to create the pages that allow the user to create an account and to manage his/her flower.
The appearance of the website is horrible, I know, so it will probably be necessary to improve it at least a little, to make it more appealing.
During the next few days, I will work on connecting the WiFi module with the websockets in order to have a bi-directional communication between the flower and the server. And I will continue to work on the server to improve it and to add new functionalities.