[SpiROSE] Rust, Device Trees and Mechanics

Hello! This have been a long time since I’ve posted here. Lots happened!

First the mechanics

The motor we chose was doing lots of noise, so I had to investigate this and try to get a solution to avoid having to buy another motor. I discovered the noise was coming from a broken ball bearing.

The faulty ball bearing was hiding in the bottom of the motor.


After ordering a new ball bearing, the motor was running perfectly… Up to the moment I realized the motor was not the only one to do a big big noise… The planetary gearbox is using 3 needle bearings that does a lot of noise too…

I recycled an old Brushless Motor, a 4 pole 2100kv 3-4S LiPo sensored BLDC motor. This motor is not supposed to fit the low speed requirements (~20-30Hz), so I had to test with the real world load. We engineered PCB prototypes without the components to simulate the load, and mounted them over the newly installed motor.

New sensored motor speed test without load

Load test, with a big protection. We care about our lives 🙂

The two black plates over the vice are the prototype PCBs (pre-sensitized FR4 plate we machined with a CNC to fit the real size). The system is sensored, so we just placed a logic analyzer at the hall effect outputs (and divided by 4 the outputs, as it’s a 4 poles motor). The result is that we can go from ~5Hz to more than 30Hz, so the motor fits perfectly with the load!

Good news: the motor is now fixed in the structure, mechanical engineering is about to end!


Discovering Rust

This have been a long time since I wanted to learn Rust programming language, but :

  • I didn’t have time to learn it
  • I didn’t have a good and simple project to start with

Thus, when I saw we had to make a simple Command Line Utility for our SPI communication with the FPGA, we decided to make it in Rust. The first day was hard. Very hard. I discovered how we use rustup and cargo correctly, how we setup Rust to always develop with the nightly version, and how to cross compile for armv7.

SpiROSE Command Line tool

After hours of questioning myself about how it works, reading the docs, asking questions to people who Rust and error reading, I finally got a working SPI CLI for SpiROSE. Ok, that’s cool, but how do I get the SPI device now?

SPI, Yocto, dtsi

As the current distribution is not really made for embedded (ubuntu), we wanted to try Yocto, a build system made for packaging a GNU/Linux inside embedded systems. Yocto is widely used for that, but has a complex curve of learning. As the time was getting short, we rolled back to ubuntu.

So, how to get SPI device in /dev/spidevX.X? The solution is:

  • Install Spidev module (we recompiled the kernel to integrate it inside)
  • Update the Device Tree Blob given to U-Boot to give the address of the SPI hardware to Spidev and enumerate it inside /dev

As nobody knew about Linux Device Trees in the group, I hardly tried to put the new device in the dtsi, to get the new Device Tree Blob to give to U-Boot.

I finally achieved this tonight. Tomorrow will be reserved for testing the SPI output (already tested with a logic analyzer) by connecting it to our FPGA development board.


Now this week will be full of tests, to get the PCBs ready to use as short as possible!

[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!