Page 2 of 5

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 :)

SecuDroid - Android Anti Theft Loss app Review

SecuDroid - Anti Theft/Loss app for Android

Google is now activating over 500,000 devices each day, growing at 4.4% week on week. This huge raise, led to a big explosion of apps being downloaded from the Android Market, which - at the time of this writing - is 6,148,593,955 (more info at

Among these, there is one particular kind of application which is potentially useful for every single Android user: an app which allows you to locate, track or find your phone in case of theft or loss. SecuDroid is one of those must-have apps which you'd better not need to use, but you'll definitely be glad to have it when somebody steals your phone or you lose it somewhere.


  • Location information including accuracy, speed and altitude 
  • Periodic tracking
  • Silent pictures using either the front or back camera
  • Remote Lock & Wipe functions
  • SIM card change notification 
  • FindMe Ringtone
  • Invisible Mode
  • E-mail integration  


  • How does SecuDroid work?

SecuDroid sleeps silently in your Android device waiting for commands sent from any cellphone by SMS. The answer to these comands will be sent by SecuDroid either by e-mail or by SMS.

These SMS will not show up on your phone because they are intercepted by SecuDroid, so the thief will not suspect that you are on your way to recover your phone.

  • How can I be sure that nobody will be able to track me if I install SecuDroid?

When you request an action from SecuDroid you must precede the command with a password. This password can be changed at any times from the SecuDroid configuration window and, by default, it is set to "PW" (without quotes).  Anyone who knows this password will be able to track you or even wipe your data off your phone.

  • How can I hide SecuDroid so that noone knows that it's there?

SecuDroid will appear as "eNotes" under the installed applications list. Also, you will be able to remove the launcher icon from the configuration window.

  • If I remove the launcher icon, how can I modify the settings?

You'll be able to launch the configuration window by dialing a pre-configured code from the stock phone app. This code, by default, is 3535 but you can change it at any times.

  • Will SecuDroid be able to determine my location even if GPS is off?

In order to switch GPS on, Android enforces the user to do it manually. However, SecuDroid will enable the GPS hardware without user interaction (by tricking the OS) to get the location and, afterwards, it will switch it off automatically to hide itself. Nonetheless, it is highly recommended that you test this feature in your particular device because this is likely to be avoided by Android in the future. In this case, just leave the GPS setting on (no impact on battery life) or you'll only get positions based on GSM towers triangulation.

  • Somebody stole my phone and I want to find out who, will the thief be able to locate the pictures in the phone storage?

No. Pictures are stored temporally without image extensions and they will be erased right after being sent

  • If I take a picture remotelly, will the thief hear the camera shutter sound?

SecuDroid will take pictures silently by disabling the shutter sound. However, some devices are impossible to get the shutter sound disabled due to legal restrictions so you must make sure how your device works by testing it first. You'll probably be able to disable it by some other means like rooting your phone and removing the sound but SecuDroid doesn't encourage you to root your phone unlike other apps.

  • The FindMe function is pretty cool but what if I left the phone in silent/vibration mode?

Just send a BEEP command to your phone and SecuDroid will ring loud for 60 seconds or until you switch the screen on/off no matter what the previous state was. After this command, volume will be set at maximum leve so you're free now to call and find out where the sound comes from

  • Just realized that I lost my phone with critical information. How can SecuDroid help me?

Before trying to track or locate your phone, you should lock it with a password to make sure that noone can access to your sensitive data or even make calls. If you feel that the information inside your phone is even more important than the device itself, wipe the data within a few seconds by issuing a WIPE command.

  • Transparency is really important. Does SecuDroid include any phone-home component that could compromise my privacy?

SecuDroid does NOT include any phone-home component. You can be completely sure that SecuDroid will not connect to a 3rd party server and will not use your location or personal information in any ways.

  • What e-mail account does SecuDroid use to send the pictures and location info to?

You can configure a GMail account from SecuDroid settings window and this will be the account used to send the answers to remote requests. If, for example, this account is removed or you change the password, the answers will be sent back via SMS (or MMS if a picture was requested). The default destination e-mail address is also configured and has not necessarily to be a GMail address.


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,...).




