Silvestre - Cosmobot 2012 Champion!

Silvestre Champion

Silvestre became champion of the Cosmobot 2012, one of the main robotics contests in Spain, after a really tough competition.

During the qualifying session in the morning, Silvestre made the fastest time with an average speed of 2.45 meters per second. Later in the evening, 16 robots went into the knockout phase and Silvestre had to make the most out of itself to push into an speed of 3 meters per second during the final round.

Knockout phase

The strongest point of Silvestre was, undoubtedly , his ability to learn the track and accelerate/brake at the right moments. Unlike past years, Silvestre doesn’t need any parameter to be entered manually but he will dynamically extract the key parameters of the track thanks to the encoders and inertial sensors. After the track’s been successfuly learnt, he will store it into memory for later runs in order to save the learning process every time. However if the data reported from the sensors is different from the expected track, he will learn again or modify it accordingly allowing him to self-adapt to changing conditions.

Cosmobot 2012 Track

The track was really good for our algorithm even though the zig-zag zone was tricky but also a good sucession of events that provided a more accurate positioning :)  The rules of the contest state that if a robot touches the internal lane, it would get disqualified but nothing prevents a smart robot from going through the zig-zag area as if it was a straight.

Silvestre was able to recognize the zig-zag area and, depending on the selected profile, he would “patch” the stored track to navigate inertially without reading the line, strictly during the zig-zag turns. This involves a risk because the top speed was about 6m/s and the navigation had to be as accurate as possible but it was robust enough so I used it on the final round :)



I don’t know what happened during the first round but Silvestre missed the line (Murphy’s law pushed him?) and started to learn the track again but, before this happened, the rival caught him up. The next two rounds, everything worked great and Silvestre won the championship!

After the contest, people wondered if Silvestre could learn the track clockwise and here’s the video:

Another video of Silvestre from another angle:

Slow motion video of the zigzag turns:

And below is the proof that what the videos show is not easy at all and took many hours analyzing data and trying:

Silvestre Wheels

New vs. used wheels after some training days

Unfortunatelly, my friend Alberto and I, don’t have as much time as we’d like to spend on the robots but we’re still enjoying competing and getting home at 2AM after a 20-hour of hard work the day before the competition :)  It’s great to see how racing robots have improved during the past two years and how innovative one must be in order to keep up pace.

UPDATE: video of the two semifinals and the final. Awesome!


Silvestre 2012 improvements

Unfortunately, Silvestre is not getting too much attention this year due to the lack of time but there was still some work to do regarding the acceleration:

The acceleration graph was quite good but still not as good as it could be. One of the main problems was the DC-DC converter which was unable to provide enough current at stall so we designed a new one and these are the results:

Silvestre Acceleration Improvements

  X axis represent time in 4.8 ms units

Compared to the results obtained last year, Silvestre is able to run 1 meter longer in the same time and its top speed is also higher. The price to be paid for this extra power is a higher current consumption which has to be taken into account when choosing the right battery for the competition.

The new DC-DC converter board has to be carefully analyzed and I hope to write a new post about it soon.


Silvestre getting ready for 2012

After some months resting, Silvestre’s got back to work this past weekend and the first thing we’ve done is to enhance the communication protocol in order to get even more data in real time on the PC. This data is essential to study software, hardware and mechanical aspects now that we’ve got a quite stable platform, and we need to focus on subtle things.

We plan to make some improvements over the way Silvestre speeds up and brakes so we definitely need to know how it behaves in both situations:



Blue line shows the maximum speed of the wheels (no friction) whereas red line shows Silvestre speed when motors are set to 100% from a stopped position. The track surface is pretty much the same as the one used in most of line followers contests in Spain and wheels were carefully cleaned beforehand. The result after mixing up the signals from the accelerometer and encoders (graph) showed that, during the acceleration phase, wheels didn’t skid.

As you can see, the robot can reach up to 5.6m/s in 0.9 seconds after having traveled a distance of about 4 meters and, in a typical straight in contests of around 2 meters, Silvestre would have to face a turn at about 5 meters per second yet making it harder to get back to a safe speed if the next turn is very close. Hence, we need to learn the track very well during the first laps so that we can precisely know the highest safe speed at every point of the circuit and also, we need to get a great control over the braking phase to slow down into such speed as fast as possible.

So far we had little time to improve the braking and graph isn’t showing good data from second 1 ahead but special attention has to be paid on how weights are transferred while deccelerating because the robot might lose traction thus making it to brake earlier. I look forward to working more on characterizing dynamic aspects of the robot and making the most out of it :)

Campus Party 2011

