One ESP32 to rule them all

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 :

Master election

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

UART, UART, UART (and shell)

As explained in this post, we have decided to use FreeRTOS on our main board. Last week, Sibille and Vlaya have successfully adapted the frame sending code for SPI buses. For The past few days, Sibille and I have wrestled with the UART communication code. 

Here is how the code evolved since my last post.

Shell implementation

At first, when I began coding the UART server, it was closely related to the shell (over WiFi). I also communicated with the ChibiOS shell on the other side of the UART. The next step of my reflexion was to realize that it wasn’t natural to have the shell on the STM32 rather than the ESP32 and I stopped using the ChibiOS shell. … Read more

Task Notify

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.

Timing the flashes

Today Xavier and I worked on a way to flash the LEDs at given absolute angular positions, as discussed in this article

Over the last few days we’ve refined an idea to naturally flash the LEDs at a given absolute angle thanks to the STM32 Timers.

The Idea

To retain awareness of the angular position of the Phyllo, we have a position sensor (either a hall or an optical sensor, both are on the board) that triggers a rising edge once per rotation. We consider the position at which the sensor fires to be the absolute angular position zero. This gives us an absolute reference that we’ll use to keep the flashes from drifting in time.… Read more

Working on communication data integrity

Lately I’ve been working on a way to make the communication between the STM and the ESP more reliable.

While searching on the subject, I came across two methods.

The first one made me reminisce some of the lessons we had in first year about information theory. The idea is to use a Hamming code for the messages of the protocol. This will make the communication more robust because of the properties of such a code. We plan to use a Hamming code (7,4) which means that the words will be 7 bits wide, with 4 bits of information (meaning we can go up to 16 different words, including the words with only bits at 0) and 3 bits of parity.… Read more

Coding for test

On Thursday and Friday, I spend some times coding the threads of the test PCB. I first debug and check if everything was ok for our thread that will read the state of all the box via the hall effect sensor. I used a logic analyser to check if everything was fine. I checked that the four pins that will be used for the multiplexer will not change until the end of the sending of an I2C message. Then I code a thread that initializes all the H-bridge by putting them at the 0 state.

I also realize that I have not seen a mistake in our scheme.… Read more

A new angle on flash frequency

In a previous post, Vlaya and I showed how the flash frequency can lead to many nice effects.

A question of angles

After a long reflection, we realized that for many reasons the best way to describe the flashes is not by their frequency, but instead by the absolute angular position of the Phyllo when each flash occurs.

Therefore, each image description will contain the colors frames and a pre-computed absolute angle (which may be procedurally computed or included in a stored animation).

These absolute angular positions are not to be confused with the relative angular rotation of the motor between two consecutive flashes.… Read more

The walking LED

I started to work on the SOM with Romain a few weeks ago. My objective is simple: we need to be able to test our modules while we wait for our PCBs.

It’s alive !

For this purpose, I took my favorite necromancy book and proceeded to revive CyL3D.

I used this opportunity to get familiar with the tools we use to program the FPGA. I forked the reference project from Aries and tried to communicate with the drivers using only the FPGA.

However I was not able to control the drivers properly, more debugging has to be done. In order to accomplish this debugging, I need to control the our modules using the HPS.… Read more

Motor control over Wifi

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