If any of the info on this website was useful for your projects or made your head spin with creative ideas, and you would like to share a token of your appreciation- a donation would be massively appreciated!

Your donation will go to my Robotics Fund, straight towards more sensors, actuators, books, and journeys. It takes a lot to continue building these robots, and I’m really thankful of everyone who helps encourage me along the way.



“A wise robot once said to me through Serial.println- that robots teach us about ourselves.”

All posts tagged Arduino

Maker Faire Ottawa

Screen Shot 2014-08-15 at 10.24.29 AM

We showed our robots at the amazing Maker Faire Ottawa! There were many people who were interested in the robots, and became inspired to try building their own.

If you did not have the chance to make it to Ottawa, here is a video of our table!

Photos of our table:



Here are the statistics from what I’ve heard: There were about 4,000 people on the first day, and 3,000 on the second. They beat the total attendance from 2010 in the first hour. Maker Faire Ottawa is the fastest growing Mini Maker Faire. And if Commander Hadfield was in Ottawa, he would have visited too! Maybe next year ;D

We were also interviewed on CBC – read more here.

We had two RoboBrrds there. This new yellow one, Coolios, and the black Spikey one. Coolios works with a sonar sensor, except that it was a little buggy and it came across as a very hyper robot. Spikey works with the iPad App we developed, RoboBrrd Dance.


Kids always enjoy interacting with RoboBrrd!


(^ Thx to whomever took this photo, great shot!)


(^ Photo cred @edgarmtoro – Thx!)

At one point in time, kids were lined up to use the RoboBrrd Dance app. How cool is that?!

We added some new RoboBrrd Kits to the store. Check them out if you want to get started building!

We also had the Automatic Food Slicer Robot in action, slicing some playdoh.


Pretty much as expected- older adults were interested in this robot. I hope that I can make it more stable in the future, so that way they can buy / make one, and it will help them. That would be cool.

We recently finished off a portion of this project for entrance into the Hackaday Space Prize. We’ll be blogging about this later, but for now you can view all the information here.


Kids also enjoyed interacting with AFSR. This is mostly because we were using the cool Hover gesture board. It takes a little time to figure out how far and fast to wave your hand for the gestures, but once they get it then they can control the robot very easily.

One of the best ideas we heard: We could use this robot to slice the crusts off bread! 😀

The badge for Maker Faire Ottawa was absolutely stunning:


Here are some nice tweets from makers!

We were also displaying Clyde the robot lamp! Some of the backers of Fabule’s Kickstarter recently received their lamp too. Stay tuned for more info about what we are going to be making with our Clyde- it will be exciting!

A few weeks prior to the Maker Faire, we received a huge box from Intel. With our Intel Galileo 2, we will be making Cognito Collobot. The goal is to make a robot that can give a TED talk. This is for the new TED XPrize. It will be challenging, but we are going to try.

Also on our display board, two panels for people who were really interested in it, was detailing my Moonshot-In-Progress project. In terms of Google Solve For X, here are the three main points:

Huge Problem: With the rise of the aging population, there will be more need for assistance in their homes. The physical objects that surround them will become problematic as motor ability decreases.

Breakthrough Technology: (Work in progress) “The LED of motors” — something that can be soldered to a pcb, and when given power it can actuate. Different patterns could perform various actuations. There could be an abundance of actuators!

Radical Solution: When motors are as available as LEDs, we could add them to everything. With software, we could manipulate all the objects around us like they are fluid — even have the objects able to sense and automatically move based on previous patterns.

Everything around us would no longer be inanimate physical objects, but instead ones that are alive and can adapt to our needs and the environment.

As of right now, I currently have two main ideas on how to possibly make this work. Still have some more reading and learning to do, but I will be working on this. Watching the Solve For X videos have been very inspiring.

Has no one else on this planet been bugged by the fact that we can’t just tell things to move? It takes very long to add motors to everything. We should just have motor tape — or something similarly accessible.

We still have to work out the idea more, but this is a crazy goal that we will chase and strive to achieve some day. 😉

We also displayed the parts from the Laser Level Teardown. A couple of people were interested in this.

In four years from now, maybe we will be sponsors for Maker Faire Ottawa. This sounds like a great goal. :)

If you are looking to support my work in some way, back my fan-funding campaign on Patreon and check out the RoboBrrd store!

This was a great Maker Faire. Thanks to everyone for making it a huge success. Special thanks to Britta, Remco, Olivier, Amos and Naomi! Without your help I would not have been able to show the robots here, so thanks. :)




