So long migB

The fall of migB and the rise of StabiloRose is no news anymore. We got our 5-people project (something we weren’t sure of), and if we hadn’t a PCB to design in 4 days, now would be a good time to celebrate.

Quit on migB wasn’t easy. Or, I must say, watch it die as many of our ideas appeared to be too expensive, too complicated or too useless. Some know that I really was into that GPS thing. However, I understand that such circumstances will be more than common in our future work life, and we got to learn to get past it.

Besides, StabiloRose is not a repelling project at all. I really enjoy the fact that once it is assembled and flashed, we can turn it into almost everything we want. And I am sure we will find some great games during its conception. So, let’s get down to business !

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] RGB LED Strips returns

We finally got our LEDs allocation over migB. We are going to use the same principle as explained in a previous post (article and video). We will also put one RGB LED on each pole to reduce the obscurity. The main issue with this allocation is the conversion of coordinates. With aligned LEDs the conversion is quite easy. Spherical coordinates can be easily projected into a Cartesian system which will govern our strips.

We also thought about a spiral wrapped around migB or parallel circles mapping a sphere. However it is very difficult to manage coordinates.We thought about a mapping matrix to deal with led position and solid angles, but it requires a calibration and a high similitude in the way the strips are mounted in the sphere. More difficult, imagine you would like to color the LED which point out a certain direction. It becomes really hard. We chose simplicity over homogeneity. This spacial allocation will also strongly help the understanding of the displayed symbols by the player.

The numbers of LEDs will be between 50 and 100 for each migB according to the final size, in order to keep the price and consumption reasonable.

[migB] Wireless charging

In order to keep our migB smooth and beautiful (without ugly connectors), we plan to implement wireless charging. We are going to use the Qi standard, the most known nowadays. Basically we will connect a power regulator to a receptive coil (input) and to a lithium battery charger (output). The regulator and the charger may be in a single chip. Thus, the energy can transit properly from the coil to the battery.

Moreover, this is not really expensive. I think we can do it for less than 20€. I’m careful, the limit is high.

You can easily implement wireless charging on your smartphone. Many tutorials can by found on the web. You can also buy ready-to-use coils providing a regulated 5V voltage over a micro-USB port. Pretty easy.

[balls] gps gps gps

Hi everyone,

after an afternoon spent on figuring out the PSSCs, we carry on the search of the right components.

Mine is the GPS chip, and I kind of hit a wall. At first, I believed it would be easy to find one. But the cheap chinese modules have a way too long delivery time. So I went on to find some from Europe, but none seemed to fit our little budget (<10€ per chip). Does anyone have any insight concerning these ?

Oh, and we found another game mode for our balls: contamination. We do not know the specifics yet, but here it is: all balls pulse white, then one starts to pulse green, and has to corrupt the others (by approaching them?). I think that’s something worth doing !

[migB] First experiment

Yesterday, we conducted our first experiment. The goals was to see if standard RGB leds were powerful enough to be seen through half transparent plastic. We used a 8*8 RGB matrix controlled by a DM163. We draw a few symbols, and placed a piece of plastic above. Even in a luminous environment (Yes it was sunny in Paris !), we can perfectly see the symbols displayed. When we separate the piece of plastic, the images started blurring until the symbol is no longer recognizable.

The best position is found when the image is softly blurred but still meaningful for the user, which represent a few millimeters between the two parts. That’s what we will try to do for migB.

Comparaison of leds brightness through plastic

Comparaison of leds brightness through semi transparent plastic

Motion…

Hello,

today we begin to define some PSSC for our balls project migB, and begin to think about components we need. According to our teachers, it is very hard to analyse a motion system with an IMU, that’s why i did research about it. It seems that orientation sensing is very easy, while getting velocity and position is much harder. Indeed getting velocity and position requires at least one mathematical integration. So if you get an error on acceleration, even little, and you always get a little error at best, this integration which increases the error. Therefore it is impossible to be very accurate over time. But how much do you want to be accurate ? This is very difficult to foresee which algorithm you will need to get what you want with your IMU, as soon as your project is such specific. Until now the only good one i found is the Kalman Filter, but i’m afraid that our errors could be negligible and thus Kalman Filter would become a big algorithm for nothing.

Also i installed Archlinux on the last computer available to us.

[migB] RGB LED strips

Today, my partner and I worked on leds for migB. We had to find a way to connect properly about a hundred of leds. The precise number is not defined yet. As we say, sleep on it. I hope we’ll have clearer ideas about that tomorrow. Two challenges here : get the leds controlled by the micro-controller and find an intelligent way to allocate them on the sphere.

The first one was quite easy (Thank you Alexis ! ). We are very likely going to use RGB led strips. These devices are really amazing. You may cut them, extend them by soldering and you control them with at most 2 wires. It facilitates our implementation. There will be less wires inside the balls, less solder and less pins used on the micro-controller. No need to use a driver either. So, is everything perfect now ? Not perfect, but it could have been worse. Actually, we can’t use multiplexing with these strips. Except with the DotStar series from Adafruit, but we don’t have precise values yet. RGB led strips act like shift registers. You push the configuration of the farthest led, then the configuration of the previous one, of the previous one and so on. The longer your strip is, the lower the refresh rate is. This model permits to keep the configuration even if the bus is disconnected. Unfortunately, as there is no multiplexing, all leds are powered on all the time (with a PWM modulation, but you get the idea). Therefore the consumption can be quite high. 7A @ 5V with the 144 leds NeoPixel strip from Adafruit ! This consumption is obtained when all leds are white and the brightness is maximal. As we will probably never meet this configuration, the battery is going to last more than 1 hour. With less leds used simultaneously and a reduced brightness, we will limit the consumption.

The allocation of the leds on the sphere is not easy. We would like to have and homogeneous distribution and aligned leds. That’s impossible. We found a led ball made of PCBs (and a video). Here, the alignment is privileged. It is good to display images or symbols, but the poles are in darkness. Not funny. It is difficult to find a projection which keeps the aligment. We have to make more tests.

To be continued…

LEDS EVERYWHERE

migB Can you feel it ?

The question is rather if it is able to feel you. One of the main ideas to give more interaction to migB is to make it tactile. I agree it seems a bit ambitious. At first we thought about adding a few buttons around the surface but it would remove all the fun. Hence, the idea of tactile came naturally. It allows many gameplay possibilities. Tap the ball like if there were a button. Place your fingers according to a pattern to solve an enigma. Hide a part with the palm of your hand…

The precision is not the biggest issue. Many physical quantities may be used to detect the contact of a hand with migB : heat, pressure, light…

So many possibilities to explore, sensors to find and connect efficiently to our PCB. Let’s go.

 

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.