Have you ever played with some neodymium balls? These are potent magnets, so we had to find a way to use them in our device without making them dependent on the magnetic field of another marble. Because if we had to manage this field, we would have always to power our coils, and they would have burnt. That’s why we choose to buy many different balls to try to find the best compromise between the distance and the diameter of the marbles.
With a plank of beech, we cut with a laser engraver. We made many different holes of many diameters with various distance to know which one is the best. We already made 40 holes, and here is the result.
Please stay far away from me
The 10mm marbles were too powerful, the 5mm were too small, we cannot use them, the 8mm too. We were waiting to have the 6mm marbles, hoping they would solve all our problems… When we finally had them, we tried to make a square with 10mm between our balls (the one on the right on the previous photo). The marbles were still too powerful, we cannot flip one of them without flipping the others. The minimal distance for this was the diagonal of the square, which is very big (about 1,4cm, if you remember the old Pythagorean theorem). So we try to use another type of neodymium component: a ring magnet. One more time, it’s too powerful.
At last, we will try to make it with the 6mm marbles and to use another magnet which has less strength.
Yesterday I set out to test the LEDs we received : ASMG-PT00-00001 and LE RTDUW S2WP. The first is a powerful RGB LED, while the second is an even more powerful RGBW LED. They need to be quite powerful because in order to avoid a blurry image due to the motor rotation the duration of the flashes must very brief, and since the LEDs are flashed only once every 137.5 degrees of rotation that means they are off most of the time.
The goal here is to test under conditions similar to those the LEDs will actually be used in : once every 1/30 seconds, they will be turned on for 100µs using high frequency PWM modulation for the colors, and then switched off again. Vlaya previously 3D-printed a few different-sized petals to test how well the LEDs manage to light them.
So the first thing I had to do was find a way to generate the needed control signals. To that end, I adapted a previous ChibiOS project on an STM32-E407 Olimex Board to quickly generate the required PWM on GPIO pins.
Since the LEDs require too much power, they cannot be driven directly by the GPIO pins. So we’ll use transistors to drive the LEDs with an external power supply. For the test itself I used a ULN 2803A Darlington transistor array.
But first, the LEDs had to be soldered onto mounts for ease of use :
It turns out the transistors in the ULN can deliver at most 500 mA, while the LE RTDUW S2WP, which is among the most powerful SMD LEDs we found, requires 1.4 A. On top of that, we didn’t have adapted resistors on hand. So I ended up only testing ASMG-PT00-00001 yesterday. We’ll test the other LED on Monday, although this one already seems to be bright enough for our needs.
Here are some pictures, taken in the dark and under bright lights :
Since we plan for the Phyllo to be used mostly in the dark, this seems like it will be bright enough 🙂 . But we’ll still try the other LED on Monday. We’ll keep you posted !
We received the coils denominated SDE1006A-681K. These are 680 µH inductance coils.
We roughly soldered two wires on each pole of the coil as you can see on the image below for very basic testing.
Next we needed to connect it to the IoT node. As a very basic montage for testing, we configured user button with polling on the IoT node to drive one of the GPIO pin we have on high when pressed.
We used a resistance to limit the current output. As we wanted a current of the ordre of the mA we used a resistance around 1 kΩ. We brought the magnetic marble near the coil, far enough to not be attracted by the coil with no current flowing through but close enough to be affected by the generated magnetic field.
We pressed the button and … SURPRISE ! Nothing happened.
More, more, more ! More power !
In need for more power, we headed to the e-lab. We connected the coils as follow :
The DC voltage source has two parameters : the voltage we want it to output, and the current limitation. If the current flowing through the montage should go higher than the limitation, the voltage source will drop so it stays within the current limitation.
As such, with the very low resistance of our coil and because the generated magnetic field depends only on the current flowing through the coil, we were able to use the DC voltage source as a DC current.
One needs to keep in mind that this is a gross montage, and a risky one as with high currents flowing through the coil the latter will heat up a lot. With this in mind, we kept constant monitoring on the montage and never let the generator on for more than few seconds.
At first we were desperate as we weren’t noticing any effect on the marbles. With perseverance and faith in the physical laws of this world, we were first able to notice a slight movement of the marble. Wheeew ! Finally ! Little by little we were able to make a marble move, then a torus as you can see in the videos below.
By the end of the day, these tests have raised serious power issues as we experienced that the bare minimum current we need is roughly 500 mA. We need to keep in mind however that these test were for the lowest inductance coil we ordered.
With these power issues into account, we will also have to find a way to fip one marble without flipping the neighboring others. Also as the magnetic field of the marbles is unexpectedly more powerful than we thought, we’ll also have problems wtih the marbles alone, without accouting the magnetic field we generate.
What now ?
Basically, we’ll have to find a solution such that we can flip a sole marble by hand without flipping inadvertently the neigboring ones WHILE being able to manipulate these same marbles with the coil.
We’re actually testing a lot of different configuration of magnets, magnet size, spacing between the magnets, size of the openings in the wood (which directly impact the friction with the marbles and thus the liberty of the marbles), support material…
We’ll need to discuss this with Alexis and do some more testing with the other coils once we receive them.
In order to start testing our components (Hall effect sensors and coils), we needed to decide which board and which OS we will use.
Our project will not need to run any complex computation nor doing complex network communications. So almost all processors we checked could be used. We decided that it was better to take a controller little endian based on an ARM processor (because we are more familiar with arm’s instructions). We also wanted it to be low power and not too expensive. With those considerations, we went toward the STM32L475VGT6 because we already had boards at school with it. This way we will do our tests on the same controller we will use for our PCB.
So we will use the IoT-Node from STMicroelectronics.
The Operating system:
We previously worked with this board to do a bare-metal project but this time we figured an OS would be useful (no offense to SE203, last year’s best course).
We already had experience with ChibiOS with an other course and two of us had briefly uses FreeRTOS a few years back. We chose to go with this second operating system because we didn’t remembered any big difficulties to implement WiFi with it while the ethernet part of ChibiOS… let’s say it was a nice month of trying to understand it. On top of that it will be interesting to work with an OS we don’t really know.
So FreeRTOS it will be.
First steps with FreeRTOS:
The only time we previously used FreeRTOS, we already had an environment with the sources and a Makefile. And if you remember the first time you had to use FreeRTOS you probably have a smile on your face right now (and that is not very kind 😉 ).
We started by doing like for ChibiOS. We went to the website, downloaded the sources. And we found ourselves with the OS sources… but no example for the IoT Node, no board.h…
Alexis explained us that we needed to use STM32CubeMX to create the project. So we downloaded the software, found the board, generated the code and we ended up with a LOT of code. We went through a cleaning stage during which we tried to remove from the sources all the code we didn’t wanted (mainly the initialization of all the modules). And we only kept the code to configure and initialize the OS, we didn’t deleted the generated code but we removed it from the sources that are compiled to create the elf file.
To check if the OS worked correctly we added in a task a function which blinks a led.
We chose the STM32L475VGT6 to be our controller and we decided to use the IoT-node to do our tests. We also chose to use FreeRTOS for both the tests and the project. We currently have a simple script blinking a led of the board.
In the next days we will start testing our Hall effect sensors and our coins to decide which ones we will use on the final PCB and to estimate the power consumption we will have.
We discussed in our post Generating 3D Models the script I wrote to generate the 3D model of our phyllotactic sculpture. In this script, I start by generating a polyhedron made up of quadrilaterals arranged in a phyllotactic pattern:
Then, my script takes as input a 3D model of a petal and copies it on each quadrilateral:
One problem with this method is each quadrilateral is different, which means I had to slightly deform each petal to fir the quadrilateral’s shape. Figuring the exact 3D transformation to accomplish this seemed a little too time consuming so I used lattices in blender, which are a way to deform objects according to a 3D grid. It turns out the result is not perfectly clean, and leaves small gaps between petals:
We also noticed the petals on John Edmark’s model are not all identical: they all have slightly different orientations, and therefore appear to slowly rotate on themselves when animated.
Using identical petals leads to a much less interesting animation. These two problems led me to abandon this method of generating petals, and procedurally generate them instead.
In order to do this, I chose to use NURBS, which are a way to generate smooth surfaces using a 2D grid. This is also what John Edmark used to generate his petals.
Reproducing the petals will likely take some time, so for now I only generate simplified petals. Manually modelling the petals with NURBS surface wouldn’t be that hard, but generating them within a script from a quadrilateral given in input, and being able to control their orientation is a whole other story…
Controlling the orientation of this simplified petal is quite simple : I only have to move around the upper polygon.
This new method allowed me to generate a clean model of our sculpture, with a nice rotating effect on each petal:
I’ll probably attempt to model more complex petals during the winter vacations, so stay tuned for that !
In a previous post we discussed several ideas on how to detect the direction of neighbouring Phyllos relative to a given Phyllo. Our favourite idea in this post was based on a mix of Wifi and IR : the Phyllos would cooperate using Wifi to turn their IR emitters on one at a time to allow the others to detect it using IR detectors.
But this idea raises several problems. The most notable is IR reflections : they could spoof the Phyllos into detecting neighbours in the wrong directions. We thought we would be able to differentiate an IR reflection from a direct emission by comparing the amplitudes, but according to Alexis, we will have too much trouble. Moreover, we have ignored so far the possible interference with the IrDA which is used for communicating between fixed part and rotating part within the same Phyllo, and it might not be that simple to isolate the interior of the hull of a Phyllo from external IR radiation.
However, we still think the basic idea is good : combining a direction-finding method that allows each Phyllo to enable or disable its ability to be detected, with a communication channel that the Phyllos can use to cooperate and make themselves detectable to the others one at a time.
That’s why we thought of other solutions. Our best idea so far is inspired by the idea of magnetic sensors described in the same previous post. We would like to use a very sensitive and precise magnetometer, like MPU9250,LIS3MDL, IIS2MDC or LSM303 (less precise but more convenient to use) on the rotative part of a Phyllo, to detect a powerful electromagnet in a neighbouring Phyllo. First, the Phyllos talk over BLE or radio (protocol under discussion …) to determine who is here and give each other unique identifiers. Then, in an agreed upon order, the Phyllos turn on their electromagnet one at a time. When a Phyllo has its electromagnet turned on, the others can use their magnetic sensors to find in which direction it is.
In other words, the electromagnet will replace the IR emitters of our previous idea, and the magnetometer replaces the IR sensor.
The trouble is that there will be plenty of other magnetic sources around : the Phyllo’s own engine, the engines of the other Phyllos. One possible solution is to make a profile of the surrounding magnetic fields during one rotation before turning on any electromagnet. Then, when we detect other Phyllos, we’ll filter out these interfering fields.
Alexis will bring the MPU9250 on Tuesday so that we can check the viability of this possibility. We will keep you posted 🙂
We made a few major modifications in our design : it turns out flex PCBs aren’t possible. Even though everything isn’t quite decided yet, here is a summary to clarify the situation. I will keep you updated of any major modification 🙂
A Phyllo is composed of three parts:
a fixed base,
a rotating half sphere placed on this fixed base serving as support for the lighting of the sculpture,
a hull made of petals that covers this sphere.
A Phyllo has 78 petals that can be illuminated individually (8 spirals with 6 petals lit by spiral arms, or 13 spirals in the other direction). The remaining petals are the tiny petals at the top, and they will all share a common illumination.
The diameter of the inner sphere measures about 15 cm, the base is about 20 cm.
From there, when one is interested in the projection of the petals on the inner half sphere:
the smallest petal that can be illuminated measures 0.83 * 0.79 * 1.04 * 1.14 cm.
the centers of the petals are at least 0.97cm apart.
Organisation of the PCBs
Each Phyllo will have:
1 fixed PCB in its base,
1 rotating PCB near the equator of the inner half-sphere,
62 PCB-petals to illuminate the 62 largest petals,
1 PCB, called “Top PCB” to illuminate the remaining 16 petals as well as the top of the structure.
The PCBs-petals are therefore placed inside the half-sphere as in the picture below:
The top PCB will have a star-like shape as in the image above.
The PCB-petal shape is yet to be found. If we use the shape of the image, we will have to make a bigger Phyllo in order to have enough room on the PCB for all the components. We had the idea of T-shaped PCBs as in the picture below, but according to Alexis, it will be too complicated to wire.
We also had the idea of overlapping PCBs for small petals and using printed tubes to conduct the light, like in the picture below. But the possibility of wiring is still under discussion.
Any comment or suggestion will be much welcome !
The following diagram summarizes the functional architecture of a Phyllo:
The fixed part of the Phyllo will contain the motor, the ESC, the battery, the power transmission device and the fixed PCB. The fixed PCB will include:
an IrDA transceiver to be able to communicate with the rotating part of the Phyllo,
a connector for the battery,
a charging circuit of the battery,
a 3.3V regulator,
a USB port to recharge the battery (and the circuit that goes with it to feed the Phyllo while the battery),
an electromagnet to be detected by other Phyllos
a SWD port for debugging.
To clarify a previous post, here is a shema of the device for power supply transmission from the fixed part to the moving part is based on the use of ball bearings as follows:
The idea is to transmit one terminal of the battery through the motor ball bearing by soldering a wire to the motor and another to the axis. To pass the other terminal, use two other ball bearings, electrically isolated from the shaft by a rubber sheath.
Detection of other Phyllos
We are still discussing how exactly to go about detecting other Phyllos. We discussed several possibilities in [this previous post]. Our favorite lead then included using IR emissions to determine the direction of a neighbouring Phyllo, but it has since then become apparent that IR reflections would be a serious problem. More on this in the following post.
The rotating PCB is the one where all the logic of the Phyllo is happening. It includes :
an IrDA transceiver for communications with the fixed part,
a hall effect sensor (and an optical sensor just in case) to detect the angular position of the motor and to be able to play animations in a chosen direction,
a module wifi to be able to communicate between the Phyllos and with a Phyllo,
an SD card connector to be able to store complex animations on the Phyllo,
a 3.3 V regulator,
a 5V regulator,
a magnetometer to detect other Phyllos,
a BLE/radio module for fast communication between Phyllos (WIP).
The PCBs of the petals are fed in parallel and receive their information by SPI bus.
5 * 2 pads for soldering SPI bus wires, ground, power supply,
3 pads to debug in SWD.
We don’t really know the luminosity we will need : these LEDs are really powerful and consume a lot (1,4A per color) but they are turned on only for about 100us, 30 times per second and will be inside the petals. We have ordered these LEDs and the next ones in order to run tests this week.
All PCB-petals are connected in parallel on the same SPI bus. We will still prepare 4 SPI buses (in case we need to multiplex the spirals: 4 spirals per bus and the upper PCB only).
On this SPI bus, 16-bit frames are transmitted. The first 8 bits specify the number of the LED being caused, with 0 being “all” (and other particular commands to be set). The next 8 bits determine the color of the LED so the address has been sent.
With this method, we need to be able to transmit 16378 + 2 * 16 (a different color for each petal + top and stop signals) in 1/30 s (duration of a motor revolution), so we need a transfer frequency on the SPI bus of at least 0.12 MHz, which isn’t difficult to obtain.
It allows to light the remaining petals, too small to be lit by PCB-petals.
We decided to use the TLC5957 LED driver of Texas Instruments with Broadcom RGB LEDs: ASMB-KTF0-0A306.
First, we have to determine the maximum current which will be used. The 3 colours of the RGB LEDs can get a 20 mA input current max and the driver can handle 20mA sink current max. So we choose a maximum current of 20mA.
We decided to configure the driver with the maximum value for the Brightness Control (BC) (and by consequence, the maximum gain) to provide the intensity to go over 20mA. So we have to choose a value of BC equals to 7. And to limit the current to 20mA max we have to put a 9.27kΩ IREF resistor between IREF and IREFGND pins.
After that, we have to choose the Colour control for each colour. This parameter is used to choose for each colour, the ratio between the maximum output current for this colour and the maximum output of the driver. This is used to tune the white balance. According to the LEDs datasheet, the mean intensities are 490mcd for Red, 1100mcd for Green, 215mcd for Blue. So, to have the same mean intensity for each colour, we have to choose those values for CC: 224 for Red, 100 for Green, 511 for Blue.
The main mode of this driver is done to be used with 16-bits colours. However, we want to use it with 9-bits colours. So, we have to use the other mode: the Poker Mode. When we choose the Poker Mode, we have to activate the ES-PWM and the XREFRESH.
The driver contains several registers. We will use the 4 main ones. The first one is the Common shift register (48bits). Every data one wants to input has to be written in this register. The second one is the FC data latch (48bits). This register is used to configure the driver. Both last ones are GS data latches 1 and 2 (768bits each). They are used to save the data and prepare it to be sent to the LEDs.
The communication between registers is led by the SCK clock and the LAT signal.
How to use the driver
First, we have to configure the driver so, we have to configure the FC data latch. To do so, we send bit after bit the 48bits configuration from the MSB to the LSB. In this configuration, we specify different values like the BC, the CC for each colour. We also activate the Poker mode, the ES-PWM and disable the XREFRESH. After sending the 48bits, we send the FCWTREN (LAT high for 15 rising edges) command then the WRTFC (LAT high for 5 rising edges) as below.
In the traditional mode, we input in the common register the 16bits of each colour from Blue to Red and from MSB to LSB. But, in Poker mode, it is different. We input the bit n of the Blue of the 15th LED then, the bit n of the Green of the 15th LED … until the bit n of the Red of the 0th LED.
So because we use 9-bits colours, we have to first send the Bit 8 of the colours of 16 LEDs then the Bit 8 etc until the Bit 0. Then we output everything. So how does this work? When one has input in the common register the 48 bits data which represent the Bit 8 of the colours of 16 LEDs, one sends WRTGS command (LAT high during one rising edge). This command will copy the 48 bits of the common register in the 1st GS Latch at the address of Bit 8 (address given by the GS data bit address counter). Then the GS data bit address counter is decreased 1. The process is the same for Bits 7 to 1. For Bit 0, one uses the LATGS command (LAT high during three rising edges). This command will do the same thing as WRTGS but, it will also copy the entire 1st GS latch into the second one, it resets the GS data bit address counter to 8 and increased 1 the LINE counter (it will be useful later). But it also forces out the new values which will be sent to the LEDs.
Just below, an example with 10-bits colours. For 9-bits colours, it is quite the same but there are only 8 calls of WRTGS and the GS data Bit address counter starts at 8.
This is a different approach to realize a PWM. The high state period will be cut and spread to minimize the time between high and low states and get a better result.
For this project, we decided to multiplex LEDs by 4. Indeed, this driver has enough pins to control 16 LEDs but on each column, we have 64 LEDs. The process to write data is quite the same as without multiplexing. However, they are some things new. First, we will now also use a line counter. This counter is here to know in which step of the multiplexing we are; do we display the first 16 LEDs, the second, the third or the fourth ones. This counter is used by the LED Open Detection which is used to prevent the caterpillar effect but we will explain this after.
So now how do we write our data? For the three first groups of 16 LEDs, it is still the same: 8 WRTGS + 1 LATGS. However, for the fourth group, the LATGS method will be replaced by the LINERESET command (LAT high during seven rising edges). This command will do the same things as LATGS but instead of increasing the LINE counter, it will reset it to 1. That means we sent the data on every LED.
The caterpillar effect is a problem caused by broken LEDs in multiplexed architectures. As a result, the LEDs multiplexed with the broken one can blink whereas they should be off when the driver tries to switch on the broken one. The Line Counter and the LINERESET command help the Caterpillar cancelling function to detect the broken LEDs and to automatically turn off the output channel for the specific line (so only turn off the output for the broken LED and not to every LEDs multiplexed with it).
One of the most critical part of the project will be the communication. Whether it is between the Touchs of with the backend we need our device to be able to communicate.
The communication challenge:
The first thing we had to do was to choose the protocol. As we wanted to allow both a communication with a backend and between devices, we chose the MQTT protocol. It has the advantages to be easy to use and to easily allow us to switch from listening to the server to listening an other device.
The first step: the broker:
In MQTT, all devices (may it be a server or an actual connected thing) are clients. They can decide to talk (post) or to listen (subscribe). But for it to work we need a broker. It is the part that will spread the information from the posters to the subscribers. We decided to use Mosquitto. It is a free open-source broker that can be installed very easily on Linux (and also on Windows but… well it is Windows).
The second step: the server
In the same time as the search for the components, we started implementing a very basic server. We used the python library paho-mqtt which is very easy to use. The issue we wanted to deal with first was the representation of the box in the MQTT packets. As our marble will have two positions, we decided to code each one by a bit. So the first idea was to send one integer per lines which binary representation would have been the state of each marble in the line. Doing so we could easily communicate the state of the box. Yet the issue was that doing so we could only retain the last integer. The consequence would be that when a new box connects between to images it would only receive the last line.
To avoid that we decided we needed to send one MQTT post by images. The first idea was to send a string with all the integers. Yet this would have increase the size of the message and we found a more elegant solution: the byte array. So as of now we have a server that send images represented by a byte array. The first byte being the first eight marbles on the top left corner, the eight right next to those and so one to the end of the line (we don’t know yet the numbers of marble). Once we are at the end of the line, we start a new byte with the left part of the second line.
So far we have a Mosquitto broker installed on one of our computers and the server sending bytes array representing the image to show. The issue we have now is that the broker is only reachable from the same computer. We will try to figure out if it comes from the computer, the broker or from the network. Yet as we have received our coils and Hall captors the next weeks will be dedicated to testing them.
Although our initial plan to light the petals was to put waveguides between the petals and LEDs placed on a flat rigid PCB (see “About LEDs“), Alexis recently told us using flexible PCBs might be possible.
Flexible PCBs could be placed directly on the inside of the demi-sphere of the sculpture, thus avoiding the use of waveguides and ensuring a good luminosity. Their drawbacks however includes a high cost and the fact that Alexis hasn’t yet used them for previous projects.
Using flexible PCBs, our idea would be to take advantage of the symmetry of the sculpture and place identical PCBs along each of the 13 spirals. On each PCB, we put LEDs corresponding each to a petal. There is one catch though: the spirals are all slightly different… Indeed, it is an important property of John Edmark’s sculpture to have each petal placed at a unique height and angle on the sphere, with a unique size. While this is great for fluid animations (see Generating 3D Models), it makes the placement of the LEDs on the PCB a bit of a headache…
We decided to use a smaller version of our sculpture, with only 8 clockwise spirals and 13 anti-clockwise spirals (The previous images we showed you were of a 13 and 21 spiral model)
Ideally, we want each LED to be placed at the center of each petal. But using an identical LED placement on 13 different spirals will obviously introduce off-centered LEDs: our goal is to minimize this. In order to do this, I first aligned all of the spirals in the same orientation, and sorted them according to their lowest petal height:
The petals are getting in our way here, what we want is to just see the quadrilateral surrounding each petal.
We then need to flatten everything, it will makes things even clearer, and the PCB schematics needs to be done in 2D anyway.
The floor you see on this image is the actual floor of the pedestal on which the sculpture lies. You can see some petals are partly buried under the floor: they still need to be lighted for a fluid animation, but some are unfortunately too small to have LEDs placed underneath them. With this additional constraint in mind, I spent some time in blender figuring out the best LED placement, and this is the result:
Here is a superposition of the worst case spirals, which was also very helpful to design the placement:
Alexis is currently gathering information to assess the feasibility of flexible PCBs for our project, we will make sure to keep you updated on our final choice.