Promulgate is an Arduino library with a very simple protocol to allow communication from Arduino to other devices.

Check out the video to see it in action!

The library was designed so that you can add Promulgate quickly to a project. It is very simple to parse and transmit messages.

To get started, go to There is an example and boilerplate code for Arduino and Processing.

The code is available in this repository.

If something breaks in the library or could be improved, feel free to let us know. We’re constantly learning, so if it’s wrong, we might not have even realised this.

You can also see our post about our two Promulgate + iOS demos.

We were looking back at our log notes for the entire project last night. It took 23 days to create Promulgate, spanning across 40 days. Each day was 1 hour (give or take) of total focus. This includes the library, two iOS demos, Xbee demo, and documentation.

Just thought we would share this info about the development time. It’s actually a little personal to us, since we aren’t exactly lightning fast (we need to improve our pace). Though, it brings up an interesting point in evaluating success of a project. Do any other makers think about this beforehand?

For Promulgate we had a few factors in mind that would make it a success (to us). Most importantly, completing the project to our best quality, and our meticulous documentation so that it will be easy to make a quick demo even if we have not looked at the code in 3 months.

Making a good demo video of it in action was also important to us, because we are lucky enough to have the support of our Robo-Patron backers on Patreon. Our original video of this project was very monotone and not as fun, so we entirely scrapped it and started over.

Sharing it with others, hopefully seeing it be used in some projects, and learning about improvements from the community are also factors. These ones are tricky though, as it can really depend on the project if people enjoy it or not. It is nice when they do, though.

Evaluating the success of a project depends on a myriad of factors. The best part is that it is done now… so on to the more fun apps. “If hardware is the heart of a project, then software is its soul”.

This work was supported by our great Robo-Patrons. Consider backing us on Patreon to help us make more projects!


Promulgate Demos

Recently we were wondering about how to create a multi-player game with hardware interfaces on iOS.

We started working on a communication library (Promulgate), and created a few demos to tinker with it!

We showed the project on the Adafruit Show and Tell! Check out the video of the demos in action, 14 mins in:

The feedback was nice, and pointed me towards a place to look that we didn’t even know or think about. 😀 Read on below for more information about Promulgate, the demos, and BLE thoughts.

About Promulgate


We started with figuring out a protocol to use for communicating data between an Arduino, iOS, Xbees or Processing. A benefit of using a universal protocol is not needing to re-program the Arduino for each application. Just create a basic API, and go from there.

The definition of promulgate is to make an idea known to many people. Except in this case it is primarily robots, not people.

The protocol is simple:
Action Specifier • Command • Key • (Comma) • Value • Delimeter

It is just enough data to be able to specify routines, and some additional information for them.

The simplicity of the protocol assumes that there are already many pre-programmed actions in the API for the robot / Arduino project. The reason being for this, is because we have found that it works better- rather than sending a slew of messages.

Demo 1

The first demo uses the basic Promulgate app to view the latest received message, and send some messages out.


It uses our core code for BLE connections for displaying the connection window, choosing which module it is, and handling all the data. (Here is an older version of this code. Updated version coming soon.)


Module 1 (Arduino Uno + nRF8001 + Xbee) connects to the app. It then bridges the messages it receives from BLE through an Xbee. There are also buttons that can send messages through BLE and Xbee.


Module 2 (RoboBrrd Brain Board ATmega328 + Xbee + LCD) receives the messages via Xbee, and displays them on the LCD screen. It is useful for debugging.


RoboBrrd 3D (Arduino Pro Mini + Xbee) is also listening to the messages sent via Xbee, and specific ones will trigger routines such as moving its wings up and down.

Demo 2

The second demo dives in to using a round-robin system to connect and disconnect from Module 1 & 3. The app currently has no GUI, but is running timers to control the system. There are two main timers: connection timeout and countdown.

The countdown timer is how long the module stays connected before being disconnected. The connection timeout timer is how long to retry connecting to a module if it does not discover any services, or flat out does not become connected.

Adding in the connection timeout timer was critical for this demo to work. There were a few problems that prohibited the modules from connecting immediately. More on this later.

Module 3 (Arduino Pro Mini + BLE112 Breakout) is similar to module 1, except that it does not have an Xbee or buttons. The core code is the same, except that the BLE112 uses a different Arduino library than the nRF8001.