Silvestre & uXbot - Line Following Champions

Last week, we attended two of the most important championships in Spain with Silvestre and uXbot.


  • In Hispabot, the track had a ramp which was pretty challenging for our robots since they were not designed with this in mind. The major problem was that the robots got blind for a while in their way up and also in their way down. This problem was worse for Silvestre since it's larger and its sensors spent more time in the air, reason why the uXbot managed to get to the top of the podium with Silvestre right behind him on the 2nd place.
  • Robolid hold a really crowded championship with around 80 robots taking part in the robotrackers category and 20 robots in the Line Following contest. Silvestre and uXbot had to fight with most of the best robots in Spain and they finally won with Silvestre in the 1st place and uXbot 2nd.  On a side note, a new electronic system was used during the contest to measure lap times, average and top speeds and Silvestre's top speed was over 5 meters per second (18 km/h)!

The most remarkable features of the robots are:

  • DC Maxon motors
  • FPGA to accurately read the quadrature signals from the encoders and real-time processing (Silvestre)
  • Inertial sensors
  • Track learning: the algorithm takes about 2-2.5 laps to identify when the lap starts over and extract the characteristics and speed-up/braking points.
  • Adaptative behaviour: Throughout the laps, the robots modify their parameters (speed, speed-up/braking points,...) for each part of the track. This allows the robot to adapt themselves to the track conditions (dust, creases, ...)

Below you can see a video from the training days to the final round of the latest contest. Some slow motion parts show how the robots performed over the ramp at Hispabot and how they had to fight with the skids right after the downhill 😉


uXbot Bluetooth Bootloader

I've never liked to use an external hardware to program microcontrollers, so one of the reasons to choose the LPC1343 microcontroller for the uXbot robot was its internal USB MSC bootloader which enables users to download their firmwares by dragging & dropping files into a flash drive. However, when you're working in your robot, sometimes it's a pain to pick it up and plug it to the PC, specially when you're a lazy engineer 🙂 so here I want to introduce you a tiny Bluetooth Bootloader for the uXbot robot.

Bootloader Flash Layout

As you can see, the bootloader resides at the end of the flash memory and whenever the user code jumps into it, it copies itself to RAM before starting the flashing process. This way, the bootloader can also be updated from the bootloader itself 🙂 In the video below you can see a demo of the bootloader in action. From the uXbot Manager PC application the firmware is downloaded into the robot's memory (via Bluetooth, of course) and the new code can start running right after the process is completed (less than 2 seconds to download a ~2KB firmware).  The user code jumps into the bootloader whenever the button is pressed but the application can enter the bootloader remotely or by any other means.

Stay tunned.


ARM Cortex-m3 - Remote debugging using GDB (1)

One of the things I've found more interesting and useful in Robotics is debugging.

Most of the time we use to print out traces through a serial port and, the luckiest ones, who own a JTAG emulator, can dig deeper into their bugs but always with a cable plugged.

So, now thanks to the excellent Espardino project and the help of its author, Ajo, who is a very good friend of mine, I decided to write my own stub for the ARM cortex-m3 architecture. You can check out more information about Espardino's remote monitor here.

Also, the following are a nice source of information I used to write this stub:

The video below shows a debugging session of the stub running inside the LPC1343 ARM Cortex-M3 of the uXbot robot. The GDB is connected to a tiny application which acts as a bridge between the TCP connection and the bluetooth link to the robot. Given that this application is listening on a TCP port, the GDB debugger can be running somewhere else (on my iPhone? ;)) and it would still work.

In my next article I will get more into detail about the stub itself and the exception handling.


SPI Communications - Slave Core VHDL

