RoseRolls is following an other one

We finally managed to make a RoseRolls follow an other one that was controlled by a smart-phone !

Videos will be posted soon !


We managed today to make the compass work, and you can find here what the results are !

The curves are sinus and co-sinus as expected. We need now to analyze those data to be able to set directions.



About RoseRolls IrDA

We worked today on the implementation of the IrDA module for our RoseRolls.

Today, we managed to make a RoseRolls follow an MBled with IrDA detection !
We still need to work on that to find a better configuration, but it’s encouraging.

video of tests

Hello everyone!

Here are some videos of our tests for the irda, using an MBLED and checking the distance:

Leds, buzzer, irda and photos!

Hi everyone!

There has been a long time since my last post, it’s because i spent my time working on RoseRolls. We made some improvements, even if we have a lot of problems because of the failing electrical connections. We continue to test our hardware and making each module work one a a time.

As said in the title for now we have already LEDS, buzzer and IRDA working. I’m going to tell you where we had some problems and what we discovered about sphero. By the way we opened another Sphero.Sphero soldered pcb

With a metal SAW

With a metal SAW

RoseRolls and Sphero


We can now make every led on RoseRolls blink and adjust their brightness. It seems easy and simple but there weren’t enough timers implemented in Chibios/RT  for the STM32F4xx. I will let Selrak explain it further because he did it with Clementine.


We can play some music, RoseRolls is able to play several melodies on it’s buzzer, however we are disappointed that in the shell we can’t hear it well. We can also play some notes streamed via Bluetooth using our own protocol.


We plugged 5 IRDA transceivers on 4 uarts (we have to emulate one).  Using Chibios/RT serial driver we can talk to them. Note that you have to enable the IREN bit in CR3 register to use the IRDA SIR encoder/decoder of the uart. Furthermore you have to settle the USART_GTPR register, the PSC bits configures a prescaler  which configures the acceptable pulse witdh of incoming data. Since IRDA protocol says that when emitting the pulses should be as short as possible instead of having a logic 1 as low level it has a logic 1 as a short pulse. That’s why we have to define a maximum input pulse length.

To summarize:  put   CR3 : IREN bit = 1,   USART_GPTR : PSC[7:0] = 1  for IRDA SIR normal mode. And let Chibios/RT serial driver to the rest.


Let the communication start

Today we managed to communicate through IRDA with our RoseRolls!

We know that the range in which we can send data is at least 40cm (15,75 inches).

This is a good start, and I’m looking forward to go further!

Hard days’ nights

Cheers to my fellow engineers !

So yeah, since it’s been a while since my last post, you’re in for quite a bit if stuff that I have to share. But anyway, as soon as you saw my name at the top of this post, you knew it was going to be like that. So gird your loins, because about the only thing I haven’t done in the past week and a half or so is posting on . Don’t worry however, I’ll sort out the irrelevant stuff.

For starters, I’ll have you notice that spring may be – *may* be – finally there. Oh wait, the fact that the sun is shining in the outside world is irrelevant. Let’ skip that.

Last week was the BDE campaign. By luck, it was also an FH week, so I didn’t have class (since I’m in the theater club, and by the way, we rehearsed all week-end, which explains why I wasn’t around much). So last week I could work during the day and party during the night, for my birthday or any other reason (or pretext, rather) – quite a rhythm I held up. We finished our first development sprint a week ago. We did not achieve all the tasks we had set out to achieve at the beginning, but we knew that would be hard given their number. Among other things (thinking about booting and loading, thinking about project architecture), I managed to get the buzzer working, and performed tests on our lab board. Our buzzer module has a state machine that continuously reads notes from either somewhere in memory we tell it to play from, or from a buffer in which we can store music (thus allowing music to come from a Bluetooth stream). The volume can also be adjusted.

