As it’s obvious, communications with a drone can’t be made through a wire. While I will use the “wire setup” for testing the code, the final communication shall be made wireless. There are different ways of implementing wireless in Arduino projects, but a lot of people would agree that, even though there are different alternatives, the most famous and used modules are the XBee. These little guys implement ZigBee protocol and they can be configured in a couple of steps and the communication is pretty stable in short range (we don’t expect them to work beyond 100m for example).

There are several tutorials on how to work with them so I won’t spend time explaining it. The material that I use is:

  • 1x XBee Explorer USBThis one is connected to the computer directly. If your code is prepared to communicate with Arduino via USB, you won’t even have to change a line, this module will make the wireless communication transparent for you.
  • 1x Arduino Wireless ShieldThere was also a XBee shield (now deprecated) that I happen to use. Either one is fine. This will be connected, obviously to the Arduino.
  • 2x XBee S2 modules (2 mW): One of them is connected to the XBee Explorer USB and the other one to the Arduino shield. Tip: If you’re building a drone or something that is going to move, maybe a module with a PCB antenna would be your best option. I got two modules with the wire antenna and the module that was aboard the drone ended up losing its antenna due to crashes. The range is going to be the same with either module, but a module with a PCB antenna is going to have longer range than a module without antenna at all! 🙂

A little tweak needs to be made here: I’m not using an Arduino for this project! Even though the whole code is valid for Arduino, the hardware is totally different. That’s why I designed the PCB I showed before which will be able to connect everything that I want to the same board. In this PCB, I connect the Teensy to the XBee module following these simple instructions. So before ordering the PCB, I need to know that this communication is good. So let’s test it:

Read the rest of this entry »


BXDrone meets Eagle

Posted: 07/31/2016 in BXDrone, General

I guess one of the most tiring things when doing electronics projects is to have 1000 wires going all over your circuit, and you end up losing track of what’s what. That’s why PCBs (Printed Circuit Board) were invented! We see them everyday but not many of us have designed one for our own usage.

There are several programs able to do the full design of a PCB, but I guess the most popular one is Eagle. Pretty basic and easy to use, mostly if you know what you’re doing! Knowledge of electronics is not strictly needed, but it’s always more than recommended to have studied some basic electronics before. Even if you’re a beginner with PCBs and studied some electronics in college but basically forgot around 75% of the stuff because it’s been eons since you last looked at a circuit (sounds pretty much like me!), don’t worry: Half of what you need to know you’re going to learn it along the way and the other half is stuff that you’ve forgotten, but it’ll only take you a 10-second Google search to remember it.

This post is not going to a tutorial about Eagle, there are several places to read that (the SparkFun tutorial is pretty much recommended!). The overview is that designing a PCB is a 2-step process:

  1. Design the schematic (the circuit itself).
  2. Design the PCB: Arrange the components in the PCB and route the connections.

In my case, I designed a PCB for the BXDrone that is going to be mounted in the structure. There are too many components so we better put them all together in a custom board.

So I present you here my schematic, pretty clean, I didn’t want to fill all the space with wires, so I just named the nets and Eagle connects them all together.


There’s the Teensy, the XBee module and some other stuff that I wanted to add, like connectors for the motors, jumpers to switch between USB/XBee communication, and voltage regulators, as the whole thing is going to be powered by a 11.1V battery: Teensy needs 5V to work and the XBee module uses 3.3V… Anyway, if you try to power an Arduino with a 11.1V battery, I’ve read that it can be powered even with 12V… I tell you, the Arduino will burn… found out first hand!!

So after designing the schematic, I have done this for my final board design. I included some holes to attach it to the drone. The distance between the holes is measured in the drone structure, however I might need to do them larger, so I tried to leave some space around them.Untitled

The measures are in inches and they are placed there as a reference, but they should be deleted before sending it off to fabrication. The reason why they’re there is because I wanted to put the IMU right in the center, which should the drone’s center. Otherwise, when the drone is spinning I am afraid that it detects some small forces in the wrong axis, and since I am not an expert and I can design the PCB however I want, I decided not to risk it!

So this is it, the whole design is included in the GitHub repository (check into the “develop” branch, “hw_design” folder).

