Working anatomy of a Phyllo

Architecture

Here is a diagram summarizing the architecture of a Phyllo, to allow you to have a global vision : 

Some details

This week, we spend a lot of time trying to choose the components. Here are the solutions we explored and the decisions we took.

Motor and ESC

All the animations we will display are based on two or three basic animations : aging petals, de-aging petals and possibly fixed images. Here are simulations to visualize those animations :

Aging and de-aging petals

In order to display those animations without skipping any petal (have a look at this instructable to remember the “skipping petals” part) while flashing the LEDs at 30Hz (ie 30 frames per seconds), the Phyllo has to rotate at : 

AnimationSpeed (RPS)
Aging petals11.46
De-aging petals18.54
Fixed petals30

Furthermore, we are going to use a brushless motor (less wear-and-tear, less noise) controlled by an ESC. We have chosen not to use the same motor than J. Edmark (KV135) but a motor with a higher KV, in order to consume less power. A higher KV motor has a weaker torque at the beginning, so we will have to choose a precise ESC (some of them are controlled in I2C or SPI). 

For now, we have chosen:

For the ESC, we will first test if the ESC CyLED used last year is able to start our motor. If not, we will use the VESC 6+.

Battery

The LEDs will require a lot of power, but for very short bursts: they will require less than 1W on average. The motor require at most 75W. We would like to have 1h autonomy, so the battery has to provide 80000mWh. The motor we choose requires a 6S battery. Therefore the capacity must be more than 3622mAh. We have chosen this one : Batterie Lipo 6S 4500mAh.

Power transmission

First we wanted to have a wireless transmission to avoid the ugly effect of having a metal bar coming out of the top of the Phyllo, as CyLED did last year. After extensive research, we found that this type of energy transmission is currently used almost exclusively for mobile phone charging. Therefore, output power is usually far lower than our needs (20W against 120W). The few products with better output power are essentially coming out of China without any documentation.

We also considered the possibility of building our own wireless transmission to get an appropriate output power. However, it is too hard to get a satisfactory calibration and we do not have the time required.

The following idea was the slip ring. However it has a big flaw: it wears down quickly. We imagined to have one connection on the ball bearer of the motor. Then, we thought that we could put a second one as a ring on the axis of the motor to completely get rid of the slip ring.

This ball bearer has no other use than electricity transmission. Here the insulating layer enables the ball bearer to stick to the axis. It is also necessary since the axis already bears the current from the ball bearer of the motor.

Regulators

We will need at least a 3.3V regulator and a 5V regulator, to regulate the output voltage of the battery and of the power transmission device. We have considered 2 switching regulators : LT1765 and LM2678.

LEDs and light pipes

We haven’t received all the components yet… While we were working on the components choices, Vlaya has started to design some tests for the LEDs.

LED Drivers

We plan to use a LED driver for each spiral arms. The drivers need to have enough output channels to drive all the RGB LEDs of the spiral without multiplexing. A Phyllo has a different number of clockwise and anticlockwise spirals, so we can take as many drivers as the smaller spiral number, in which case they need to have more channels, or as many drivers as the bigger number, and they can have fewer output channels.

The drivers cannot be interrupted in the middle of a PWM cycle, therefore the clock of the internal PWM of the drivers needs to be fast enough that a PWM cycle is shorter than approximately 100µs. That is the time the LEDs can be flashed, if they stay on for longer periods the image will blur due to the Phyllo’s rotation.

Moreover we need to be able to communicate fast enough with the drivers to send the color values of each LED to the drivers in the time between each frame (1/30 of a second). And we need to be able to simultaneously enable and disable all the drivers.

Finally the output current must be high enough to power our LEDs with an acceptable brightness.

We have chosen these LED drivers : THL3502

  • 24 channels, allowing up to 8 RGB LEDs per driver
  • PWM 10 MHz and 8-bit brightness control, making for 25.6 µs PWM cycles
  • 10 Mbps I2C serial input, allowing us to send colors for 150 RGB LEDs in 240 µs
  • Output current : 100 mA

With the I2C interface, we cannot simultaneously fire and disable all the drivers. If the delay gets too big, a solution could be to separately control the current output to the LEDs with transistors.

Wifi

We will need Wifi to communicate with a Phyllo from a computer, and probably to communicate between Phyllos. At first, we wanted to use an ESP32 because it’s simple to use and easy to find help online. But after discussion with Alexis, we will use a AMW006.

SD

We would like to be able to upload complex animations frames on a Phyllo and maybe allow users to do the same. To provide the necessary storage space, we will use an SD card : JAE_ST1W008S4ER1500.

