When you try to rotate at a relatively high speed, centrifugal force comes with the territory. The issue is that PCBs are not the most robust pieces in a mechanical system. We need to find a way to make them stronger to hold them in place so they don’t fly away and/or break and find their way into a bystander’s face.
We tried to figure out how much the PCBs would flex. Thankfully, Wikipedia exists and our problem is a classic strength of material case. We have an issue similar to beam theory’s cantilever beam case with a spread out force. Wikipedia has an article with the relevant formula giving us the information we need.
the last formula is the one giving the vertical flex in relation to x. In this formula, w is the force per length, E is Young’s Modulus for the material the beam is made of, I is the second moment of area for the beam and L is the beam’s length.
With this formula, we can deduce that a PCB will flex about 2.5cm if left on its own. Needless to say, in this formula, an assumption is made that it would not break. We need to find a way to reduce flex as much as possible.
A path to solutions
We explored ways to make the PCBs stronger. For now, the best solution we have is small steel beams on each side of the PCB. We estimate that flex would then go down to about mm. There might be a better solution but we have not found it yet and mm of flex over a cm PCB does not seem to be that much and might work.
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.
We need to be able to drive our little magnet marbles and flip them according to a magnetic field direction or the opposite one. To do so current must be able to flow both ways through our self-inductances. Moreover we’re going to need current’s intensity of a much higher value than what is able to flow out of or flow in the GPIO.
One way to do so, is to use a H-Bridge as we can see on this site that we’ve already mentionned in an earlier post.
What’s an H-Bridge
Basically an H-Bridge is a electronic circuit built with drivable switches in a way that allows us to flip the voltage on a load and thus allows us to flip current polarity.
the configuration where S1 S4 are closed and S2 S3 are open and
the opposite configuration
By switching from one mode to we are able to revert current polarity by changing which voltage source terminal is connected to which load terminal.
FET transistors are usually used as switches to drive the load. Below we can see a typical implementation with NMOS and PMOS.
H-Bridge implementation with MOSFETs | Source : os.mbed.com
How we plan to implement the H-Bridge
There’s two ways to implement H-Bridge circuit. Either we do it ourselves hand picking the transistors and doing the circuitry ourselves or we pick a H-Bridge driver integrated circuit. We choose the later solution as implementing the H-Bridge by hand can be tricky and unnecessarily complicated for our project.
Moreover, H-Bridge drivers are more advantageous as they have protections against over-voltage, under-voltage, overcurrent etc.
How we choose the driver
There’s two ways to implement H-Bridge circuit. Either we do it yourself hand picking the transistors and doing the circuitry yourself or we pick a H-Bridge driver integrated circuit. We choose the later solution as implementing the H-Bridge by hand can be tricky and unnecessarily complicated for our project.
Moreover, H-Bridge drivers are more advantageous as they have protections against over-voltage, under-voltage, overcurrent etc.
How to choose the driver
There are many criterias that we considered to choose the driver.
First of all, one criteria that seems obvious but we didn’t know about before talking with our professor in charge, is that the driver must be designed to be used with inductive loads. This is not always the case as we can find H-Bridge drivers for capacitive loads.
Initially we’d like to have a 32×32 marble matrix and if not possible a 20×20 matrix at least. It is consequently obvious that price is a critical criteria. As each of our marbles needs to be individually drivable, we often need for one component to order as many as we have marbles.
One way to reduce the number of H-Bridge drivers we’ll need, is to look for drivers designed for multiple loads. This is an important criteria as it possibly allows us to reduce the final cost for this component but also because it may also allows us to gain space on our PCB.
Likewise, driver package size is equally important as we’ll need for each marble a set of components (self-inductance, Hall effect sensors, H-Bridge drivers). It’d be too bad to have to space out the marbles because we don’t have enough space under them to fit all components.
Last but not least are the voltage of the power source and the maximum current that can drives through. We estimated that we won’t use currents higher than 1A to generates the magnetic fields so we looked for drivers in this range. As for the power source, we thought that 7V should be more than enough.
Giving all these criterias we looked for a good compromise and we ordered these two drivers for testing :
As referenced in a previous post we need a way to wirelessly transfer power from the static part to the rotating part of our system. We found a 200W dev kit from Würth Elektronik but it seemed over-powered for our needs. Another integrated solution exists but is only good for 60W. Therefore we needed to estimate how much power our rotating system would need.
The bulk of our needs is in the LEDs. Considering 1280 LEDs and a multiplexing factor of 1:4, we would consume at most the power of 320 LEDs at a time. According to the specifications, an LED could use 60mA@3.3V at most. This gives us a max power consumption of 63W just for the LEDs. Even though this is a worst case scenario, it seemed to us that using a 60W power supply would be too risky, even more with all of the other components (SoM, wifi module etc..) and taking into account a DC-DC converter efficiency of 95%.
Since we couldn’t find another solution for wireless power transmission between 60W and 200W, we stuck with the 200W option, a using only coils and making our on driving circuitry would require us to be experts in induction power transmission and power supply design.
Motor and ESC choice
Our search for a BLDC motor took us all over the e-bike, drone and RC car and boat world. At first, we found a motor at Alien Power Systems but couldn’t find an ESC to match so they directed us towards Maytech. They make both ESCs and BLDC motors. We need a motor with enough torque to start the rotation considering our system will be quite heavy compared to an RC car or a drone propeller.
Getting both the motor and ESC from the same brand made it so we didn’t have to solder connectors or bother with pinout issues. It would allow us to have better support down the line should we have a technical issue. We then chose a Maytech MTVESC50A for our ESC which gives plenty of power for the Maytech 5055 1100W 70KV motor.
LitSimulate is a simulator which simulates what LitSpin will display. We developed the first versions with PyOpenGL and PyGame.
Image Format
Each 3D image is represented by a classical image. If we note r the radial resolution (total number of columns), h the number of LEDs by column and n the number of steps by rotation, our image dimensions are rh x n. In our case r=20, h=32 and n=128. So we have 640×128. One line represents the n points one led will display. And each block of h lines represents the 360° image of a column from the outermost to the innermost (from 1 to r). Just below an example with r = 8.
Example of image for r=8
Examples of simulation
We made some simulations with r=10, h=10 and n=100
Input image
Simulation side view
Simulation top view
Input image
Simulation side view
Simulation top view
Input image
Simulation side view
Simulation top view
Limitations
For now, we simulate an 8-bits-by-colour display and not a 9-bits-by-colour one. This is just because it is easier to create an 8-bits image on the internet rather than 8 bits. However, it will be very simple to change LitSimulate into a 9-bit simulator.
The main issue is a problem of memory. Indeed, the RAM is constantly filling up until the PC is completely blocked. So we can only use this first version of the simulator for a few seconds. Moreover, we can’t simulate with our real values of r, h and n because it takes too much memory to display the results. To deal with this issue there will be several steps:
We will try to fix it by keeping Pygame et PyOpenGL
If we can’t, we will try without PyGame and only use PyOpenGL (because PyGame is used to initialize OpenGL display). Maybe we would directly go to step 3
If it is still too slow, we will make the simulator in C++
If it is still too slow or too complicated, we will try the Point Cloud Library for C++
For our project, we need to test our components in order to find the best way to control our marble. Good news, our project has been done in other ways before. That’s why we take a look at this webpage: https://wiki.fuz.re/doku.php?id=projets:datapaulette:1bit_textile (in French)
Diameter of the marbles
Our first idea was to choose the smaller marbles, which have a diameter of 5mm. I have some of these marbles at home, so I tried to make a prototype with some cardboard.
Conclusion: my biggest fear was that a marble would move the other marbles when we rolled it (because of a too big magnetic field), but with my prototype, they don’t. If no, we would have to always create a magnetic field with our coils and that’s impossible. We would have to change our project for toroids, which are uglier. The other thing is the fact that 5mm marbles are not really easy to roll. That’s why we choose to order 6mm, 8mm and 10mm marbles for our test
The coils
The other project also uses coils. The main difference is the fact that our coils are not hand-made, and our coils are under the marbles, not around them. However, they should have the good range for the coil. We just have to do a little calculation we learned when we were in Classe Préparatoire, with the value given by the other project.
60 turns, 50mA, 6mm circle and a distance equal to almost 0: the coil is about 0,6mH
With a 0,1mm diameter wire and a typical resistance of 5A/mm², we find an RMS current of almost 400mA
We choose bigger coils because they would ask less current from our processor for working. We finally ordered ten coils of 3mH, ten of 1mh and three of 680µH (the last stock, if we choose theses ones, we would take an equivalent) for our test
Hall effect sensor
For this sensor, we have to choose which type we want. Understanding the different type is not easy, but you can find plenty of web articles about this. The best thing is to have a linear sensor because we will have a better idea of the state of a marble. When it will be on one way, the field will be negative and the sensor’s tension under 1,75V and on the other way, it will be positive and the tension over 1,75V. We also choose a directional sensor that gives the field in the three directions of space. It might be harder, but we could choose only one sensor for four or nine marbles if it works well and if the fields are easy to distinguish
I/O expander
Finally, my last contribution for today is the I/O expander. First, we look at the possibility given by the project Datapaulette: shift register. After a short time of reflexion and the help of Alexis, we understand that it was a bad idea because we cannot control as much as we want the current in the coils. We will have to choose an FPGA that will give us enough I/O for our device. We need a total of 2048 I/O pins (one for the value of the Hall effect sensor and one for the current on the coils, the others will be linked to the ground or to VCC). We will wait for the end of the tests to choose our expander, but it should be one of these expanders. We just have to choose which number of ports we want by expander.
In order to better understand how to make LitSpin a coherent and functionnal device, we created a diagram of its architecture .
The following represents how the different modules will communicate and work together. Technical details will come later as choices in components and communication buses are made. This is not supposed to be a drawing so it is not representative of how LitSpin will look but it should give an idea of how it will work.
Basically, there will be two main systems. A static system that will have an electric motor and what is needed to control it : a control board that will communicate with an Electronic Speed Controller, the accompanying BLDC motor, an IR receiver that will get information from the rotating system and the induction power transmitter.
The rotating system will contain the bulk of the project. The DC-DC power supply converting 24V to 5V, our SoM, LED drivers and multiplexing circuits and other modules. The SoM will contain both an ARM processor and an FPGA element to control the drivers and multiplexing circuits.
In order to have one driver per 64 LEDs, we will be multiplexing our LED outputs 1:4. Each PCB will then consist of 32 LEDs on each side, one TLC5957 driver and the multiplexing circuitry.
As for communication, the rotating system will have a Wifi module that a user will be able to connect to and an IR LED to send motor control information to the static PCB.
Our original idea was to place LEDs on the inner sphere of the sculpture, either with flex PCB, or by drilling the sphere, placing the LED in the holes and connecting them with wires to a rotating PCB contained into the sphere. To facilitate the positioning of the LEDs, we could have modified the design so that we can pin the petals one by one on the inner sphere rather than print everything in one block.
But these designs are not easily achievable. First, Alexis does not know how to design flex PCBs. Second, to have a satisfactory visual impression, we would like to have at least 100 petals. To justify this number, here is a model with 60 petals, and another with 100 petals, and a third with 150 petals.
With 60, 100 and 150 petals respectively.
In the above images, there will also be petals all the way to the center, but there will be only one light for all of them. In the above images, only the petals that would have their individual LED are shown. There will of course be petals all the way to the center, but the center ones will all share the same light.
With 100 petals and a single LED per petal, it would make 400 solder wire, which is unthinkable (especially given that the sculpture will turn).
Flat PCB
After discussion with Alexis, we agreed to place the LEDs on a flat rotating PCB with the same phyllotactic arrangement. Here is a simulation example to imagine how we will place the LEDs:
The idea of abandoning 3D sculptures without struggle did not please us. That’s why we will try to give a 3D impression while leaving the LEDs on the flat PCB. To do this, our best idea so far is to use light pipes to guide LEDs light to the petals, like in the figure below:
Ideally, we would be able to keep flower-shaped sculptures similar to those of John Edmark. But in case we cannot have full-blown 3D sculptures, we could still add a little bit of relief. Here’s what it could look like:
Today, Alexis has ordered a selection of compatible light pipes and LEDs, so that next week, we can do tests to measure the loss of brightness per cm inside the pipes and the influence of a LED on its neighbors (loss of brightness at the entrance of the guide).
LEDs overheating
Another problem that we are likely to encounter is the overheating of the LEDs. For 100 RGB LEDs (which need to be switched on at the same time), with a maximum of 100 mA per color, a current of 30A is required. So if we power the LEDs with 4V, we need a power of 120W. We started to think about solutions to cool the LEDs: drill holes in the sculpture to ventilate the LEDs, use a Metal Core PCB (MCPCB, such as below) instead of a FR4-PCB, use heat sinks, LEDs with an electrically isolated thermal path (such as Cree XLamp LEDs).
Layers of a MCPCB
But our LEDs will be under light pipes so they will not be well ventilated by the holes in the sculpture. The MCPCB will not allow us to put all the components that we need, in particular we can not solder components on the back of the PCB. The mask solder is only on the top layer, on which the LEDs are placed, and the bottom layer ends with aluminum or copper, and it is not possible to add FR4 and copper after the layer in aluminium. And the heat sinks all seem to have a disproportionate size for our use.
Before continuing research on the overheating of LEDs, we will use LEDs already ordered which I mentioned above to test their heating.
If you have any idea or suggestion, all comments are much welcome !
We need to generate 3D models of phyllotactic patterns.
We give an explanation of how to generate phyllotactic patterns on a sphere.
We present an issue we encountered, and the solution we found.
Why 3D Models ?
When we first started thinking about the project, we quickly realized we would need to generate 3D models of the sculpture ourselves.
First because we need to have full control on the model, to try various configurations for the future 3D printed sculpture. And second because it will greatly help us visualize all the kinds of animations we are imagining.
We place the first point on the “equator”. Then to place each following point, we rotate 137.5° and move a little closer to the top of the sphere.
The big question is : how much closer is “a little closer to the top of the sphere” ?
137.5° is the golden angle, derived from the golden ratio. It has the nice mathematical property of being as hard as possible to approximate with rational numbers. This allows it to waste as little space as possible, which is why plants use it. And it looks nicer. You can try the simulation on this page to get a better grasp of this.
A First Attempt
The first thing we tried was to actually place the points on a cylinder, rotating them 137.5° and going up by a fixed amount each time, and then projecting those points onto the sphere :
Projection from the cylinder onto the sphereThe projected pointsConnecting the dots
But we soon noticed an annoying discrepancy between what we got, and what John Edmark’s Blooms look like :
A Bloom by John Edmark on the left, our attempt on the right
Our petals get more and more squashed as we near the center.
A consequence of that is, if we follow a spiral from the center outwards, at some point we’ll realise that what we’re following isn’t a spiral anymore.
All this doesn’t happen with John Edmark’s Bloom.
Follow a clockwise spiral from the center outwards and see what happens
The same thing actually happens in sunflowers:
Spirals “breaking up” in a sunflower
But in our case, it happens because the points step too slowly towards the center, whereas in a sunflower, they step too fast.
A point on the sphere can be located by two arcs of a circle : parallel arcs (“horizontal”) and meridian arcs (“vertical”). To rephrase the previous explanation, we place each following point by moving along a parallel for 137.5°, and then moving up along a meridian for some arc length.
A face formed by intersecting spirals
As we get closer to the top, the parallel arcs of circle become smaller.
The meridian arcs also need to get smaller, otherwise we would overshoot the top.
We want the meridian arc lengths to decrease so that the faces keep roughly the same square shape.
To do that, they need to decrease at the same rate as the parallel arc lengths, to remain in proportion.
A bit of geometry yields this differential equation, where a(x) is the “vertical” angle between point x and the horizontal plane, and k is a coefficient:
a'(x) = k cos(a(x))
a(0) = 0
The solution is:
a(x) = Arctan(sinh(kx))
We had to tweak the value of k a little bit to get nice results.
Here’s what it looks like:
3D rendering of our latest design
Flat Circular Phyllotactic Patterns
We can do the same thing with flat circular patterns : place each following point by rotating 137° and moving closer to the center. The question is still “how much closer ?” and the geometry is merely a bit different.
We get this differential equation, where r(x) is the distance of point x from the center, k is a coefficient and R is the radius of the circle:
This is a follow-up to my previous article, in which we explored the choice of PCB placement in order to get an optimal visibility.
My previous analysis only covered the case of a punctual point of view. However, most people have two eyes, which provide a double point of view and could increase our coverage of space. It is to be pointed out that a point of space seen by one eye does not provide depth information to the brain, however let us assume that our image perception is smart enough to overcome this limit.
In the following simulation, we used a typical eye distance of 6 cm. To understand the different configurations, please refer to this article.
One eye
Two eyes
Stairs configuration, 40 PCBs. In the new two eyes simulation, the red dots represent the points that can be seen by the right eye, while blue dots are for the left eye. Dot sizes still represent brightness and dots are transparent so that we can see when left and right vision blend.
Constant-angle spiral, 40 PCBs.
Constant-distance spiral, 40 PCB
Modulo forest, k = 3, n = 40
Modulo forest, k = 7, n = 40
Modulo forest, k = 11, n = 40
Modulo forest, k = 13, n = 40
As you can see, the dispositions that seem to benefit the most of stereoscopic vision are modulo forests, particularly the ones where the repartition of PCBs seems the most uniform. The parallax effect is all the stongest when PCBs hiding each other are far away in the axis of vision. Modulo forests with k = 3 and 11 seem to be good candidates as the front portion of the cylinder is (almost) complete in both cases.