Play around with Eagle, design your own PCBs and you’ll find eventually it’s a very useful tool! Leave any comments if you have any questions (I’ll try to answer them!) or if you see something wrong in my board 🙂 Cheers!

Links of interest:

Eagle website:

SparkFun Eagle tutorial:

Tips on PCB design:

It’s been some time since I have started working on the BXDrone project, and there are several parts where the timing is critical: If you expect your flight controller to modify the motors’ speed during the flight so they compensate the tilting of the drone, you need to make the calculations quick. Usually the ESC (Electronic Speed Controller) update the signal they send to the motors 450 times per second (this is, every 2.22 milliseconds), maybe 100 times per seconds (every 10 milliseconds) as the slowest refresh frequency, so you need your flight controller to send the ESC new speed data at least as fast as they work. Therefore these numbers are critical, and you need to make sure that the code you write for your flight controller is not slower than these rates.

Lately I have included in my BXDrone code the module “TimeRecord”, which allows me to measure how fast any part of the Arduino code is. I created a new repo so you can download it and include it as a library for your Arduino sketches. The usage is pretty easy, a text document included in the repository will give you an example of how to use it. If you are interested, keep reading to see a usage example and a demonstration on how I use the TimeRecord library.

Read the rest of this entry »

Hello again! After some time lurking in the shadows (not really lurking, I just didn’t have enough time) I decided to re-start again some projects, like the BXDrone, whose new code is available on GitHub, but it’s still on a raw state.


However this post will talk about the BusTracker project. I have already shown how it works (refer to previous link), and even though the code has changed, the basics are the same. The major changes that I have introduced are:

  • Change Ethernet with WiFi. “Hey dude, that’s not a major change! Just change a couple of code lines but the rest is the same”. Kind of. I decided to use the Adafruit CC3000 WiFi board, which works perfectly in Arduino and Adafruit provides with very good examples of how to use it.
  • Change Intel Galileo with Arduino. If you remember, I was using an Intel Galileo instead of an Arduino for this project, and there are several conflicts with the Adafruit CC3000 library and the Intel Galileo, so I had to use an Arduino. “Ok, still it’s good. What’s the problem on that?”. Memory, my friend. Memory is everything, and while Intel Galileo has 256MB of memory, Arduino Uno is playing in the Major leagues with 2kB RAM. That’s OK for most of the applications that Arduino has. Even we can scratch off some free memory storing fixed strings and variables in Flash memory. However, the Saskatoon transit website we are trying to download has 22,000 characters (1 char = 1 byte) in its source code, this is 10 times larger than Arduino’s RAM memory. Before you know it, your program is in a coma.
  • Download website in chunks of X bytes. In my code, I set this X to 50 bytes. My code reads 50 bytes of the source code we are downloading, extract whatever information is useful (bus line, waiting time, etc.), throw it away and read the following 50 bytes.

Even with these fixes, Arduino get stuck sometimes. It can be 1 minute after the program has started, it can be after several hours… who knows? It’s really annoying that each time this happens, we have to push the reset button. That’s the reason behind the new feature: Watchdog timer.

“What’s a watch-what?”. Do you see what I said before about hitting the reset button whenever the program gets stuck? That’s what a watchdog does, without you having to take care of it. It’s a module in the microcontroller that sets a countdown at the beginning. Before the countdown goes off, you tell the watchdog “Hey! The code is still working!” and the watchdog resets the countdown to the original value. If, for any reason, you don’t notify the watchdog that everything is OK (for example, when your code gets stuck), when the countdown goes off, it’ll reset the Arduino, and this process will start all over again.

It’s pretty useful for situations like these. “Hey dude! Still you’re not preventing that the Arduino gets stuck!”, yes I know, but I get the program to give me continuously the waiting time for the buses, which is what I want, even though it gets stuck

For Arduino, the code is really simple:

#include <avr/wdt.h>

/* Auxiliar variable */
int k = 0;