SPI (Serial Peripheral Interface) protocol is a synchronous serial data link which operates in full duplex mode. It's got a higher throughput compared to I2C or SMBus  and it's very useful for high speed short-range communications.

The SPI protocol specifies the following signals:

  • SCLK — Serial Clock (output from master)
  • MOSI/SIMO — Master Output, Slave Input (output from master)
  • MISO/SOMI — Master Input, Slave Output (output from slave)
  • SS — Slave Select (active low, output from master)

All lines can be shared for every slave device in the bus except the Slave Select signal which has to be different (out of band selection) for each slave.

This is the basic operation depending on the CPOL and CPHA values:


The SPI core I've implemented is fixed for Slave and CPOL=0/CPHA=0 modes. This means that the MOSI line will be sampled at every rising edge of the SPI Clock whilst the MISO signal will be set right before this rising edge (actually, on the falling edge) so that it can be properly sampled by the Master.

SPI Module

As the FPGA will have its own clock, we'll be having two different clock domains since the SPI master signals will be generated externally and they won't be necessarily synchronized to the FPGA internal clock. Thus, the approach will be sampling all the external signals to get them synchronized and using two shift registers for input and output data.

 Source code:

entity spi_slave is
  port (
    RESET_in    : in  std_logic;
    CLK_in      : in  std_logic;
    SPI_CLK     : in std_logic;
    SPI_SS      : in std_logic;
    SPI_MOSI    : in  std_logic;
    SPI_MISO    : out std_logic;
    SPI_DONE    : out std_logic;
    DataToTx    : in std_logic_vector(7 downto 0);
    DataToTxLoad: in std_logic;
    DataRxd     : out std_logic_vector(7 downto 0)
end spi_slave;

architecture Behavioral of spi_slave is

    signal SCLK_latched, SCLK_old : std_logic;
    signal SS_latched, SS_old : std_logic;
    signal MOSI_latched: std_logic;
    signal TxData : std_logic_vector(7 downto 0);
    signal index: natural range 0 to 7;
    signal RxdData : std_logic_vector(7 downto 0);


 -- Sync process

  process(CLK_in, RESET_in)

    if (RESET_in = '1') then
      RxdData  '0');
      index <= 7;
      TxData  '0');
      SCLK_old <= '0';
      SCLK_latched <= '0';
      SS_old <= '0';
      SS_latched <= '0';
      SPI_DONE <= '0';
      MOSI_latched <= '0';

    elsif( rising_edge(CLK_in) ) then

      SCLK_latched <= SPI_CLK;
      SCLK_old <= SCLK_latched;
      SS_latched <= SPI_SS;
      SS_old <= SS_latched;
      SPI_done <= '0';
      MOSI_latched <= SPI_MOSI;

      if(DataToTxLoad = '1') then
          TxData <= DataToTx;
      end if;

      if (SS_old = '1' and SS_latched = '0') then
          index <= 7;
      end if;

      if( SS_latched = '0' ) then
         if(SCLK_old = '0' and SCLK_latched = '1') then
            RxdData <= RxdData(6 downto 0) & MOSI_latched;
            if(index = 0) then -- cycle ended
               index <= 7;
               index <= index-1;
            end if;
         elsif(SCLK_old = '1' and SCLK_latched = '0') then
            if( index = 7 ) then
               SPI_DONE <= '1';
            end if;
            TxData <= TxData(6 downto 0) & '1';
         end if;
      end if;
     end if;
   end if;
   end process;

   -- Combinational assignments

   SPI_MISO <= TxData(7);
   DataRxd <= RxdData;

end Behavioral;

In order to test this core I wrote a simple testbench wich basically waits for a command from the master and answers it. This will serve as a base for the microcontroller code which will send this same command (0xA0) and wait for the answer (0xA4). This is the simulation view:


