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.



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.

Moving forward

Hey, it’s been a few days since my last post.

For the last days I helped Quentin and Charles making the pcb, at first I said that i didn’t want to work on it since I already did some pcb before and I know how painfull it can be. But I ended up working on it anyway. We were 3 behind a computer trying to improve the design and i liked our way of working together and seeing things that we could have missed alone. I took some time to finish my own pcb, there are some mistakes, I should have spent some time reviewing each function but i wanted to move forward so I spared me some time. In the end the design satisfies me.

We move on to software development. Since I do this for a year and a half now as an apprentice, I’ve got some experience to share on the organizational part. Quentin also had some experience so we decided to use some of the agile methods to improve our efficiency and learn some professional skills that can be useful later.

We settled on what methods to use, how we will use github tracking system to choose which tasks we will work on during each sprints. We will do continuous integration and use as much as possible non regression tests. All this to make the cleaner and best code as possible. I started to work on the product backlog and the repository architecture, with Quentin we also started to write down our soft architecture and some module specifications. So for now i’m much more confident about where the project is going and I think we can do a really good and fun job. There are cons however, for example we aren’t still sure if we will be able to use the bluetooth chip without changing each of it’s gpio manually. Today we found in the user manual that we can do everything we want using the command mode of the chip so it’s reassuring. In 3 days we will receive our pcb so we want to start as early as possible the software to be ready when the boards will be soldered.

About Sphero and Irda

Today we returned to normal course after the Athens week.

Already in the morning teachers asked us where we were, what we have done and gave us some advices on our organisation.

We updated our pssc according to our new and final objectives, better late than never. There are some points we need to cover before rushing into the project. First of all we have to finish as fast as possible the pcb for the course in order to work on ours. We were asked to deliver it for thursday, that gives us 3 days to do it. It’s scary but since our pcb won’t be much complicated we hope we can do it.

The components must be chosen fast, we already settled on the mpu : the STM32F405RG, we will use a 3 axis magnetometer, the same IRDA chips as on MBLED: TFBS6711. The same buzzer as on the dev board.  Some small rgb leds, an IR photodiode  etc.

Today I worked on some issues we hadn’t solved since a long time, here are the answers of those questions:

  • To what is plugged BOOT0?  A pull down to GND via a 1k resistor  R6. If you want to boot on system memory you just have to remove R6 and connect the pin to VCC.
  • Why do we measure a 2Ohms resistor between mstby (motor standby) and gnd?  There is a short circuit somewhere, we weren’t able to find it, it explains why we can’t control the motors anymore.
  • Where are the resistors between bluetooth uart and the mpu uart? Answer is R5 and R4. (see the picture).
  • Does IRDA goes through the transparent shell?  YES!  But not through sphero’s white plastic shell.
  • Can we measure distance by measuring the reflected beam on RX pin on the IRDA chip? NO, there is always the same signal as tx on the rx pin during emission.  It means irda isn’t really full duplex.

About Irda: We weren’t able to make a simple chibios program work on the MBLEDS, I decided to give a try at recompiling one of their original program, i just had to find the right branch on git, master was the deal.  And i tested the snake program with a transparent shell between 2 mbleds, it worked fine. I also made measurements on the RX and TX pins of ther irda, to see if we can measure the reflexion, we can’t.

I made a picture of sphero’s pcb in order to summarize the important connections we found on the board.

Simply testing emission and reception

Simply testing emission and reception

Sphero bottom board with light annotations

Sphero bottom board with light annotations

Sphero's pcb Top layer with annotations

Sphero’s pcb Top layer with annotations

Athens update

Hello everyone,

I posted several updates on our explorations of Sphero during the past week. It was difficult to understand Sphero because every time we thought we had the right pick, when we tried something: for example the reboot in system memory, it failed. We still achieved to make some decisions.

Yesterday we discussed about the final points of our architectures and of the features we want to add to Sphero. It’s in Selrak’s post.

Since we spent every evening during the week working on sphero, I didn’t have much time to work on the pcb design. I started the placement yesterday so it’s really not ready now. I plan to finish this as soon as possible in order to focus only on the project after.

To boot or not to boot


Tonight we made some tests!  We looked where are connected BOOT0 and boot1 (PB2) on sphero. In order to make sphero boot via the internal bootloader of the stm32 BOOT0 must be to 1 and BOOT1 must be to 0.  This makes the stm32 boot on system memory.

With the bipper we looked the connection of BOOT0 and it appears that it’s connected to VCC via a resistor of 380 ohms. It is confirm when we plug the board, we measure 3.3v. So that’s a good news.  After we checked PB2, it’s hard to tell where it is connected. But when we plug the board it’s to gnd.

Basically the good config is already there, but that’s strange, why sphero is on the internal bootloader by default? Maybe we missed something which externally triggers boot0.

Logically it means we already can talk to the bootloader.  I tried with the  to read the memory:  “sudo -r -p /dev/ttyUS0”   and put sphero in reset when release it.