void setup(){
    // Use the Serial comm to know when it resets

    // Initialize watchdog (countdown = 8 seconds)

void loop(){
    // Print a number and add 1 afterwards

    // Feed watchdog (uncomment this line to keep the watchdog from resetting
    // wdt_reset();

    // Insert 1 second delay

The code above sets up the watchdog but doesn’t feed it (note the commented line on the loop() function). In this case, the watchdog should reset the Arduino after 8 seconds (i.e. when the countdown ends). You can check that if you open the Serial port and see that after printing “8” or “9”, it goes back to print “0”, “1”, etc. That means that the Arduino has been reset.

There are some other ways of resetting the Arduino (the one that I like the less is connecting a digital pin to the reset pin. That doesn’t seem like a safe reset at all), but a lot of people would agree that a watchdog reset is the best and safest way of doing a software reset.


NASA’s Curiosity is an example of a system implementing a watchdog timer.

The watchdog timer is a well-known module in embedded systems, since in most cases we don’t have direct access to embedded systems and they have to reset themselves in case of a failure. An example of this is the Curiosity emergency reset in 2013, when it had an unexpected software reset. In case any part of the Curiosity code gets stuck, you won’t expect anyone to go to Mars and hit the reset button, so you have to foresee these kind of situations. Usually after a watchdog reset, you have to check what caused the reset. As part of the watchdog module, usually after the reset it provides some information about the reset, like in which memory address the program was, or which code line, etc. Refer to links below for more information.

And that’s all so far! Stay tuned if you’re interested in the code (by what I’ve heard from friends, we all want to have a display at home that shows when the next train/bus is coming!) and comment with any question or any information you want to ask/add. Thanks for reading!

PS: In case anyone living in Saskatoon was wondering, no, the recent changes on the bus lines hasn’t affected the code 🙂 It works just as fine as it did before!

Links of interest:

Watchdog timer in Wikipedia:

Detect lockups in Arduino:

A couple of weeks ago I showed you how to include WiFi communications in your Arduino using the Adafruit CC3000 WiFi board. Now it’s turn for the server side. In this case, my server is going to be the computer, so this work will be done in Java, as my project uses Java in the computer side (and that’s how I did it!). If you want to use C/C++, there is a good tutorial on sockets in C that will teach you how to set up a server using sockets. There is also the choice of using another Arduino with an Adafruit CC3000 WiFi board as the server, but I have not implemented. However, the library for this board includes examples that will help you do that. In case anyone is interested in doing it and cannot make it work, I can take a look. But as I said, Java will be used this time (also we will see how to implement this in another language, since the client implementation is very similar to the server one).

Sin título

Arduino – Computer WiFi communication

First of all, I will explain what I did to establish the communication with my Arduino and then I will point out some details that require some moments to think about.

Read the rest of this entry »

So recently I decided to recover an old project that I started a couple of years ago: Bercianity, a small rover vehicle made out of Lego pieces and controlled by an Arduino. The system was simple: Arduino is the brain of the rover and had a communication with a Java program on my computer. This communication was over USB, so the Serial library was used in the Arduino side. An XBee module was used to perform the wireless communication but the code was still the same.


Adafruit WiFi breakout board

Now I decided to move it so computer and Arduino communicates over WiFi. I wanted to explore the WiFi connection and I believed that the range could be larger than XBee’s. I am going to review here the easy steps that I took to port from Serial to WiFi communication, first on the Arduino side and then on the computer (which will be explained on the next post).

Read the rest of this entry »

I have shown a bit of this short project for bus tracking but I haven’t explained anything, so I thought it was about time to describe how I did this.

First of all, to display the waiting time for the bus, first we need to get that information. There are two ways of doing this, depending on the city you are interested in:

  1. Use GTFS-realtime data. This would be the hardest way to implement, because you have to learn how it works, but it would be the best suitable for any other city that uses GTFS-realtime for its transit. You can find some tutorials like this that will teach you how to handle GTFS data. Also other transit companies, like Chicago Transit Authority, have their own API and feeds that you can use.
  2. Parse the data from an already-built bus tracking website. This is the case of the city I chosen, Saskatoon, SK (Canada). They have this website that gives you all the real time information you need about the buses.

So, I decided to go for option 2. Why? I didn’t seem to find a GTFS-realtime feed for Saskatoon, only the GTFS feed that gives you the bus lines’ IDs, bus stops, scheduled stop times, etc., but no real-time information whatsoever.

Read the rest of this entry »