[StabiloRose] gotta go fast !

Today, we did some pretty good optimization on the critical path of the application : applying rotations and computing distances. We went from ~24ms per frame to ~1.5ms per frame, using precomputed tables to compute arccos and the famous fast inverse square root from quake III.

Since our IMU only gives position at a 100Hz rate, we can’t really improve much on the stability now, except with some kind of inertia-compensating algorithm using the gyrometer, which we probably can’t do in the alloted time, but it already looks pretty good now ! (sorry, I don’t have a video)


[StabiloRose] For the code is dark, and full of bugs

I’ve probably seen every one of them today (hyperbole intended) : {integer, buffer, stack} overflow, null pointer dereference, divide-by-zero, encoding issues… Even what seems to be a hardware problem : when our JTAG probe is unplugged, the USB connection hangs, even after a hardware reset.

Tomorrow (well, today) is the first-last-day. It’ll be over soon !

[StabiloRose] return ESUCCESS; !

This was an eventful journey !

After debugging on a non-functional strip (the soldering had ruptured, so we couldn’t display anything), and displaying well-corrected …black images, we now have a thing !

[StabiloRose] Measures and simulation

Since last time, I spent some time modifying the simulator we used to view the location with the IMU, so that it can display our LEDs at their final position. You have probably seen the pictures.

I also helped with the measurements on the sphere, to locate every LED, and added quaternion support to the IMU code (we used euler angles before).

[StabiloRose] (Assembly and) Regression Tests

I mean, calling what we do regression testing would be an insult to anyone who has ever written regression tests, but I’m still glad we caught that one: When we were testing the IMU in the same run as the LEDs, the second one would fail. When we only tested each one individually, they worked fine. In its default configuration, ChibiOS uses the same DMA stream for an I2C controller (the one with our IMU) and an SPI driver (one of our LED ribbons). In individual operation of each of these systems, this causes no problem at all. When you try to use both, it obviously fails.

I feel like we could very easily have missed this one, since those components don’t interact with each other yet, and they had been tested individually already.

Also, we started assembling the ball, but you might have seen that from the 3 previous posts !

Light it up !



Today, I managed to light some LEDs. In the end, it was much easier than the time spent debugging it might indicate. I began to work on the API to use it in the other parts of the project.

We still need extensive tests seeing how this is a critical part of the project, but here is a colorful picture for the time being (I didn’t manage to crash the PSU by lighting too many LEDs, but I’ll try harder tomorrow !):




Getting Sidetracked by Interesting Protocols

Today, I lost a lot of time.

Actually, I didn’t lose any time, I just didn’t use it for what I had intended in the first place. I hoped to finish the assignment within the deadline, that is today; instead I learned a little about USB and standard libs.

I started by trying to use the serial-over-usb module of ChibiOS, but faced with the complexity of the USB protocol, I ended up adapting the demo code rather than reconstructing it. To my surprise, it didn’t work ! That is, even when only compiling the demo code, it would compile fine, but never actually expose a recognizable device to my computer . Instead, I would be getting confusing “device descriptor read error” messages in my dmesg, and packet inspection via wireshark/usbmon indicated that the packets were malformed. After some fiddling about and dirty “switch the usb off and on again until it works” hacks, I could see the device descriptor, but not its configuration, so still far from a serial-over-usb communication.

After a few hours of hair pulling, I switched workstations, and it worked on the first try, with the exact same code, only a different compiler ! I guess I’ll be sticking with the official ARM toolchain from now on, to avoid any unpleasant surprises like this.

In the end I still learned some basics about the USB protocol, and I also tried to make ChibiOS compile with clang. I have no more compilation errors, but it’s still not linking unfortunately. I guess this little side-project will have to wait, though, because I still didn’t finish the assignment in the end…

Yet Another PCB Entry

Just like everyone else, we have been working on finishing our schematic for the PCB. After a few corrections by Alexis, we were ready to start placing the components, and then routing them.
Obviously, we had to do it several times, and I still feel that I have no idea what I’m doing most of the time.

Anyway in the end we managed to get a first routing done. Now we’re just waiting to be told it’s terrible (it probably will be. It’s our first one after all).

It wasn’t easy working on that this week-end. With ATHENS we were only three people available, and some hiccups from the mailing list prevented critical email from being delivered. To top it all off, it seems that Alexis mistakenly destroyed hours of his work on HeRos’ PCB (Good news, he managed to save it). Hopefully all those delays won’t  affect the rest of the project too much.

I haven’t gone seriously into the practical work with the STM32 yet, but I intend to do that for the next few days. I must admit, I’m a bit fed up with electronics after two weeks, I’m eager to go back to programming for a while.


Introducing StabiloRose

This morning we had our first presentation. It went… poorly, at best. We were not quite ready, and we were not quite ready about all the technologies we wanted to use.

After the presentation, Sam & Alexis thought about it, and came back to us with a proposition : scrap the project, and salvage the idea to make a spherical display, that keeps up with gravity.

Let me present to you StabiloROSE (we have a real name this time !)

StabiloRose is a ball. It can display things all over its surface, keeping up with its own orientation. You can use it in your pool to read your email (yes, it is waterproof !), as a discoball in a party, or to communicate with other balls over the internet.

StabiloRose is a high-quality,high-resolution led display over a sphere. from this point, you can use it to display basically anything over its surface, while keeping its orientation : make it roll, or float in the water, your image will always be horizontal (or vertical, or tilted, if that’s what you’re into).

It’s not only a game anymore, but it can be used to easily implement one. It is really a multipurpose device, on which you should be able to display anything.

Some characteristics :

  • It’s a ~16cm diameter ball
  • It uses leds for its display
  • It should be waterproof

MIGB : Many Integrated Games in a Ball

Pronounciation : Migby.

Yesterday we finally got to choose our project; now it’s official (and almost final). There’s only one caveat : we have to show that we have work for five people in our presentation on Friday, otherwise, the group will be split up and we’ll have to find another project to pursue.

We started defining our features more precisely after we chose the projects yesterday, and we also have to think of the design we want to adopt with it. One of the main points we want to focus on is that, even in a “adventure” game mode where players take their ball for a stroll, our ball should be autonomous and not have to be communicating with a phone.

In its main mode, though, it is a collection of balls that act like bombs and give you challenges to defuse them. The challenges imply manipulating the bombs in certain ways : rotate them, hold them with a set number of fingers (maybe more than 10 !), launch them against each other or over a set distance. They also communicate together, so that if you have 5 balls in a room for example, you may have to run around to reach the next one before it explodes. We still have to write the descriptions more precisely and chose the ideas we want to keep for the official project.

Today espectially, we also had a course on real time OSs, and started practical work to go with it. Yesterday was also the deadline for the tutorials, so we finished that too.