So this week end we figured out that our code may not fit on the flash of the robots >< hard time is it huh ?
So we decided first to compile with -Os argument and to review our code to spare some space.
We designed a choreography with Paul, you can check it out on our drive
Also I’ve updated a little the music mix which is still there
Also I started my revision for the finals of the semester which are during the week of the ROSe presentation, yay !
We have not so many classes this week so we will work 24/7 on SwARM 🙂
that's all, good night 🙂
Since last post I did three major things :
- I wrote some code for the beacons and robots to be able to download wirelessly the dances in the robot’s flash, so that even if the master beacon or the server fails, the robots keep on dancing. I also wrote a sequencer, sending the moves and the colors to the robot at the right time (the time is synchronized with the master beacon but can switch automatically to an internal timebase if the beacon fails).
- I created a 3D printed case for the beacons and started to 3D-print and build them.
- I started writing a GUI to generate the dances.
Next I’ll continue to write my GUI and do some debugging on my previous code when we finally receive our boards.
I finally finished implementing the first version of the algorithm that gives the trajectory to be followed as well as the proper orders to follow it. It does not yet handles all cases, but soon will. I deemed more important to have a working version that can be tested as soon as possible.
Tonight, I’ll be brief in this post. I finished the ads driver. What’s more I find out the way to save time on the exchange with the spirit protocol. I’m very happy of that. What’s more I settle a fifo for the exchange which can be configure very easily for the test. Th email goal is finish the integration this week, and start to start the video.
Good night 🙂
Since Wednesday, I have continued to work on the RDC Driver and the time. I would like do functions which were able to get the current time and return a file name or a directory name. I needed to rewrite the itoa function. After that, I made the link between the time handler’s functions and the Bluetooth’s get time function in order to update the time thanks to the Bluetooth connexion and the smartphone.
I also made several tests for the beginning of the global integration in order to understand some bugs with the Bluetooth connection.
After that, I wanted to buzz the buzzer but when I welded the buzzer and tested the circuit to know if there were not a short-circuit, I found the buzzer was not blocked. So, I found that strange and after investigations, that was not a buzzer. Because of this, I did researches to find a new buzzer. However, Alexis have given me a buzzer to write the code about that.
The next week, I will work on the global integration and make the handler of the color code to indicate if the power, the parameters are ok or not.
During the end of this week, I did what I expected, that is continuing to integrate features on the dev branch and thinking about how to bind a string to a servomotor and where to put the optical fiber on the plant.
Then, we found some bugs in the new features that Sylvain added on the server and on some usages of the websockets that I hadn’t tested until now so I fixed them.
Monday, we will receive the PCB and we will see what needs to be fixed.
Such important improvements this week, I resolved my writing problem ! In fact there were not any problems at all, I was writing but It just took so much time… So I decided to reduce the number of writing and increase the length of what was writing. It speeded up the task from 10 minutes down to 30 seconds.
Thus, I ended with implementing the filters on our PCB, it worked fine ! I tested it and compared with what we obtained on the computer: exactly the same. I didn’t try to determine filters speed, but it was enough faster to appear immediate. But this tests need to be perform so I will try to do it during the next ultimate week.
After that, I decided to integrate the whole code and with Xavier, we realized that both LoRa and SD card couldn’t work at the same time, we supposed that it was because of some DMA’s channel… So that Xavier and Samuel wrote a new SPI driver without DMA and now LoRa and SD card can both worked together again !
I also integrated, with Xavier, his job on qualification, we tested it and we had the same results as on the computer too.
Eventually, I worked with Xavier to weld our electrode connectors and we helped Alexandre to merge his work on the ADC with what we have done recently. We performed some tests: we are able to read the ADC output but we can’t read as fast as the ADC write and also, we don’t manage well the data. We always read zeros.. So we have one week to deal with that and to fix some details: it seems that the project will be done soon!
Stay tuned during the last week !
Benjamin for BreathUp 😉
During this end of the week, the project have seen great improvement, as we have put together all the different part of the project that was developed separately.
I first worked on LoRa, and we are now able to send messages to TTN network from a PCB. This wasn’t as easy as expected. Indeed, I encounter two major difficulties. First, an incompatibility between the SPI driver and the SD driver because of DMA shared channels witch forced us to make an hard version of the SPI driver. Then we (I was coding with Samuel) found out that there might be an issue in the stm32 because when we set the SPI configuration to send 8 bits, it’s sending 16, so we find a way to send our 8 bits by asking the stm to send only 4bit, but that’s quite dirty…
Then I worked on the complete integration of the communication from the PCB and to the PCB, containing the creation of a report, ciphering it, trying to send it via Bluetooth, deciphering it while on the server and all the way backward with a new configuration of the device coming from the server.
Then I worked with Benjamin on the integration of the SD drivers, the filters and the qualification algorithms. After some unexplained problems, we finally find a way to make it work. Then I worked on the test on the filters and the qualification, they are now tested with the code and configuration that will be put on the PCB, and not another file. We can therefore change easily some parameters and be sure that everything will be ok on the PCB.
Eventually, during the IMU driver development and during the implementation of LoRa and the qualification algorithms on the PCB, I have found an still unexplained issue, changing value when they are passed to a function as parameter. The dirty fix I found is to allocate them as static values. then they are stored in the bss and the issue doesn’t happen. It looks as a stack overflow, but we didn’t find any other proof of this…
This week will be the last week before the project evaluation, and therefore I will work again on the global integration. I might also try to use the Objenious network for LoRa instead of the TTN one.
The end of the week was full of major steps towards a functionnal robot!
I adapted my code for SwARM’s robots and I perfected the enslavement and the dissection of the trajectory. Our robot can move straight forward, in a curve or in a specific shape as a square. Of course it’s not perfect because for now I only rely on the feedback of the coding wheels, but starting tomorrow, as we should receive the PCBs, we should have a robot with DWM, IMU and coding wheels so we will be able to fusion the data of all three sources.
Also Perceval and I documented the choreography, its shapes and its dimensions, both in time and distance.
You can listen to our medley to prepare you ears for our presentation 🙂
Have a nice evening and a nice week
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).