Categories

[SpiROSE] Mechanical construction, various tests and FPGA design

This week was full of various little tests and tryouts: Power input, Motors, LEDs,  LED Drivers, etc. It was also a week used for designing the FPGA internal architecture and final adjustments for mechanical construction.

 

Mechanical construction

The mechanical design have been updated due to the lack of some materials in our distributor. The design have been checked and validated back with the mechanics, and the materials have been ordered. The mechanics will start the construction on next week. The motor and his controller have been ordered too.

The updated mechanical design is available here.

FPGA Design

The FPGA architecture have been finished, including clock domains, I/O count, main modules definition, RAM layout, data input specifications, synchronization constraints and drivers control logic. The chosen FPGA (Cyclone III with 40KLE) have been validated to work with this architecture and next week will be used for starting developing on it, to check the timing requirements. The rotative base station schematics can now start.

A note about RAM: last week a basic estimation was done to see if an FPGA could internally store a whole 3D image, but the calculus was erroneous, which leaded us to think that the Cyclone III FPGA was capable of it. The reality is that it can store up to 18 ‘slices’ (we call these micro-blocks), so synchronization is needed.

 

Various experiments

The LED drivers have been soldered on breakout board, as for the LEDs, and some motors we had have been tested. The goal was to validate our choice of components. Due to mechanical construction starting soon, we ordered the final motor and controller just after the tests in order to have it when the construction starts.

 

Now the schematics of the rotative base station are ready to start, and the FPGA code have to be written.

See you next week for more details!

Mechanics: (almost?) final chapter

The final design of the mechanics of SpiROSE have finally been chosen! A week full of design decisions, finding a design, testing the mechanical
design, simulating, talking with the mechanics to see if it’s doable, etc.

There have been lots of designs, the most importants are the following.

Blade-based designs

The design pattern is based on a stack of RoseACE blades. Every blade contains 32, 64 or 128 LEDs, and the stack is made of 32 to 42 blades. This
leads to a design looking like the following.

Blade-based design pattern without top arm.

The red squares are the RGB LEDs. A big central axis is used for turning the LEDs and transmitting the electrical ground. A special PCB at the bottom
of the axis is used for the Single Board Computer module, an FPGA and a brush for transmitting the Vcc from the fixed base. Wires connect the blades
to the main rotating PCB.

This design is similar to the design made by Volumen Display. It have the advantage to be modular: you can add or remove blades without changing the
mechanical design of you system, and another advantage of being more aerodynamic (it acts more or less as a big 30cm diameter fan :).)

The issues with this design are mostly mechanical issues. In fact, it is extremely hard to make a stable design this way because of the approx.
1300rpm speed of the blades. The mechanics said it would wobble, and the solution making the wobble to disappear (adding another bearing on top of the
axis) introduces other even harder problems (how to fix the PCBs). The other issue is the occlusion. The central axis makes a big occlusion and the
helicoidal shape of the blades overshadow the lower LEDs, giving the feeling of a big blurred central axis.

Another blade-based alternative design was to stack custom plexiglass(r) laser cut discs, containing the PCB. It looks like the following. The Disks
could be screwed to each other up to the base circular PCB, making the axis. The issue with that design is that the plexiglass would obstruct so much
the light coming from the LEDs that it makes the feeling of an even bigger central axis, instead of solving it…

Plexiglass(r) based axis.

Due to the issues related to this design pattern, it was finally removed from our design space.

Blade-based pattern with top supporting arm.

 

Plate-based designs

This design pattern is a HARP-like pattern. A big central plate gives a matrix of LEDs. This plate is turning on itself and makes the same shape as
the blade-based design makes. This pattern needs a supporting arm on top, leading to the following design.

The difference with HARP would be the number of LEDs, and the fact that our goal is to remove the occlusion issues they got. The occlusion they got
was due to multiple effects:
– The fact that LEDs are on one face of the PCBs makes the system not able to render anything when the LEDs are not visible to the user’s eyes. The
solution we got was to use two PCBs with LEDs, back to back. It makes possible to always have LEDs facing the user’s eyes.
– The fact that the LEDs have an emission cone (approx. 120°), giving this feeling that there is kind of a central occlusion because the LEDs cannot
illuminate when the user’s eyes are not in the emission cone. To solve this issue, light guides/diffusers will be experimented on LEDs next week to
see what we can do (this subject will be discussed in another post :).)

 

The winner

The winner of these designs is the Plate-based design, having less mechanical issues. The mechanical design approved by the mechanics is the following. It will be changed a little bit due to motor changes, Budget adjustments, etc. but it will be looking like this one.

Next week is not anymore on the mechanical design, but on the embedded systems and budget choices!

See you next week for more fun!

SpiROSE: how about the mechanics?

This week was full of requirement definitions. How many leds do we put, what bandwidth can we expect between the computer and the display, what technology can we use for [insert stuff here]… Lots of them have been defined, and more than 70 PSSC (Project Specific Success Criteria) have been written. During this time, mechanical drawings have been done to try different mechanical layouts.

The system is based on a main layout : a big squared block makes the fixed part of the system. A big plexiglass© cylinder with a top roof is put
over the block. Inside the fixed cylinder is the rotative part of the display. There have been multiple rotative versions. The idea is to make
something that can infer no occlusion while it’s turning. The induced problems are:
– The PCBs must be fixed without inducing occlusion (when turning)
– The layout of the system where the PCBs are going to be fixed shall not induce occlusion when turning.
– This system must resist without wobbling and have an intertia momentum small enough to respect our security criteria.

 

Mechanical preview

Example of full design with triangular rotary mechanism

 

We ended with about 5 designs for the moving part that we’re going to review with the mechanic.
More to be done on next week, as the mechanical drawings should be done at the end of next week!