Today, Sibille and I tested the common reference time sharing between Phyllos. After coding the whole part, it worked pretty well and we managed to communicate with three Phyllos and the main_stm almost on our first try.
What was just a bit more challenging was when we tried to make the current time master (see yesterday’s post) disappear so that a new one could be reelected.
The tests’ main points
We needed to make sure that we could propagate the time tops from the master chosen among the bottom PCBs, through the main PCB and up until the main STM32.… Read more
Finally, after a few posts, and a lot of work, our testing device (ie our dev board and our ESP) can be a complete sender. As a reminder at first our device will receive images from our server but we also wanted it to be able to send data to another device. Since my last post here are the issue I faced and the solutions I found.
The first issue was to send the data to the other device once we got its topic. To ensure we send the correct amount of byte, I wrote a python script that played the role of our second device.… Read more
On Wednesday, I spent some times implementing task notify on the sensor task, until implementing it on the h-bridge task. Then, I realize that it creates many memory errors and was not really useful since the thread should not call the function that change the multiplexer until the I2C communication was finished.
I also find the way to put some values in the esp32 that I used for the test as an I2C slave, and realized that it works with only 7 bits adresses whitout a read/write bit at the beginning, so I changed its adress and it correctely acknowledge to my communication.… Read more
Today, Marc and I started to work on the common time reference shared between Phyllos.
As you may recall, we need this common time reference to be able to play synchronized animations with several Phyllos. Here is a gif to visualize an example of synchronized animation :
As explained in this post, we know since a long time that it is possible to transmit precisely enough a time reference with UDP. But we still have to choose one ESP32 to be the master ESP32 and to enforce its time reference to all other ESP32, and by extension all other Phyllos.… Read more
On Tuesday, I realize that I need to make two tasks for the sensors. One that will enable the good sensor on the multiplexer, and another that will enable the sensor once the first one is finished. I would like to implement a semaphore, but the FreeRTOS manual suggest that I use a task notification instead of a semaphore. They use less RAM, but I still do not understand well how it works after a day at looking and testing it. I’ll sleep on it and hope that I will understand better how it works.
I also configure an ESP32 as an I2C slave device in order to have an ACK when I communicate with the STM because I have no other device that can do this job.
Yesterday, I used Marc’s UART server to connect the ESP32 to the Olimex E407 devboard which we use to test our bottom PCB code.
After a few adjustments, it works and we are know able to turn on the motor and choose its speed by sending a speed target from a computer to the bottom ESP32, which transmit it to the dev board over UART, which translate it in DShot frames and transmit it to the ESC.
As the majority of the bottom PCB code is written and functional under ChibiOS, we will of course keep this OS for this PCB and use FreeRTOS only on the main board.… Read more
As I wrote in my previous posts, the ESP, the STM and the server were working together to receive images or animations depending of what the user wants. Now it’s time for the STM to become the sender.
We want the devices to be able to received images from the server but we also want to establish a connection between Touchs to send images from one to the other. On top of that at the end we want to have a communication between both devices in both ways. But as you may know chi va piano va sano. So first things firts, we implemented the emitting part for the first device.… Read more
Today, as I was working on implementing the different servers from my last post, I realized a problem occurring on the UART connection between the main_esp and the main_stm. As I previously discussed in that post, I had to tackle the issue of distributing the traffic on the UART data bus.
To this end, I began to write a sort of server on the ESP32. It copies the port system on an internet server. The first byte of each frame encodes the function the following data line must be transferred to. In this approach, two problems must be tackled.… Read more
In one Phyllo, we
have two ESP32. Let’s call them main_esp and bottom_esp to match
main_pcb and bottom_pcb. As far as WiFi communication is concerned,
there are three types of possible data flows:
client (typically a computer, for shell connection on the main_stm)
main_esp (to play shared animations)
bottom_esp (the two ESP32 from the same Phyllo to provide target
rotation speed or maybe also turn off main_pcb)
For each flow, there
must be a protocol to discover the IP addresses. One solution is to
broadcast a request for a specific Phyllo IP address. This solution
is especially useful for the shell client.… Read more
To hell those marbles
Last friday I mainly worked on getting the new marbles (the ones that hadn’t undergone any heating process) to the desired magnetic field values. Remember, on this post I had already manage to have the marbles we already heated at the desired value. It needed a heating time around 5 min, so I instinctively thought that for marbles that had undergone no heating, it would need a longer time. I was wrong. And not slightly wrong, but more like completely wrong.
So I started heating at 300°C for 6 mins, it was too much and the magnetic field almost completely disappeared (barely noticeable).… Read more