I discovered along the way the concept and usage of thread mailboxes. For those who care by the way, mailboxes can be really useful. It’s basically a queue of msg_t (which are uint32_t) on which any entity can post (if it has a pointer on the mailbox) and which the thread can checkout and fetch in. The advantage here is that each msg_t can mean a lot of work to be achieved by the thread before it  goes to fetch the next message. In that sense you’ve achieved a kind of mutual exclusion : you ensure all the work one message implies has been done before moving on to the next one. Example : a memory in which you move entire chunks, or which you reorganize through complex algorithms. The dedicated thread reads one message after another, and performs such complex movements in “message-atomic” blocks at the end of which the memory is in a coherent state, so that the next message (and associated algorithm) can be applied safely. Later, I happened to check out the “Mutual exclusion” page of the ChibiOS

Last, I worked on the LEDs. For the on/off blue ones (that don’t require a PWM§driven intensity setting) it wasn’t too hard, and I discovered the concept of virtual timers to implement different blinks with different periods on different LEDs.

Beyond that, I worked on the concept of PWM driver and how they are implemented in ChibiOS. I’m really starting to like this OS. But the thing is, it doesn’t have support for PWM on timers beyond 8 on STM32F405, and we need that for our RGB LEDs (so as to display any color we want by setting blue, red, and green intensity). So with Clémentine and on Giovanni’s advice, we took a look inside the ChibiOS machine, and figured out how timers are defined and referenced, and how PWM drivers are initialized and started. Then we took a long look at the reference manual and at all the timer config registers (there are MANY of them). And we discovered how beautiful it was.

The thing is that on STM32F405 there are 14 timers. Yes, 14 of them. Some (2->5) are of general purpose, some are advanced (1 and 8, can do lots of things), some are just good timers. But ChibiOS only has PWMDrivers for timers from 1 to 8 – because the other ones (beyond 9) share the same interrupt handlers, and that’s specific to STM32F405, and Giovanni’s philosophy about ChibiOS is to keep things general and portable. So he told me to create my own PWM drivers, and said he just might add support for general interrupt-less PWM driving. Nonetheless, we set out to implement our own drivers for timers 12, 13 and 14 (the ones we nee).

And remember, it’s beautiful ! So even though all the timers are different, in the sense that some have feature A but not B, and some have B but not A, they all have the same registers, mapped in the same order starting at the timer’s base address in memory, and within the registers, the bits are mapped out the same way ! Say now that timer N doesn’t have feature A, then the corresponding registers or bits (feature A config register for instance, or the feature A enable bit in the main config register) are just “reserved”. So it’s really easy to use existing code for another timer – you don’t call the functions you don’t want to use and don’t write in the corresponding bits and registers, and the remaining ones (feature B) work just the same, with corresponding registers and bits at exactly the same places ! All you have to do is change the timer base address, and only use offsets from there on. Whatever timer it is you’re using, at offset 0 is the config register 1, and its bit 0 is “timer enable”. And if in your initialization method there are writes or reads to registers or bits that timer N doesn’t have (because it doesn’t have feature A), you’re fine, you’re just talking to “reserved” bits and registers, and that doesn’t matter. That’s how beautiful it is.

Now we still need to test all this, and there are still some weird OpenOCD behaviors that we don’t understand … We’ve fixed a few things already but that doesn’t appear to be enough. The thing is, and that’s a very general remark here, is that we’re learning and applying at the same time. It’s great, but sometimes it gets you stuck when there’s something you don’t know yet. We’re basically putting down the rails AND moving the locomotive forward, like they used to in the Far West in America – and sometimes those two processes don’t work well together, and one hinders the other. Especially when you’re trying to go too fast with the locomotive (the work application) and the rails (the learning and understanding part) are not properly setup yet. You just risk a wreck. It’s an intense experience, and I’ve learned this much stuff in so little time. I’m like a sponge – I try to absorb it all (risking to be full and letting some slip by). Any way

