You can now find the final website of bouLED on Hackaday.io where it hs been featured as one of the trending projects ! Project logs will stay here, though.
An archive of the repository is also available on GitHub.
Since last post, all triangles have been soldered, including their power supplies. Getting them to work was a bit of a pain, since some LEDs got fried, so Alexis spent a lot of time replacing LEDs. Last Friday, we had to do a demo of our progress, and here’s a video of it:
There were five triangles we couldn’t use because they were missing a connector, but Alexis finished them this week-end.
The board Lucas is moving (far left) is the main board, with the AHRS array. The image is supposed to move to “counteract” the main board’s rotation: when it is inside, it would make the image static even when rotating the icosahedron.
Lucas used the projection algorithm he describes in this post, which works really well in my opinion. There’s still room for improvement, though: for instance, we haven’t figured the axes out yet. We’re also thinking about what to do in the final demo.
There are holes in the triangles that allow us to bolt them to 3D-printed pieces. Hichem designed pieces for this in OpenSCAD to join triangles together at a shared corner, but the angles were off. We also tried using FreeCAD, but it was a huge pain to use, even for simple stuff like drawing pyramids. The problem was that when using OpenSCAD, there’s a lot of calculations to do, which are easy to get wrong, and in this case, it’s way simpler to use a constraint-based CAD package. Next, we tried FreeCAD, which was somewhere between “huge pain” and “nightmare” on the user-experience scale. Even for simple stuff like drawing pyramids, it was really unpleasant to work with, although I do concede that a) we’re not mechanical engineering students, b) we’re not familiar with mechanical CAD packages, and c) we didn’t have the time to learn FreeCAD properly (didn’t take it, either).
Enter SolveSpace. This one was a bit of a surprise: it’s a TINY (5.46MiB for the Arch package !) open-source constraint-based CAD package, as opposed to OpenSCAD which uses constructive solid geometry. Even though its UI doesn’t look very modern, SolveSpace very simple and intuitive to use, and what’s more, it doesn’t try to be as featureful as <proprietary CAD package everyone knows>: its simplicity is its best asset. There are some quirks (no loft operations, for instance) but there are often ways around them. All in all, I’m very impressed by SolveSpace: it’s a lesson in minimalism.
A simple structure
I redesigned Hichem’s corner-piece using SolveSpace. It’s meant to join five triangles together at a corner. Here’s what it looks like:
There are hexagonal wells for the nuts. To house the electronics, I designed a plate and supports (yes, also bolted to the triangles). The supports will be glued on the plate. Here they are:
The notches in the plate are there to let the bolts protrude from the supports.
Finally, here’s a view of the whole structure:
The corner pieces have all been 3D printed as hollow pieces, which made them way faster to print, and they feel strong enough. We’ll have to laser-cut the plate once I finish its design (mostly figuring out where to put holes for velcro straps for the LiPo battery), print the supports (~20 minutes each, from my early experiments), and finally glue the supports and the plate together.
The insides look like this so far:
Way messier than the screenshots, huh ? The grey ribbons are for the SPI connections to the LEDs, and the other wires are for power. Soldering the wires to a proper power distribution board (i.e, a two-sided un-etched PCB) and shortening them will probably make this a bit more manageable.
Back from a long posting hiatus … The triangles are almost finished. Some of them are missing connectors, and others miss a second Micromatch connector for chaining. Unsurprisingly, when ordering the LEDs from China, we didn’t get APA102 LEDs but some clones: SK9822. It’s a bit different though, but this article sums it up nicely. I had to tweak my LED strip driver but it wasn’t a big deal.
Another surprise: everyone thought that we had 20 triangular PCBs, but no: we found another one. This is good news, especially given Murphy’s law.
Speaking of Murphy’s law, on Friday, we tested a triangle, whose power supply started to smoke … I don’t have any pictures but on Saturday we found out with Alexis that there was solder paste under the inductor of the buck converter, which short-circuited it and fried the IC. Fortunately, after changing the regulator and the inductor, everything works as expected, as far as power supplies are concerned.
However, as for the LEDs, it’s another story. I tested all triangles, and 9 of them don’t work properly: there are dead SK9822s on them, but it’s easy to find where the problem comes from with the testing code I wrote and an oscilloscope as an overkill logic probe. Replacing them should do the trick.
Here’s what the test setup looks like:
There’s a program I wrote on the STM32F7 Discovery board that sends a simple test animation to the triangle. Here’s what it looks like on a good panel:
On defective panels, the white flash at the beginning stops at the failure point.
As to the main board, it’s finished and we’re writing the firmware for it.
Over the holidays, I tried implementing a projection algorithm to display an image on the icosahedron. Roughly speaking, the idea is, for each LED of the icosahedron, to find out in which triangle in the un-rotated icosahedron it is. This step works fine. Then, on this triangle, we can put axes and get 2D coordinates, and finally find out which pixel (i.e, which colour) that is. It turns out that this step doesn’t work as well as it should. There were annoying glitches in the coordinates, for instance, and that was a nightmare to debug.
On Monday, we decided to ditch this idea and to go with Lucas’ method, which works fine, and what’s more, which is simple. Simplicity is underrated.
Tomorrow, we’ll build and test the main PCB
Last time, I routed the power supply. Since then, I placed and routed all the components and added the ground planes. We’re now waiting for the teachers to review the boards. Below is a screenshot of Xpedition PCB showing what I’ve got so far (ground planes are not displayed, but they’re there):
The green traces are VCC (3.3V). It’s not obvious from the colouring, but some parts of these VCC traces are on the back of the PCB. U3 (the tiny chip above D2) is a LDO regulator (LT1762) that drops the 14.8V VBAT voltage from the LiPo battery (J2) to 5V for the U5 3.3V-to-5V level shifter used for the SPIs (the connectors on the left). U1 is a LT1765 switching power supply for the 3.3V rail. U2 is the STM32H7 MCU. Finally, there’s an SD card (J1) and an ESP32-DevkitC for network connectivity (U4).
I started placing the 3V3 buck converter first. Here’s what it looks like on the schematic:
The LT1765 switches at a high frequency (1.25MHz), which constrains the routing. The datasheet explains that the most important thing is to make the path from pin 3 to pin 2 through D2 and C2 as short as possible. My layout looks like that so far:
Vias to the ground plane aren’t pictured, but the path I was talking about is really short, and I think it will do the trick. The layout and schematics have yet to be reviewed, though.
Today, I started drawing the main board’s schematics. It’s not finished yet: the decoupling capacitors have yet to be chosen and I’m not done with the STM32H7 (pins like VBAT, VREF, BOOT0, etc.). As a teaser, here’s the power supply:
It takes a 14.80V input (from a 4S LiPo) and steps it down to 3.3V. That’s not the right buck converter (it should be a LT1765-3.3), but the pinout is the same, so when it’s done I’ll only have to change U1. The SDHDN_n pin is left floating on purpose, according to the datasheet.
Here’s a sneak peek at the unfinished parts of the schematic:
I’m currently designing the main board. First, I had to create a routing table for the STM32H743VIT6 using one Alexis made as a base. We’re only able to have 5 SPIs, a SD card in 1-bit mode and an UART. Programming and debugging will be done over SWD.
The next step is the power supply, using an LT1765-3.3 buck converter. Using the datasheet, I started choosing ratings for its peripheral components, but it’s getting late so I’ll finish that tomorrow. Next step: drawing the schematic.
We settled for a layout with 78 LEDs per facet, with a slightly modified border clearance. It looks pretty great on the simulator:
Don’t pay attention to that triangle with white LEDs, it’s coplanar with the z=0 plane, as a reference. You’re seeing the icosahedron from above. The important thing is that the layout looks regular enough, without any weird stuff in the corners, where 5 triangles meet.
Next step: build a paper version of bouLED. Behold !
That thing is HUGE. It was a pain to build using only paper and scotch tape, but it’s really useful to get a better idea of how to design the inner structure. On the flip side, I messed the dimensions up when printing the triangles, they’ve got 21cm sides instead of 18.5cm. The triangles I showed in my last post had the right scale, though (but the LED-to-side margins are slightly different). Notwithstanding my clumsiness while building this, it gives a good idea of what the end result will look like.
Choosing a battery
With Lucas, we thought that by limiting the LED brightness, we’d be able to downscale the power supply a bit. The 3D printed prototype triangle (103 LEDs) was already unbearably bright when drawing 1A in white, so we’ll avoid drawing over 20A for all the triangles, at 5V. The main board will run on 3.3V, and 3A is way more than enough for it. That’s 110 watts.
A 4S LiPo battery has a 14.8V output voltage, and for a 110W output it’d spit 7.4A out. That’s a very conservative discharge current for LiPo batteries, a 4S 3000mAh 35C battery like this one can deliver more than 90 amps continuously and its peak current is probably even higher.
With 3Ah, this battery could supply bouLED power (at full brightness !) for 24 minutes. We could have picked one with a beefier capacity, at the expense of its weight. This one weighs 308g.
Voltage regulator choice
Alexis suggested using a small regulator per facet (and another one for the main board), saying that’s it’s way easier than finding a big regulator.
What we need is a buck converter: it reduces voltage but increases current. The part Alexis suggested is a LT1765 from Analog Devices: it’s rated for voltage inputs up to 25V and the output current limit is guaranteed by the datasheet to be above 3A. It has fixed-voltage versions that can output 5V or 3.3V without having to add an external voltage divider.
My previous calculations for LiPo sizing didn’t take into account the fact that a buck regulator transmits constant (without taking efficiency into account, of course) power but at a different voltage. Basically, I did them as if I had a linear regulator. Now, the battery is one third of the price of the one I mistakenly chose, same for the weight.
I changed the LED layout algorithm to allow us to set a number of LEDs for each row. To improve regularity, the algorithm only takes the bottom row’s number of LEDs, and the row above this has one less LED, and so on. There’s also a “margin” setting for the space between the outermost LEDs and the triangle’s edges.
Here are all the layouts I generated, printed on paper with a 1:1 scale, and a 5 cents coin for scale.
We’d appreciate your feedback on this: which variant is your favourite ? You can click on the images to display them in their full size.