How to distribute traffic

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:

  • main_esp ↔ client (typically a computer, for shell connection on the main_stm)
  • main_esp ↔ main_esp (to play shared animations)
  • main_esp ↔ 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

Out of the shell

At last the shell is running satisfyingly. Finishing it, I had two last problems. The first one is because Ubuntu finishes its lines with a lone line feed whereas the ChibiOS shell expects a carriage return before it. When it does not get it, it does not reply.

The second problem was that the shell not only returns feedback on the command, it also echoes the command itself. Which is then printed a second time to the user. I did not find another way around this that simply comparing the response to the answer and only print the different part. This may lead to some concurrency issues since the thread receiving the responses is different than the one sending them but even if we sometimes cannot wait to send a new command, at worst we will get the first command printed twice instead of once which is not very important.… Read more

Shell in the air

For reminder, as the main intelligence in a Phyllo is main_pcb which will be rotating, we cannot tolerate to only have a shell over USB. Thus we have decided to have connect to a shell using WiFi.

I have been implementing this those past few days. Surprisingly, I actually encountered a few friction points.

First, let me describe more precisely the situation we have. The shell is controlling the STM32 and the WiFi is run by an ESP32. We thus have two layers of data transmission. The first one with WiFi between the user and the ESP32 and another one via a data bus between the ESP32 and the STM32.… Read more

Timing with ESP32, conclusion

Today I corrected the test of the ESP32 as I suggested yesterday. I added more ESP32 and I modified the code to emulate a busy CPU situation. I also paid close attention to the regularity of the timing between emission and reception of the UDP packets.
Here is a picture of the setup:

For the question of the stability of the timing between emission and reception, I found out that it is not stable enough. Here we can see that the timing can at least vary between 0,1 and 0,2s which is too much.

However, as shown below, the precision is fairly good for the reception.… Read more

First test on ESP32

Today was day of the test. It was actually quite different from what I planned, in this post especially.

First of all, I did not manage to make an ESP32 receive its own broadcasted packet. Apparently, it is not natural for a device to receive a packet sent by itself. I still have some leads to follow about it so I will maybe continue to look for a solution. In this test, there was simply an ESP32 which did not received packets. It is also possible to accept that. Indeed, we will have 2 ESP32 on each Phyllo. One on the main_pcb and another on the bottom_pcb.… Read more

ESP32 Update

I kept preparing the timing test for the ESP32 today. The challenge was to understand how FreeRTOS works, of course, but also to grasp the workflow of the WiFi on the devkitC.

The example I found first was simply about coding a usual UDP server/client pair. However, when I arrived to the actual testing moment, I realized that there was barely any chance of it working as I did not even provide a basic username/password to my program. So I had to discover more about how to setup the actual WiFi connection.

It eventually worked out. However, I am now stuck on a very annoying problem.… Read more

First outline of a time reference

Today, I started to implement the code necessary to test the possibility to use WiFi for time reference between Phyllos as explained in this post. Although we mainly use ChibiOS for our applications, the documentation for ESP32 is in FreeRTOS so the code for this test will also be using FreeRTOS.

The plan for the test is to connect as many devkitC as possible to a main board (here it will be an Olimex E407 programmed with ChibiOS). The main board will be the master over one of the devkitC. When it will start the test, the slave will broadcast an UDP packet.… Read more

Figuring out the right WiFi protocol

Since thursday I’ve looked into how to implement the wifi communication we need between our phyllos (see Ruling the colony of Phyllos ).
We need a way for multiple Phyllos next together to broadcast data between themselves, and a way to communicate with the Phyllos from a smartphone or computer (for instance), and we will be using a ESP32 dev kit C integrated in our Phyllos.

Data exchange between Phyllos

The rate at which the phyllo need to exchange data doesn’t have to be very high at all: we just want to exchange small messages such as “Here is my ID: xxxx” , or “Start animation X at time T”.… Read more