The BLE112 is where we started to run into some problems. Sometimes, for no apparent reason, it receives a message that was not even sent. (The payload data is a y with two dots over it, which also makes it look like this weird alien character that is evil and here to mess up all your systems.)

It halts whenever it receives this character. Sometimes it continues, sometimes it doesn’t.

Then there is the issue of having the module connect and disconnect reliably. If you’re really lucky, it will be able to disconnect and enter back into advertising mode. But sometimes it does not do this. Whenever it does not do this successfully, we actually try to reboot the module via code and the reset pin. Sometimes this works, but more often than not it gets ‘stuck’ and is just constantly resetting it hoping that it will realise it is not in a connected / connecting state.

It definitely seems like the state machine is borked with the BLE112. Or, it might just be the sample Arduino code that is messed up. Either way, it isn’t working as smoothly as well as one would hope. Sure, with many hours and possibly a TI CC debugger to modify the BGScript, it can be fixable — but this is not what we’re working on.

The countdown timer works reliably at 10 seconds. 7 seconds worked semi-reliably, with the BLE112 needing a manual reset sometimes. 3 seconds would cause the BLE112 to completely choke within the first two tries, and cause the entire system to lag.

We were originally hoping for less than 1 second. The connection and disconnection time has to be so rapid that the users of the app won’t notice any lag. Using two nRF8001’s will hopefully have less bugs. It certainly seems this way from this initial testing.

Round Robin, BLE Thoughts

We wanted to try out a round-robin technique just for fun. To see if anything bad would happen if we connected and disconnected the devices so many times and so quickly.

It turns out, later we saw two neat demos of this: multi-sensor and with BGScript.

Also, from Anki Drive:

“The Anki Drive app connects to multiple vehicles and iOS devices simultaneously.”

They use a nRF8001 in their cars. Still have to read through their code a bit more to see if there are any clues as to how they connect to multiple cars at the same time, or if they are going with a round-robin or similar approach.

So it does seem possible with a little trickery. :)

After hearing the tips from ladyada on Show and Tell, we looked through the Adafruit forums. Found this post from Kevin:
open the .xml config file for the UART service in nRFGo Studio
go to the GAP Settings tab
click ‘nRF8001 Setup > Generate Source Files > Generate only services.h’.

Here is what services.h looks like as is.

In the GAP settings we can modify all sorts of things, such as the advertisement name and how often.

Thanks to the ITP BLE documentation jam, there’s apparently even a way to get nRFGo working on Mac (video).

This is going to be fun >:)

Our first experiment will be to try to change the advertisement name. From there tinker with the other settings. Then try it out with even more nRF8001s. Wonder how fast the countdown timer will be able to go.


The next steps for Promulgate are to tidy up the library, gather all the code, prepare some examples, make a video, write some further thoughts and commentary about it… then release it to the world!

Excited to get this project done. It’s a stepping stone for more interesting projects. Really wish we would have thought of this a while ago. What a speed bump this has been. So stoked to try out the suggestions and see if the time for the round robin can be reduced even more. The services.h awaits fun adventures >:D. Just have to finish this first. Finish. Finish. Finish.


If you enjoy the demos above and the projects we make, please consider supporting me on Patreon or buying a kit from the RoboBrrd Store! (Thank you!)

Last Week: Maker Success Stories

Last week we spoke at the Maker Success Stories speaker series at the Kingston Makerspace. It was a blast!

Learning about the game industry from Liza was interesting. Her role is a producer for games. Her career path traversed many fields, which is interesting to see how you can exchange experience from one field to another with some cleverness.

One of the key points that stuck with me is that she said it feels like she is failing her job if anyone on the team has to stay overtime to finish a task.

Wow. So true, right? For example, if I don’t stay focussed during the day, some tasks get shunned to be later and later. Working later on them and not sleeping to meet a deadline, eventually leading to more burnout. Burnout is exceptionally more noticable when you are a team of 1 person. It also makes me wonder about the future, if I actually had a team… Hmm.

Tim posted a photo of the RoboBrrd circuit board artwork that went crazy viral, pretty fun!

We sold two brand-new RoboBrrd 3D Kits. It was an absolutely fantastic moment!

Last but not least was this great quote and response. Means a lot. Hope I can make it happen.


We just finished documenting the electronics for RoboBrrd 3D.

Progress has been made on the Automatic Food Slicer Robot! Working on some more tweaks for the Z-Axis Carriage sub-assembly:

Until next time (which will hopefully be quite soon with finalising Promulgate), make cool robots!