I'm back from the 15th edition of Campus Party and it was a great success for us regarding the competitions we took part in. Here are the results:

  • Web/Mobile App Development Challenge by Coritel (Accenture) - Innovation Area: 1st place!
  • "Best of Show" Robotics competition: 1st place
  • "Speed Runners" Robotics competition: 1st and 2nd places
  • "Campus Climbers" Robotics competition: 3rd place

CP prizes

I enjoyed very much this edition of Campus Party attending  great conferences  and meeting up with some old friends again and new people into robotics and technology. I'm already looking forward to the next edition and seeing more cool stuff during a whole week in Valencia :)


Drive the uXbot from your Android device

I wrote an application for Android OS based devices to control the uXbot robot remotelly via Bluetooth. This has been my first experience with Android development and, even though the UI creation isn't very straightforward, the rest of the features such as Bluetooth discovering, pairing or sensor data acquisition have been fairly easy.

 uXbot Mobile Manager SplashuXbot Mobile Manager


I'll be uploading some videos in the next few days and, when it's a little bit more tested, I'll be glad to publish the sources so that anyone can add new features (IR sensor readings, battery voltage, firmware uploading using uXbot internal bluetooth bootloader,...).




CRJET 2010 International Robotics Competition

Last 8th October took place the 3rd edition of the CRJET International Robotics Competition in Cataluña.

Silvestre was the WINNER of the Line Following Robots category. During the qualifying session in the morning, Silvestre set the fastest time, completing 3 laps to the 11.752 meters track in 14.02 seconds (2.5m/s average speed). Piolin - Silvestre's little brother - made the second best time at qualifying but had some issues and got a final 3rd place losing against Shibuya in the Semifinal round.

CRJET 2010 Qualifying results    CRJET 2010 Track

Its revolutionary positioning system allowed Silvestre to identify the main straight and to speed up to 4.8 m/s. Thanks to its inertial sensors and the wheel encoders, Silvestre could brake at the right point reaching the corner at a safe speed. This strategy had not been seen in any Line Follower competitions so far making Silvestre look even more impressive.

 Silvestre Highlights (the slow motion part is very cool 😉 )

Final Race, Silvestre VS Shibuya:

For the next contests, the challenge is to make another key improvement to keep Silvestre on the top of the podium.

Also, Tobias was awarded with the "Most High-Tech" prize in the "Best of Show" category so it was a pretty successful weekend :)


Silvestre - Line Following Robot

Silvestre Robot

Silvestre is a line following robot who was born early this year. So far, he's competed in two national contests in Spain achieving a 5th place in the first one and winning the other one.Among his main  features:

  • 8 Infrared sensors
  • Two Maxon DC motors
  • Bluetooth enabled (telemetry and configuration)
  • LPC2148 ARM7 32-bit microcontroller
  • PD Loop running at 100Hz
  • Error estimation using cubic interpolation over the IR sensors data
  • Accelerometer and gyro sensors

In the video above you can see Silvestre running on a 8.44m long track. Whenever he crosses the mark, sends the lap time over the Bluetooth link to a PC software which displays the timing information along with some other data such as battery level. In the best lap in the video he can reach up to 2.24m/s and as long as the wheels become dirty, the grip decreases and therefore, the times get worse.

The microcontroler's got 512KB the flash. Half of this memory's currently holding a custom filesystem to store configuration profiles (speed, PID constants, enabling/disabling features, etc.) which can be loaded, stored and deleted through the PC software.

In order to speed up the communication between the computer and the robots we designed a low bandwith binary protocol with error correction which's been implemented and optimized carefuly in all of our robots. This way, the development of new software (for both robot and computer side)  gets simplified from the communication point of view and there's no need to start over again every time. You can see an screenshot of the PC application we've built:


RL-Telemetry application

The inertial sensors help Silvestre to measure how good he's performing and enables him to adjust the speed and PID constants as  the wheels are losing grip. Basically, the accelerometer data is used to accelerate faster to the setpoint speed whereas the gyro tells him whether he starts drifting (too much angular acceleration).

In the contests being held in Spain, there are no marks indicating when a lap has started so there's no way for the robot to figure out when to modify its parameters  so something that might be useful as well with the gyro data is to be aware of the actual orientation of the robot. Thus, integrating the gyro signal, Silvestre knows when he is facing the initial position again and this is likely the starting point. However, this approach is not valid when the track's got two or more straights in the same direction because the robot will get to 360º and the lap's not been completed yet.

The key for improving Silvestre's performance has been undoubtely the ability to gather data from the sensors in real-time so that they can be later analysed on a computer.

