LEDzep – getting angles and tap detection


These days I worked a lot on our mpu9150, a 9axes motion sensor embeded on our cards. We had to adapt the SDK provided by the constructor Invensence and adapt it to our STM (it was originally intended for TI processors). Then we used it to configure the mpu and the dmp processor. The mpu transmit to the dmp raw datas throught a fifo. The dmp will then put in the same fifo the filtered datas.

Here is what we get in this fifo when the system is balanced, when a tap is simulated with the ball or when we rotate along z.
test valeurs au reposLEDzep - tap capture

LEDzep - test valeurs angle

We note first of all that there is no drift.
Then I used the values ​​of the accelerometer to determine the duration and the threshold adapted for the tap detection. It now appears to be effective as shown in these videos. There is still a small porblem: each shocks, the dmp detects up to 3 taps. So that’s why the zeplin flashes when touching the ceiling.

After that, I projected the quaternions datas in order to recover euler angles and especialy the Heading angle that we’re going to use for the servo control.

We now get a precise angle measurement as shown in this graph.

LEDzep - récupération angles en degré

So now we are able to recover datas from all our sensors (altitude, angle, tap) and we can use all of our actuators. Thomas began a first height servo control code. I will now start the angular one. Both servo control threads will then be alternated with regular time intervals.

good evening!

LEDzep – Final rush

Hey !

Long time no see, but lot of stuffes done.

First the uart between the nrf and the stm32 is inflatable water park now fully functionnal. We had some trouble because the remote control through the app seemed to work 10 seconds and after that it was all random. But the bug is now fixed and we can go on.

We’re gonna have two android apps : one for hüpfburg mit rutsche the direct remote, and the other for the light ambience and choregraphy control.

So we have to implement the way to take control bounce house of a particular balloon. Here is a quick draft of what I think would be a good idea to do that.

Screenshot from 2014-04-24 13:10:29

I’m going to do that this morning.

See you

LEDzep – Viderose

Hi all,

Friday we eventually managed to fix most of our issues, which allowed us to have a working prototype with a very rudimentary control system, even though it was a first draft it was rather cool 😀

Saturday I spent all day (and night) soldering with Alexis and Daniel, and was rather happy to discover that I was able to solder 0402 components (even there was a lot of free space around the components), we now have our 10 PCB soldered !

Later I tried to improve the barometer measurements, as they were not very good …

I also helped Daniel adapt the Invensense library for the mpu9150 for ChibiOS and STM32.

From now I will spend all my time on improving the altitude measurement and flight control until I consider they are good enough 😉

LEDzep – mpu and shell


These days I worked especially on our motion tracking device. We use the nine-axis MPU-9150 that can measure gyro, accelerometer and compass datas. The range we have chosen has a characteristic, it embeds a digital motion processor. By accessing to its registers, we can retrieve measures that have already been filtered and analyzed. I decided to use the motion driver SDK provided by Invensence, the manufacturer.

The code now, recover a FIFO on which the measures filtered by the DMP processor are set to the string. A callback is also called each time the DMP detect a collision and the function send back the direction from which came the collision and the number of these impacts. It will be very usefull because we will be capable after a collision to round and drove off in the opposite direction. We should now work on the i2c communication functions that must be defined for the Invensence platform.

We will soon need a quick data return for altitude and direction servo-control. We purposely left an uart output on our PCB. So i used it in order to implement a small shell in order to have first the mpu data returns.

We also finished the other evening the assembly of PCBs. They have been tested today and connections are all good 🙂

LEDzep - PCBs













Finaly I also Worked on the architecture of the futur android App. I made a first mock-up in order to think about what it might look like and to help to encode faster once we will have tested all the android features.

here is the link.

If you want to see what happens directly on your smartphone, you can download the app “Fluid Player” and flash the following code:

LEDzep - flash code



LEDzep – Android app and nRF51822QFAAC0…

Hi everyone,

This last week, I worked on nRF and Android. First, I implemented all the missing services. I can write or read data from a characteristic using the UART. I implemented a simple protocol to communicate between the nRF and the STM:

A frame is composed of:

  • start delimiter: 0x7E, 1 byte
  • type of message: 1 byte
    0x10: battery level
    0x11: altitude level
    0x12: compass level
    0x13: collision status
    0x14: left motor thrust
    0x15: right motor thrust
    0x16: left servo level
    0x17: right servo level
  • data: 1 byte

We don’t need an escape byte as we have only one byte of data every time.

We also need a software flow control. The nRF chip we use (nRF51822QFAAC0) has a 1 byte Rx buffer. Each time the nRF receives a byte, it sends an ACK back to the STM.

I also improved the Android app. The priority was to be able to command the balloon as soon as possible using the 2 servos and the 2 motors. Then, using Android, we can control the balloon and do many tests.

Here’s a screenshot of the current state of the application:

 Screenshot LEDzep app 

The 2 vertical seek bars are used to control the motors and the horizontal seek bars are used to control the servos. The app also displays data coming from the balloon.