As you can see, when the spi_done signal goes high, the datarxd register is loaded with the value 0xA0. Afterwards, the answer to this command (0xA4) is loaded into the datatoxload register and the MISO line is set to the right bit at every falling edge of the SPI clock signal.

As the simulation looks good, I decided to wire up the FPGA to an LPC2148 microcontroller and test the SPI core for real. The following code will run in the LPC:


void send_fpga_cmd(unsigned char cmd)
    unsigned char dummy;
    IO0PIN &= ~(1<<11);    // Select FPGA
    while ( !(SSPSR & 0x02) );
    SSPDR=(unsigned int) cmd;
    while((SSPSR & (1<<4)));
    IO0PIN |= (1<<11);    // deselect FPGA
    dummy = SSPDR;         //flush the RxFIFO


unsigned char read_fpga_byte()
    unsigned char data;
    SSPDR= 0xFF;         // write dummy data out to gen clock
    while((SSPSR & (1<<4)));
    data = SSPDR;
    return data;

    data = read_fpga_byte();

I configured the SPI bus to run at 2MHz on the microcontroller. Here you can see the logic analyzer output which shows that the SPI core works as expected.


As you can see, the microcontroller sends a ping (0xA0 byte) and the FPGA answers with a response command (0xA4 byte). The SPI clock frequency is exactly 2.000MHz and the behavior is the expected one.

Silvestre FPGA - SPI Test
Silvestre FPGA - SPI Test


FPGA - Actel ProASIC3 First Steps

I want to show you how easy is to start playing around with FPGAs. The following example is based on the Actel A3P250 Devel board programmed with the microJTAG board.

The idea is simple: we're going to design a PWM module and make the on-board leds flashing at different rates. The RTL design of the PWM module is shown in the picture below:

PWM component RTL

Let's have a look at the components inside the PWM module:

PWM Module RTL

As you can see the 10-bit PWM module has got one register, a 10-bit counter and one comparator. To test our module, I'll write a simple VHDL code:

-- test.vhd
library IEEE;

entity example2 is
    Port (

                LEDS:out STD_LOGIC_VECTOR(3 downto 0);
                CLK_in: in STD_LOGIC;
                RESET_in: in STD_LOGIC

end example2;

architecture Behavioral of example2 is

component pwm is
    Port (

        CLK_in:     in std_logic;
        PWM_in:     in std_logic_vector(9 downto 0);
        PWM_load:   in std_logic;
        PWM_reset:  in std_logic;
        PWM_out :   out std_logic

end component;

      signal counter: natural range 0 to 48000;
      signal result: STD_LOGIC_VECTOR (9 downto 0);
      signal pwmout: STD_LOGIC;
      signal clk_div: std_logic;


    pwm1 : pwm port map ( CLK_in => CLK_in, PWM_in => result,
 PWM_load => '1', PWM_reset => not RESET_in,
 PWM_out => pwmout);

         if (RESET_in='0') then

            counter <= 0;
            clk_div <= '0';

        elsif (CLK_in'event and CLK_in='1')    then

            if (counter = 47999) then
                clk_div <= not clk_div;
                counter <= 0;
               counter <= counter + 1;

            end if;
        end if;

    end process;

    process(clk_div, result)
        if (clk_div'event and clk_div='1')    then
            result <= result + 1;
        end if;

    end process;

    LEDS <= (others => pwmout);

end Behavioral;

The frequency divider makes the 'result' signal increment every 48K*2 ticks of the main clock (24MHz). The 'result' signal is connected to the input of the PWM module which will load its value every time it changes because the LOAD signal is always '1'.

The result will be that every 4ms, the PWM input will increment by 1 from 0 to 1023 (10 bit value). The PWM output - which is connected to all LEDs in the  board - will take all values after 4 seconds and the cycle will repeat continuously.

You can download the whole source code from the link below:

VHDL Source code

The A3P250 Devel kit was a present from my friend Ajo and I want to thank him for such a nice board 🙂