My friend Alberto Calvo and me have worked hard on this robot and we're looking forward for new contests and challenges. Our main goal, rather than just following a line, was researching how the usage of inertial sensors and self-learning processes could be applied on this kind of robots.  We're still working on Silvestre in our spare times so I'll probably update this post soon.


uXbot Robot

I want to introduce you the brand-new uXbot (micro xBot) robot. It has been designed for educational purposes and with the main goal of serving as a base for the Robotics Workshop at Campus-Party España 2010.

 uXbot front view uXbot rear view


  • ARM Cortex-M3 32 bit Microcontroller (LPC1343)
  • Motor driver up to 3.5A
  • 12 Infrared sensors
  • Integrated battery charger
  • Battery Voltage monitoring
  • Firmware Programming via USB
  • 4 General Purpose LEDs
  • 800mAh Li-Po battery
  • Metal Gearbox motors
  • Bluetooth module

In order to make the development process easier, some libraries have been written  for the end user with the following layout:


uXbot library layout

  • HALLib (Hardware Abstraction Layer Library): Provides an interface to uXbot hardware and the microcontroller peripherals such as sensor reading, pushbutton, voltage monitor, motors, timing functions.
  • VCOMLib: Provides a USB Virtual COM Port driver (ACM profile under Linux OS) so that the user can communicate to a PC.
  • uXbotLib: This is a high-level library which will be mainly used by users who do not have/need to have any knowledge about the underlying electronics of the uXbot. It provides an interface to move the robot in any direction, an open-loop PID controller for line following, sensor reading and filtering, etc.

All the tools used to develop applications for the uXbot are free and available for both Windows and Linux OS (32 and 64-bit).

In order to control the uXbot through the USB VCom port or Bluetooth, a C# application has been written. Anyone will be able to use it from Windows or Linux (using Mono). Here you can see an screenshot:
uXbot Manager Software

I want to show you two videos. In the first one you can see the uXbot being controlled from a Windows Mobile device using a simply C# application which sends commands to the motors depending upon the PDA acclerometer sensor readings. It's pretty funny and addicting :) In the second one, the uXbot is following a black line at an average speed of 1.65 meters per second.

I would like to publish all the source and diagrams soon, so stay tunned :)


PS. You can find more information at (Wiki & Forum in Spanish).

TOBÍAS - Self Balancing Robot

TOBÍAS - Self Balancing Robot

Since the very first moment I saw a 2-wheel self-balancing robot I got amazed about all the engineering behind it and I was so excited to build one myself. So now that it's become a reality let me introduce you to TOBIAS

TOBÍAS - From 3D to real life

  • Mechanical Description:
    • 4mm thick PVC sheets
    • High torque motors (0.69 Nm)
    • High grip wheels (95mm diameter)
    • High momentum of inertia (~1.5 kg and modifiable Gravity Center with lead sheets)
  • Electronics:
  • Inertial Measurement Unit:
    • Accelerometer: Slow response & sensitive to acceleration forces due to movement
    • Gyroscope: Fast response & integration drift for angle estimation
    • Need to mix up the information from both sensors: Kalman Filter

Kalman Filter:

Kalman Filter data In this graphic you can see some data captured in real time by the microcontroller and then dumped offline to a PC for a later analysis.

The blue signal represents the estimated angle using just the raw data from the accelerometer: arc-tangent of y-axis by x-axis acceleration.
The green signal is the integration of the gyro sensor which clearly shows the drift over the time.
The red signal is the actual angle estimated by the Kalman Filter which shows that in the balancing state the angle falls between -3 and 3 degrees.
Block Diagram:

TOBIAS Block Diagram Here you can see the block diagram of the complete system. First, you can observe that the signals are sampled at 3200Hz (oversampling) and then low-pass filtered with a Finite Impulse Response (FIR) Filter with a cutoff frequency of 100Hz.

A 16x decimator is then used to obtain signals with a bandwith of 200Hz and no aliasing. This filtering process improved the angle estimation so much because a lot of noise was removed.

The inputs for the Kalman Filter are the angular rate and the estimated angle from the accelerometer which is computed using an atan2 function call. After that, some tests reported that the angle output by the KF had a precision of about .1º which looks really accurate.

This angle is ready to be processed in order to apply the right torque to the motors using a PID controller -tunned by hand- with more effort than expected (and desired). The integral part of the PID is computed by the trapezoidal rule while the derivative component is calculated using a 7-steps Savitzky-Golay derivator.

The output of the PID is then applied to both motors in order to keep it balanced.


The LPC2148 is a very powerful 32-bit microcontroller which shouldn't have many problems acting as TOBIAS' brain. However, the firmware was as optimized as possible in order to allow future improvements and, in the mean time, keep the processor in power down mode while not doing anything to save battery (every mA of current counts ;)).