Angular position sensor

To be able to display neat and clear animations in a precise direction, we must be able to detect the alignment of the motor with its original position with an accuracy of less than half a degree (to have distinct images like J. Edmark). To do so, we will use a Hall effect sensor (TLE4964) and we planned an optical sensor (the same than Cyled : TCUT1600X01) just in case, even if theoretically, the Hall sensor is precise enough. The idea is to get a pulse every rotation and use these to deduce motor speed, and then integrate the speed, coupled with the once-a-rotation pulse, to deduce the angular position.

IrDA

To communicate inside a Phyllo between the fixed part and the rotating one, we will use IrDA. We have chosen these transceivers : TFDU4101-TT3.

The IrDA Design Guide requires a transmission distance of 0cm to at least 1m and an emission angle of at least 30 °. Thus, if we place the transceivers close to the axis of rotation, they will be able to communicate during most of a turn, so no worries about the transmission speed.

If we can not place them close enough to the axis of rotation (because of the wide motor diameter), we can reduce their directivity by putting a diffuser so that the LED illuminates the entire interior of the phyllo (or at least most of it) and the two transceivers can communicate all the time. It will not be necessary that it affects the communication of the other Phyllos.

If we cannot place them close to the axis of rotation nor diffuse enough light, and we are obliged to place one at the periphery of the PCB: we place one near the center facing outwards, the other on the periphery oriented towards the center. They will be able to communicate during 2.7ms minimum. In this case, we must take elbow transceivers like TFDU4101-TR3, probably faster ones…

To be continued…

The following post will detail our ideas about detection of other Phyllos and communication between them. And Monday, we have a meeting with Alexis to decide on a solution. We will keep you updated 🙂

Architecture: “The more it’s simple, the more it’s simple”

First, the work of some students

We spend a whole week working with just a few responses from Alexis, so we try on our own to find out how to make our architecture. This is what it would look like

We spend a lot of time exploring the best components, as you may have seen it in our previous posts.

We would have to make a lot of FPGA programming for the I/O expander, but we thought it was our unique solution.

We spend some times looking for a sensitive captor touch with only one key and the way to use it because we wanted to use the sensitive captor touch of an ESP32-WROOM-32D.

Then, destroy everything with a single Alexis and build again

We had a meeting with Alexis yesterday. He explained to us that the sensitive captor touch of the ESP32 wouldn’t do the job through the wood. One component to change. Fortunately, we already found a 3-key sensitive captor touch, we just have to make sure it will have enough strength to work through the wood.

Then, we spoke about the price and the length of the device. With 64 I/O expanders, Touch would be too expensive for funding it, that’s why we choose to make only a 16×16 grid of marbles.

The next step was the I/O expander: we cannot use them for our hall effect sensor because they are analogic and not numeric. We thought to change for numeric ones but we will come back to them later

We still need a lot of I/O expander, that’s why we need to find a better architecture for our H-bridge. Alexis first thought to make something similar to the architecture of a digicode. One half H-bridge by line, and one by column. If we want to activate the third coil of the fourth line, we would put VCC on the third half H-bridge and the ground for the fourth half H-bridge.

Finally, taking a look at our H-bridge gave us the best solution. This H-bridge can be controlled by an I2C bus, and we can give each of them a special address, so they can be on the same bus: instead of 32 pins, we just need to use three pins. Two for the I2C bus and one for the address, that we will link to some shift registers to control their address.

Now, are we happy? Not exactly, we still need to find how to control our hall effect sensors. A brief look at component gives us our last solution. We would use some analog multiplexers. So, here is our new architecture.

And now?

We are waiting for some coils and Hall effect sensors, and we will begin our tests.

A first look at the FPGA architecture

In order to synchronize the LEDs and create a persistence of vision image, we use a CycloneV SOC.

Here is a first idea of the architecture we might use :

The ARM processor fills a buffer with the next image to be displayed, that is then swapped with the second buffer. It can pull this image from the SD card, or from another source such as the text printing function we plan on adding.

The full buffer is then accessed by a Direct Memory Access (DMA) IP that then sends the relevant cylinder (32 * 128 pixels) to each LED band controller that is then stored in their memory.

The sync module uses the signal from the hall effect sensor to compute the current rotation speed and deduce the approximate angular position of the rotating part(current_angle).

This current_angle combined with the pcb_angle parameter (that gives the angular position of the PCB in the configuration) allows each LED band controller to read a in the relevant addresses of their memory and flash the LEDs with the color corresponding to their position.

This first draft gives us an idea of the architecture we are going to use, however a lot of choices have still to be made, such as the type of buses to use.