It doesn’t work. The bootloader is unable to talk via the uart.  But when we use our remote in python via the uart we can talk to sphero. But it appears that we need to previously connect to the bluetooth with a smartphone. Maybe that’s why the uart is not free in reset. Even with the resistors we found between bluetooth RX ,TX and the STM32 rx,tx.

The next step we want to do is to sniff with two probes in RX what is happening between the stm32 and bluetooth chip at reset. There maybe some commands in the AT mode of the bluetooth at initialization time.

In summary: we weren’t able to set the sphero in bootloader mode for now but we have still more investigations to do before.

Rolling rosace or enslaved sphero?

Today we used the serial/usb cable to talk with the opened sphero in shell mode using a small python script. It works so we know if we want to flash sphero via seria we will be able to use the uart.

We settled on reusing the hardware of sphero, but adding a pcb above it.  The features we want to add is a spinning led bar like RoseAce, and some IR sensors, using maybe some IRDA to modulate the IR.

One architecture we could do is one board plugged on the uart of sphero,  and a motor in the center of this board.  On the axis of the motor just a bar or disc with some leds on it and powered by a “button battery”.

So we are sure to do an additional pcb but we don’t know if we will do our own firmware our just talk to sphere via the api mode.

Our next step is to succeed in flashing the sphero with our own code. But it’s scary because we have only one try, if we flash it with another code, it’s original firmware would be whiped and there will be no going back.

Our idea to check if we can flash is to code a simple application, for example with chibios, that just changes the led color (in order to check if it works). And then put the BOOT0 to 1 and BOOT1 to 0 to go in alternate bootloader, then use the stm32loader python code to flash over the serial.

If sphero boots and the led blinks it’s a green light!

We will try this as soon as we are confident enough to do that.

The difficulty of choosing a subject

Hi everybody!

Today was tiresome!  There is the pcb design we have to finish for tomorrow and we had to work on our project, it has taken us a huge amount of time and energy!

There are some important news and modification on the project.  We felt that the teachers wasn’t really enthusiast about the objectives and the visibility we can make around our project. Therefore we took some time to rethink them.

In the discussion we had we oriented the features on communication between 2 or more rose rolls and we brainstormed on a distance/orientation measuring feature between 2 devices.  The main thing we chose was Infra red emitter/receiver disposed all around the board. And we chose to drop out the android development since it’s not the focus of the course.  We proposed it to the teachers and then started a long discussion on the technology we can use for that purpose.  IRDA was mentionned, ultrasound was banned, we talked about bluetooth link power measurement, that’s a lead we can try.   After they threw some ideas: We can make the ball spin really fast in place and use a LED bar to create a miniature version of ROSACE. We tested the spinning speed of sphero and it’s obviously not sufficient.  We could make a board wich rotates above the main board.. Or else put a screen.   These are some interesting features which will add some flashing and bling to our project.

Then we discussed about what we can do on the existing board inside sphero.  Stay focused the following is important!

We might be able to reflash totally a sphero, if we are able to do this it means that our project can be to do an open source firmware!! That would be a first for this device and it would be pretty amazing!

Because sphero uses the same mpu (stm32F103cbt6) as we use in class, we started to search how it boots.  I’m going to tell you know what (mainly) the teachers and us discovered:

Sphero doesn’t have a JTAG connector so to flash it they use an uart of the STM32.  It is able to do firmware updates with the bluetooth so it means that the uart of the bluetooth is the one that can be used for boot with the alternate boot mode (selected by pins BOOT0 and BOOT1). We know we can use the user hack mode to jump to the bootloader and store a firmware via bluetooth, but it’s dangerous since we might brick the thing.

Our guess is that in factory and dev mode, they disconnect the bluetooth chip (Roving rn42-n), to do so we found that the supply pin of the bluetooth chip is controlled by a transistor. We don’t know which pin controls the transistor yet, to investigate. We are looking for a way to flash the board without burning it so we have to be really sure of how it works. There might be a resistor in the TX signal, we will look for it tomorrow.

If we achieve to disconnect the bluetooth chip we will be able to set the processor in boot mode and flash it with our own code.  If we don’t find how to disable it,  we will simply unsolder the chip and have our way.

In conclusion, there is a major decision to make based on how it’s possible to reflash the board or not.  If yes  we might not have to design some board for our project, our just a simple one with new sensors for sphero. But we will make our own firmware that’s a really interesting thing to do and to share!

Continue following us to see whether we will do it or not 😉


Hello, today I spent  a half of my day working on the course board design exercise.

I have already done some pcb before on softwares like altium designer or eagle, but I find expedition pcb far more easy to use! Even if it allows a more complicated use and configuration, since we use only basic features i’m not lost.

The part that I don’t like the most to do when designing a board is trying to link every last pin of the components you want on your board with a pin of the mcu. Luckily this work was made by the entire class so it is faster enough. I’m not sure yet if everything fits in but i started to enter some modules on the design. I’m not finished yet with the schematics but I think I’m able to finish in time.

We spent the rest of the day / evening discussing with Rose Rolls team but I will discuss that in another entry.