The “Send command” field is obsolete for now.

I am now working on flashing our nRF software to the LEDzep board. It’s not as easy as expected because we developed the software targeting the nRF51822QFAAG0.
Unfortunately, our supplier made a mistake and gave us a nRF51822QFAAC0. This is quite a problem because I had to switch the SDK from 5.2.0 to 4.4.2.

I’m able to flash our card but it doesn’t advertise BLE advertisements yet.

More to come soon!

LEDzep – Everything is working

Well not everything but at bounce house for sale least the motors and servos.

We would have at least expensive bounce house with slide fans to present to Parrot on presentation day …

This afternoon, we make the link with the nrf aufblasbare rutsche to validate the UART between the STM and the NRF. And if everything works perfectly, we’ll test it on a real balloon tonight.

LEDzep – Servos and Motors

Yesterday and this morning I worked on driving the servos and the motors.

It was a bit harder than expected since the two timers the servo used both had weird behavior with Chibios. The first one TIM8 had advanced functions not supported by Chibios (we were on an N channel, so I had to change a bit in the CCER register in order to switch the polarity of the channel), it wasn’t hard to fix but took me a while to find where the bug came from.
The second timer TIM9 had an issue on his PWM function, the frequency was twice what it was supposed to be, after a while trying to figure out why it behaved this way Sam told me to check the implementation made by ChibiOS/RT of the clock, after a while reading the datasheets (and checking the implementation which indeed respected the datasheet) I decided to look on the ChibiOS/RT support forum and discovered that it really came from ChibiOS/RT and was discovered the day before … Eventually I solved the problem by taking another timer as we still had a few free ones.
Once I solved this problem it let it rest for the night and finished it this morning, Thomas took a nice video you should see it soon.

I also worked on the H-Bridges, after losing two hours on a stupid board.h issue (I forgot to put pin linked to the enable of the H-Bridges as outputs …) they were running !
Later I fixed an issue which allowed us to control the speed of the motor (but only when they turned forward) when I looked at the signal with the oscilloscope I discovered that the PWM for the backward rotation wasn’t generated properly … I was sick with PWMs for that day and decided to call it a night.
This morning Thomas discovered that it was a simple sign issue in the code so we fixed it, and now both the motors and the servos are working !

See you soon 😉

LEDzep – Here comes the PCB

Yesterday, I finally had a PCB to work on !

After spending a few days acting like a kid before Christmas awaiting his presents (here LEDzep’s PCB), Santa (here Alexis) brag ma my present 😀

Isn’t it a nice board ?


I had a few troubles making it work at first, as I used the wrong linker script at the begining and forgot that it had a 16MHz clock instead of an 8MHz one.
Nevertheless after Alexis and Sam explained me which PLL values to change (and thus saving me quite a while of datasheet reading) I manage to make the board work !

I had time to have a LED blink and use the LED strip on the balloon and it was rather encouraging !

Later I worked on driving the servos and the motors, I realized that we most likely would have to patch my gift, as the servo connector didn’t have the proper wiring nor the good voltage (they are plugged on the LiPo battery which gives between 3.3 and 4.2V whereas the servo datasheet asks for at least 3.6V so we will have to see if they respond at a lower voltage :/). I was stuck a little bit on them so I didn’t manage to have them move properly (our previous code wasn’t working as expected), but I am confident that by tomorrow afternoon we will be able to drive both the servos and the motors !

Our only lasting foe will be the controll system, but I’m rather optimistic !

See you soon 😉

LEDzep – Architecture


I’m thinking about the architecture of our program. It must first define how the user will program the different choreographies through the android app. Here is a first glimpse into what this application could look like.
We would find three tabs:
1) The first one allows the user to choose an mp3. An algorithm will then recognize the tempo.
2) The second one allows the user to choose the order in which the various movements proposed will be executed.
3) The third one allows to choose light transition movement.

When the user have set everything, he clicks on the load button and the app will send successively to all the balloon connected the different triplets composed of the time before the next beat, the movement to perform and the light transition that matches it.
LEDzep - App architecture
At the reception, the NRF will handle the BLE layer and transmit through his uart connection the different triplets to the STM that will store it in his FIFO. Once the connection is completed. All balloons wait to capture a clap with their integrated microphone. Soon as they receive it, they initialize their timer and read the FIFO. After the clap, the app start playing music and all balloons are synchronize.


LEDzep – awaiting PCB

These days we tried to finalize everything that did not depend on PCB. As you can see in the video below, we have a structure for the chassis. Motors, servos and LEDs are placed. The next major step for our project, once we will receive and sold the PCB, will be the position control. It will probably be a very time-consuming process because of the inertia of the object.

Here is a short video showing our progress and giving an idea of what our project could look like.

I am currently working on a script that advertise in ble the value of the ground pressure. It is in order to measure a more accurate value on the embeded barometers and to reduce drift phenomena.

Thank you for watching this video, We will show you soon the moving balloons.