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 in Programming



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!

Buddy 4000 + BLE App (work in progress)

We’ve been long awaiting the days when communicating to our robots from an iOS device would involve less jumping through hoops! BLE on the newer iOS devices is pretty sweet.

Here is a video demo of our app interacting with Buddy 4000 using BLE!

We’ve been working on this off and on for a few months. Actually, half of the core functionality was finished a while ago (sending data from the iOS device to the robot). The BLE module we were using wasn’t configured properly to send data from the robot to the iOS device, and we didn’t have a TI CC debugger needed to re-program the BlueGiga chip so yeah… When we heard that @sectorfej had new modules in his InMojo store, we quickly bought one!

Here is the BLE module (wires are 5V, GND, TX, RX):

ble_buddy_wip 004

There’s a great BGLib library for this module that has all sorts of features packed in to it. There wasn’t much documentation about sending data… Here’s how to do it:

  1. ble112.ble_cmd_attributes_write(20, 0, data_len_var, data_var);

The number 20 is the hard part. We couldn’t figure out where to find the info about this number or anything… so we iterated from 0-49 to find it! You might have to do the same for yours as well. Just keep an eye open on Xcode for when data is received on the app side, and then narrow down the numbers until you find the one that works.

We didn’t show this in the video, but we use sending data from the robot to the app for triggering sounds. Specifically owl and fart sounds. (Yes, this might be the most complex fart app to date). It works better with RoboBrrd, as it has sensors that can be used to trigger the sounds.

Anyway, most of the ‘core functionality’ of the app is involved with this (below) and the communication. We can even make it auto connect to a particular device (as you saw in the video), which makes the experience even more seamless.

ble_buddy_wip 003

Here is how auto-connection is done. We save the UUID and name of the device, then check if we see that specific one:

  1. (void) connectToDefault {
  2.     // ok, let’s try this
  4.     if(connected) return; // already connected don’t do anything
  6.     NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
  7.     NSString *givenUUID = [userDefaults objectForKey:defaultDeviceUUIDKey];
  8.     NSString *givenName = [userDefaults objectForKey:defaultDeviceNameKey];
  9.     //CBUUID *zeeUUID = [CBUUID UUIDWithString:givenUUID];
  10.     CFUUIDRef zeeUUID = CFUUIDCreateFromString(kCFAllocatorDefault, (CFStringRef)givenUUID);
  12.     int i = 0;
  13.     for(CBPeripheral *periph in allPeripherals) {
  15.         if(periph.UUID == zeeUUID) {
  16.             NSLog(@"same UUID");
  17.             if([ isEqualToString:givenName]) {
  18.                 NSLog(@"same name – let’s try to connect");
  19.                 self.peripheral = periph;
  20.                 [bleManager retrievePeripherals:[NSArray arrayWithObject:self.peripheral]];
  21.             }
  22.         }
  24.         i++;
  25.     }
  27. }

Sometimes specific BLE modules have certain service UUIDs and characteristic UUIDs that you can only send data to. We’ve never experienced a problem with ‘spamming’ everything (yet), but we built in this feature just in case. This is when data is being sent from the app to the robot.

  1. CBUUID *uuidService;
  2.     CBUUID *uuidChar;
  4.     int ss = [selectedShield intValue];
  6.     switch (ss) {
  7.         case 0: {
  8.             // any
  9.             uuidService = [CBUUID UUIDWithString:roboBrrdServiceUUID];
  10.             uuidChar = [CBUUID UUIDWithString:roboBrrdCharacteristicTXUUID];
  11.         }
  12.             break;
  13.         case 1: {
  14.             // kst
  15.             uuidService = [CBUUID UUIDWithString:kstServiceUUID];
  16.             uuidChar = [CBUUID UUIDWithString:kstCharacteristicTXUUID];
  17.         }
  18.             break;
  19.         case 2: {
  20.             // dr kroll
  21.             uuidService = [CBUUID UUIDWithString:drkrollServiceUUID];
  22.             uuidChar = [CBUUID UUIDWithString:drkrollCharacteristicTXUUID];
  23.         }
  24.             break;
  25.         case 3: {
  26.             // redbear
  27.             uuidService = [CBUUID UUIDWithString:redbearServiceUUID];
  28.             uuidChar = [CBUUID UUIDWithString:redbearCharacteristicTXUUID];
  29.         }
  30.             break;
  31.         default:
  32.             break;
  33.     }
  36.     for(CBService *aService in {
  37.         if([aService.UUID isEqual:uuidService] || ss == 0) {
  38.             for(CBCharacteristic *aCharacteristic in aService.characteristics) {
  39.                 if([aCharacteristic.UUID isEqual:uuidChar] || ss == 0) {
  40.                     [self.peripheral writeValue:sendData forCharacteristic:aCharacteristic type:CBCharacteristicWriteWithResponse];
  41.                 }
  42.             }
  43.         }
  44.     }

This also allows us to do certain actions for different shields. While going through the example code for the RedBear BLE shield, we noticed it needed a ‘reset’ (or something). We haven’t tested this yet, but hopefully it will make the RedBear one work:

  1. if([selectedShield intValue] == 3) { // redbear shield is weird
  3.         CBUUID *uuidService = [CBUUID UUIDWithString:redbearServiceUUID];
  4.         CBUUID *uuidChar = [CBUUID UUIDWithString:redbearResetRXUUID];
  5.         unsigned char bytes[] = {0x01};
  6.         NSData *d = [[NSData alloc] initWithBytes:bytes length:1];
  8.         for(CBService *aService in {
  9.             if([aService.UUID isEqual:uuidService]) {
  10.                 for(CBCharacteristic *aCharacteristic in aService.characteristics) {
  11.                     if([aCharacteristic.UUID isEqual:uuidChar]) {
  12.                         [self.peripheral writeValue:d forCharacteristic:aCharacteristic type:CBCharacteristicWriteWithResponse];
  13.                     }
  14.                 }
  15.             }
  16.         }
  18.     }

The above is called whenever data is received by the app- eg:

  1. peripheral:didUpdateValueForCharacteristic:error:

When it is all working, it’s really fun to interact with the robot in this way!

ble_buddy_wip 002

There are still some wonky things that happen. For example, if you send too much data- or if you send it at the same time. Sometimes we don’t even know what we did and it will just disconnect (though thanks to our code, it re-connects quickly and without interrupting the user). This happens infrequently, so it might be odd cases.

Special thanks to @macisv, who at SecondConf last year taught me lots about BLE and let me experiment with it! And of course @sectorfej for making this great module that we used :)

Now for the hard part: completing and releasing it. It’s kind of weird, even though we are using this quite often… we have kind of come to dislike this interaction (of pressing and holding buttons) because it’s quite boring. So we’re not sure yet if this one will be finished, or if we’ll be trying something else, perhaps with more gestures and such.

ble_buddy_wip 001

More fun coding ahead! 😀