In order to figure out how the microcontroller could handle all the tasks, a profiling of the execution was performed using a GPIO and a logic analyzer:


As you can see from the image above, there's plenty of time for the microcontroller to do some other things. This time was used mainly for logging purposes and in the current version, to read from a IR receiver and controlling TOBIAS using a cheap remote controller from an RC helicopter. This performance was achieved after optimizing the code of the most computationally expensive tasks (Kalman & PID). Also these functions execute from RAM and try to make a good use of the MAM (Memory Accelerator Module) hardware in order to speed its execution up as much as possible.

Considerations for future improvements:

The first approach was building a fairly good balancing robot without spending too much money and now I can say that it was definitely achieved.

The sensors used in the IMU were taken off a cheap PS3 gamepad bought on eBay, there's no commercial electronic boards (entirely own design) - apart from the cheap step up/down DC-DC controller ($15) -, and both the plastic sheets and wheels are quite cheap and, thus, the overall cost of the robot doesn't go beyond the 100€ ($140-$150).

However, the cheap motors made all the project a little bit more difficult (and challenging at the same time) than expected: they were not enough responsive and the gearbox wasn't tight enough allowing you to turn the wheels freely about 3 degrees.

I'm sure that if another motors were used in TOBIAS, the performance would have been way better but it was more exciting to face the PID tunning and the signal processing under these 'negative' conditions.

References & Greetings:

T.O.B.B. Balancing Robot by Matthias Toussaint: I would like to thank Matthias so much for answering my e-mails and pointing me in the right direction with his unvaluable advice. All the signal processing was based on TOBB's and the only main difference is that TOBB uses a very interesting complimentary filter (instead of Kalman) which works incredibly well as you can see in the video posted on his site. Thanks once again Matthias because I learnt a lot from you !!

Also big thanks to my friend Alberto Calvo, the co-author, who also made the 3D artwork shown in the article 😉

Final Result:

All in all, it's been a very interesting project and, as a reward, TOBIAS won a prize in the Freestyle Robotics Contest at Campus Party '09 last summer.
In this video you can see TOBIAS in action:


Playing with inertial sensors and Kalman Filter

I've started to build some sort of two-wheel Balancing Robot and before getting the party started I'm having to deal with mixing up the data gathered from my inertal sensors.

My homebrew IMU (Inertial Measurement Unit) is composed by one 3-axis accelerometer and 1-axis gyroscope. The gyro sensor's got an analog output (.67mV per degree/s) and the accelerometer's got an i2c interface. I would love to share its part number with you but, since I liked this unit to be as cheap as possible, the sensors were ripped out (and reverse-engineered with a logic analyzer) from a cheap PS3 gamepad bought on eBay ;).

Since the output of the gyro sensor is 'too low' for my ADC, I built a simple non-inverter amplifier and a low pass filter with a cutoff frequency of 1KHz. Also I placed a high pass filter (cutoff frequency at .3Hz) in order to compensate the temperature drift. The data from the accelerometer's digitally filtered on the microcontroller with a simple 1st order Butterworth filter.

Inverted Pendulum

The main idea of this kind of robots (inverted pendulum) is to measure the tilt angle in order to drive the wheels just below the mass. The higher the center of gravity, the easier balancing will be. Why do we need both an accelerometer and a gyro?

- The acclerometer senses not only the gravity (tilt) but the acceleration forces on its axis. So it would be useful if it was static (no acceleration due to movement).

- The gyro outputs angular velocity (degrees per second) and it's not sensitive to acceleration. In order to get the angular position we have to integrate this signal. However this will drift over the time and the estimated tilt angle wouldn't be accurate after some seconds.

The 'trick' is to take out the best of each sensor: the long-term information from the accelerometer and the short-term response from the gyro sensor. One way to do this is using a 'black-box' known as Kalman Filter (if you are brave enough, have a look at the theory; I'm not :)) which mixes up both signals predicting the actual tilt angle.

I got some source code of this filter from rotomotion ( and pushed it directly onto my microcontroller. The sensors are sampled at 50Hz and fed to the KF at the same rate. In the next plot you can see the raw tilt angle (atan2(raw_accy, raw_accx)), the integral of the gyro sensor (using the trapezoidal rule) and the output of the Kalman Filter.

Kalman Filter

As you can see, the raw tilt angle is a little bit noisy while the gyro integration is very clean. Also, there's a lot of drift in this signal but magically the KF manages to estimate the angle very accuratelly and free of noise.

Now it's time to try the filter with stronger movements and vibrations before feeding its output to the PID which will - hopefully - make the robot balance :)

I 'll post more on this soon!