The last thing I wanted to share that was implicit in all the previous stuff is that our PCBs have arrived and have been valiantly and efficiently soldered by Loïk, Quentin, and of course Mr. Polti ! Many thanks to them ! It’s great to see the fruit of our design work come to reality – and function. I would’ve liked to be a part of that soldering step of the process, but we have to try to keep the work parallelized. Speaking of which, moving on to LEDs and timers tests !

What’s up on RoseRolls

I spent the whole weekend working on our new PCB. We managed to make leds blink, and to produce some sounds.

Pictures and movies are coming!
We managed too to connect our computer to the Sphero trough our PCB.

We still have a lot to do but it’s encouraging.


What is RoseRolls?

RoseRolls is a spherical robot made by hacking a Sphero (from Orbotix). It’s aim is to create a both hardware and software add on for Sphero.

How it works?

Sphero is sold to be unbreakable. They provide a sdk to allow everyone to create applications to remote control it. But we want to change it’s hardware. We basically open the ball, and plug an additional pcb on top of his. We insert our mpu between sphero’s bluetooth chip and it’s stm32. This way we can intercept and forward any messages sent to him.  We use his api to send commands in order to control his base: make it roll and blink basically. This way we don’t have to redo ourselves the very complex navigation, balance and control system it uses.

What we add

Based on our observation that sphero isn’t really autonomous we will make roserolls more autonomous. Sphero can already know it’s position, detect collisions, make some visual feedback with it’s leds. But we will add more:

  • Transparent shell
  • Infrared communication/angle detection
  • buzzer
  • more leds: 3 RGB and 5 blue.
  • 3 axis magnetometer: sphero already has one but its too mixed up by the motors magnetic field. We add it just for test purposes

Our Architecture

Here is everything we will put on our board:

RoseRolls pcb TopRoseRolls Bottom pcb


Irda is used to know the position of 2 spheros one relative to another: if A is emmitting and B is receiving on it’s left irda transceiver, we know that A is at the left of B. Furthermore, in the frond we put 2 IRDAs crossed in order to create a “mustache” like a mouse.

IR photodiode

Because IRDA transceivers don’t give the power received, we can’t use them to measure the reflected beam.
That’s why we added a photodiode coupled with some RC low pass filter in order to measure the distance of nearby objects. We don’t know if it will really work since the environment will be flooded with infrared.

Buzzer and leds

In order to enhance the emotion feedback we added some leds and a buzzer and we will give RoseRolls some kind of personality.

User stories

  • Use a RoseRolls as a Sphero: it must be compatible with already existing smarpthone applications
  • RoseRolls can take control remotely of a sphero and make it dance
  • Avoid obstacles while being remote controled
  • Play some music: because 8 bit music makes us nostalgic
  • Make a choreography using several RoseRolls
  • Automatically arrange some RoseRolls in a certain pattern: line, grid etc.
  • Have a RoseRolls following another one and form a snake
  • Solve a carboard maze by exploring it and find the shortest path from center to exit
  • Use mbleds as a invisible beacon or barrier.

[RoseRolls] First Sprint

Today was the end of our first (short) sprint. We took advantage of this moment to celebrate Selrak’s birthday.
Out of 14 opened task (we don’t count cookies), we managed to achieve 5 tasks, and 4 other are in progress.

Our conclusion for the sprint are the following ones:

  • The work done during the sprint is satisfying.
  • We enjoyed the ability to cut the project in small units.
  • We liked to have short deadlines, imposed by the sprint, that made us more willing to work.
  • We were happy to finally be able to code after a long time of planning.
  • We feel like sometime we should go deeper in the things we work on.
  • We are slowed by not having our board to test features.
  • We don’t master yet the git branch system.

We assume that time and practice will help us to solve our problems.
We agreed that the Scrum method is effective and we want to keep it for the moment.

We also worked to prepare the next sprint. We want to :

  • Work on the remaining tasks
  • Work on the boot-loader
  • Include the compass in the architecture

We are looking forward to receive our board!
May Rose roll(s).