Catching up on posts

I haven’t posted in a while so I’ll try to catch up with this post.

My main occupation for the last three or four work sessions was to implement the program that takes in input a string, and then displays this string on the outer circle of Litspin.

My first thought was that I wanted to implement it for the simulator, but firstly it was not that interesting to have a simulation for the display of a simple string, and secondly, it would be nice if we could use Litspin to display debugging information.

For the first point, I nevertheless decided to implement it on LitControl and make it possible to display it on the simulator, because I though that it wouldn’t make sense to be able to display 3D models but not simple strings.… Read more

Integrating is not Qt

Today I wanted to integrate Nathan’s file picker to LitControl, should have been quick and easy, but it turned out that merging two Qt projects into one is not that simple. I first tried to merge them by manually adding Nathan’s files into LitControl, but I had some compilation errors that I couldn’t make sense of. I then tried to use qtcreator’s subproject feature which could allow me to keep both .pro files each in its own directory (qtcreator’s project files), but somehow it was worse. So I am now back on merging manually, and I hope that by tomorrow this issue will be resolved.

Blender adventures

The last few days I focused on trying different animations on our simulation, I also tried to animate a bouncing ball as suggested by Alexis. However as you will see my blender animation skills are very limited, and the ball has some difficulties respecting the laws of physics. Nevertheless I tried with different animations, and it allowed us to discover some flaws/limitations in our program:

With the cat, the voxelization was quite fast, however i tried voxelizing 500 frames of a moving dragon, and I couldn’t finish it because it was way too long. I then found a feature on blender that allows to automatically reduce the number of triangles without ruining the model, which is very convenient because with our display we can hardly see the difference between a high poly and a low poly model.… Read more

Voxelization: the end?

The last two days I continued debugging the voxelization along with Guillaume, now we finally have a clean and fully functioning version with the animation. Turns out most of the problems I had were due to how C++ handles floating values, especially when I need to round them to an int value, which is essential with voxelization. With rounding functions such as int() or floor(), the program behaved differently on my computer and on Guillaume’s so I found a way to avoid using those rounding functions, and now everything works as expected, on my computer as well as on Guillaume’s.

Now we are trying the voxelizer with various animations, but some of them have too much triangles and frames an the process is quite long.… Read more

The program has unexpectedly finished

Yesterday was not the most interesting day I’ve had. While Guillaume was busy implementing the animation, I spent most of the day doing some debugging and rewriting some parts of the voxelization code. Indeed we noticed that on the ppm files generated by the voxelization, some lines and columns when systematically black, even when the original 3D model was supposed to color every voxel. Moreover, on some models the app kept crashing with a segmentation fault. For the black lines, most of the problem lies in the way i round the values in order to decide which voxel should light up.… Read more

Synchronization update

Today with Nathan we spent a lot of time rethinking the work distribution between the synchronizer and the led band controller. I won’t go into details because Nathan already explained it in his last post, but basically the synchronizer will have more work than expected because it will have to generate all the signals needed by the led band controller to output the right bit at the right time. Indeed since every led band has the same display pattern (the leds are all multiplexed the same way on the PCBs), the calculations can be made only once for each led band.… Read more

Quick update on the synchronizer

Nothing much to say about today, I continued studying the architecture and the driver documentation. I had trouble at first figuring out how to synchronize the signals sent by the sync module and the data sent by the led band controller module, before realizing that it was the controller’s task to send the data in agreement with the signals received from the sync module. I then started coding the module today, but after we had a meeting with Alexis, so we will need to update the architecture before going any further. More news about it tomorrow.

Time to synchronize stuff

Today I started working on our synchronization module. This module is supposed to take in input the result of the speed measurement provided by the sensors and then infer the current angle position as well as others signals needed by both the led band controller and the led drivers: LAT, SCLK, GCLK and MULT. But before writing any code, I need to make a timing diagram as precise as possible. This is my first objective. So today I spent most of the day diving back into the driver documentation and the FPGA architecture described by Romain and Nathan in order to make a first draft.… Read more

Voxelization update

Last time I showed you how I managed to voxelize an obj file and display it on our simulator. However, I had a few issues with the cube, because it wouldn’t detect the vertical faces. This week after battling with geometry for longer than I’d like to admit, I finally managed to add horizontal rays that are orthogonal to each voxel located on the side of the cylindrical grid. As expected, we can now see the coloured vertical faces of the cube:

However, more unexpectedly, even the other models looked better on the simulator, for example the Charmander I used in my previous post:

Without horizontal rays
With horizontal rays

It is quite visible on thin forms, if you look at the tail for example it has much more volume and it more visible on the second version.… Read more

Let me hear your vox

For nearly two weeks now I’ve been working on a voxelizer, to convert a 3D model into an image that can be displayed by LitSpin. The goal of voxelization is simple: we need to display an image on a grid of leds, which means that the input image needs to be divided into voxels (3D pixels), each voxel representing a led.

Our grid looks like this:

The number of voxels corresponds to our desired resolution (20 circles, 128 angles and 32 leds from top to bottom).

The voxelization algorithm consists in tracing rays across the model to detect intersections with the triangles of the model.… Read more