I spent the most of my time to do clean up, some changes on the global integration and other minor changes. Indeed, I changed the color code to show more information thanks to the LEDs. In the same time, I modified how I used the different LEDs because I found my work on that could be better.
The next week is our last ROSE week and there will be the final presentation on Friday. Therefore, the task of the week is the preparation of this presentation.
Have a nice week
Benoît for BreathUp
This week, I begun with the color coding. Indeed, the different LEDs on the PCB indicate the state of the device and the alerts. The functions which handle the LEDs are OK but not integrated. However, I could not test the color code for the battery level because the battery level is not finished.
After, I have worked on the CAD software Fusion 360 to create a casing for our PCB. I never used a software like it. So, to understand how it works and how create a part it was an easy. Moreover, I could not use it on my own laptop I had to install the software on a virtual Windows machine in A406. However, to learn how use the Fusion 360, I could ask Sylvain and Arnaud some questions. But it is a new thing to me and I spent lot of times to make simple tasks. I have made a first version but there was a problem when I print it. I made some corrections and printed again a cover and it is better. I will print the base and make others corrections.
Eventually, I will also work on the final integration.
Benoît for BreathUp.
During this end of the week, I worked on the AES and implement C and Python functions that encrypt and decrypt messages using AES128 CTR mode and they work pretty well.
I also worked on our PCB, and implemented some code to drive the LEDs with PWM.
We also discovered another problem: the quartzs are not oscillating, and as we need the 25MHz one for the USB, we still can’t use printf() to debug our drivers, witch makes thing a bit trickier. Therefore, while we are looking for a way to use the quartz, I worked on Segger Real Time Transfer (RTT) that should allow us to debug the code on the STM, but this is not working for the moment.
Eventually, during the beginning of the week I will work on RTT and on the quartzs.
Have a nice week,
so today I finally finished to port my led driver to ChibiOS, you can find it on Github on the branch led
I also start to translate our wiki in english because we started it in french. All the pulibc destinated pages are already translated.
Tomorrow I will translate the PSSC and Git Help pages.
That’s all 🙂
During this second part of the week, I’ve tested several servomotors to help me choose which one was the best for our need. And I still don’t have a don’t have a final answer. The HS81 seems good but it’s quite expensive. As this choice doesn’t have impact on our schematic and PCB design (we just need a 3-pins connector, whatever servo we choose), we still have some time to take this decision.
As I said last wednesday, I tried to improve the communication with the CS4344. I improved it because now, I’m able to send the data to the codec using the DMA, which is good as it doesn’t use the microprocessor. But I still have a problem: the music is played too quickly by the codec. I analyzed every signal coming into the codec in order to find a difference between Samuel’s code and mine, but I couldn’t find any difference. I’ve missed something for sure, because there is an explanation (I’ve always been told that a computer does exactly what you ask it to do, not more not less, so the error comes from me).
I didn’t have time to test the software codec on the development board this week (in fact, I preferred starting to work on the server).
I’ve also added one powerful LED to the schematic and modified a little the pin allocation on the microprocessor. We just need to change the voltage regulator and add the last resistors and our schematic will be finished (except if Alexis finds mistakes in it).
Next week, I will focus on the server code and if possible, I’ll test the software codec on the development board.
This week is fully dedicated to the ROSE project so I had time to work on several aspects of it.
The audio codec was the most time-consuming one because I spent hours trying to understand why I wasn’t able to play music on the board. As Tanguy said, I managed to have the I2S work last Sunday afternoon but it was no the end of my problems. Because yes I was able to talk to the codec but we didn’t understand each other. I explored several ways in order to understand what I was doing wrong. I expected that the problem was related to sampling frequency because that part isn’t clear to me: I don’t clearly understand which signal corresponds to what value. But it wasn’t that. Samuel found a code he used for the 2014 communication challenge and that was able to communicate with the codec. I adapted this code to the new version of ChibiOS and it worked !! I still have to change a bit this code in order to use the I2S driver that was added in ChibiOS in the meanwhile (it uses DMA, so it’s better than doing it by hand on the microprocessor). And I also found a software codec made for running on embedded systems and that is able to decode ogg files. With this 2 infos, we validate the choice of the CS4344 as our audio codec (as Alexis suggested us to do).
I also made some tests with the Flexinol and our banana tree, in order to see if I was able to move the leaves. And the result was very disappointing… So I tested with a simple motor and a wire and it worked very well. With this solution, the result is really convincing (according to me at least). When I showed it to Alexis, he approved my choice: we’ll abandon the Flexinol and use servomotors instead.
Finally, I tested the most powerful LED we have (the one which was abandonned few weeks ago) with the optical fiber, to see if the light was visible even during the day (because with the other LEDs, it’s only visible by night). And it is, so we decided to add one powerful LED to our product in order to make some flash visible even during the day (to signal that you’ve just received a message for instance). We take only one of them, because they need a very high current (up to 2.8A each).
During the second part of this week, we want/have to finish the schematic and the placement/routing of the PCB. Tanguy will probably do most of the job on this part. So I will try to improve the communication with the CS4344 and test the software codec.
Last Friday was the communication challenge (the subject was the same as 2 years ago: solve a maze received from the network and displayed on a screen), and thus I had less time to work on the project than other weeks.
I didn’t had time to implement Tanguy’s suggestion in the detection algorithm for now. I’ll do it before next Wednesday, for sure.
Friday, we finally received the optical fibers, and also a custom light generator and a big packing gland. On Friday evening, after having finished the challenge, I tested the different types of optical fiber with the generator. The effect was nice. Thanks to this test, we can now confirm our choice: we’ll use optical fiber in order to decorate our banana tree
And this test also confirmed me that the packing gland I had selected the week before and that we had received on Wednesday matches our needs.
After this test, I soldered some wires and resistors in order to be able to control the three colors of our LED. Yesterday, I wrote the (very simple) code that allowed me to select the intensity of each of the 3 colors. And I tested it with the optical fibers. The result is cool. It’s less bright than what was expected but the color is more beautiful: the 3 components (red, green, blue) mix very well. Choosing the right diameter for the fiber is very difficult (we have one fiber of 1.5mm and another of 2mm) because both look nice. So I’ll wait for Tanguy’s opinion.
This test allows me to validate our choice for the LED: they work very well, at least as well as the custom generator (and they are much smaller and cheaper). So we have to find a proper heatsink because they still heat a lot.
For the next half week, I’ll implement Tanguy’s suggestion in the algorithm and add new samples in the automatic tests. As I know I won’t have many time to work on the project during this half week, that’s all I plan to do.
During the end of this week, we mainly worked on the lightning. We intended to test some high-power LEDs and that’s what we did. As they require 300mA, we need to drive them with a transistor. I choose the resistors following Sylvain’s calculations. On Friday, we received the LEDs and began to play with them. Even when supplied only by a multimeter, their glowing is quite bright. When they are at their maximum brightness, it can be quite dangerous for th eyes. But we still don’t know how it will look with an optical fiber. Then we used my TP card to test one and drive it with a STM-32 : I wrote the code while Sylvain soldered and in the end it worked.
We also have a brand new requirement for the project : Alexis wants us to measure the humidity of the earth in the flower pot. I found that it was better to get the value by measuring the capacity rather than the resistivity of the earth, but I didn’t manage to find some adequate device. In fact, we might not need anything to do this, we have to see if something can be done with the proximity captors that we use for the leaves.
Next week, I will focus on the schematic of the card.
During the last part of the week we focused on testing the encoder wheels and the RGB LEDs. We bought balloons to diffuse the light from the LEDs. The first attempt with normal “birthday party” balloons wasn’t really convincing, so I found round, white and thicker balloons that worked way better (see Perceval’s post for picture). I found that to get a nice effect we would need 8 RBG LEDs, and I measured a maximum intensity of 440mA for these. So we have to change the battery, the one I selected last week was able to provide only 1A, and it won’t be enough, knowing that the motors could require up to 600mA.
I also tested making encoder wheels with a phototransistor and a IR LED, we got the parts on Friday to test, and I checked that the method is indeed working and will be easy enough to do on many motors. The only annoying thing is that we need an analog comparator, but some are included in the STM32F302, so we don’t even need any additional part.
Next week, we’ll test Decawave modules (real-time localisation using radio waves) to get a better idea of the precision.
“And God said, Let there be light: and there was light.” Genesis 1, verse
Friday I managed to light up some LEDs from a LED strip controlled by SPI : APA102 bande LED RBG 5V
The code is avaible on Github on the branch “pretest”
I ran the code on a Raspberry Pi running Raspbian.
I tested it with some coloured air balloon (red, blue and yellow) to see what the result will be but there were a lot of ambient light back in a406. Arnaud managed to find white balloons and try them at Télécom Robotics’ local. This very good because it’s beautiful and the light is diffused very well. Alexis gave me some diffuser paper that I paste on the LEDs strip and it helped.
I was also very panicked Friday afternoon because GitHub was down (actually it was their DNS host) but everything is back to normal 🙂
I enrolled the team in Trello which is a very cool tool for project management. We use it as scrum table.
According the the PSSC, we have to finish the PCB next week. Unfortunately we don’t know yet which battery to choose because Alexis is very picky (especially towards no brands or not protected ones). Next week I will code a LED library to test them more efficiently. I want to start a choreography list for the robots.
that’s all folks 🙂