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 Projects



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. :D 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!

Nutrition Monitor for the Elderly


This is a nutrition monitor for the elderly. It calculates a malnutrition score based off of body mass index and the daily food intake. The score is then uploaded to a remote dashboard that a guardian can view, and be alerted if it exceeds a threshold.

With the nutrition monitor, a problem can be addressed in a few days, rather than many months.

It is a step in the direction of being able to be more aware of ourselves by using sensors placed in our homes.

Watch it in action:

You can get started making this yourself! Check out the Instructable, NutriModule Arduino library, example Arduino sketch, and the Processing sketch.

MAKE Connected Home Contest

I entered this project into the MAKE Connected Home Internet of Things contest. The prize was a $500 gift certificate at the Maker Shed. We won! Read the article here.


Thank you to everyone who watched the video, commented and shared it with friends, and to the MAKE staff.

It was quite a shock to get a call from Stett at MAKE on Friday evening saying that the Nutrition Monitor won! (My hands were shaking well into Saturday morning.) I will never forget this!

Right now, I’m considering the Printrbot Jr V2. After there are some more purchases in the RoboBrrd Store, we can probably get it!


Just as some background, I saw a tweet about the contest, and noticed that the deadline was really quick. If you read this blog frequently, you might have realised finishing a project very quickly is a struggle for me.

Knowing a gist of what I wanted to make, I researched around about malnutrition. On Sunday (Feb. 2), I dived more into it and learned all about it. There were two references in particular that helped:

Nutrition Support for Adults (accessed Feb. 2, 2014)
Malnutrition Universal Screening Tool (accessed Feb. 2, 2014)

Monday (Feb. 3) it was time to start building. I finished the Arduino library before the hardware was done, then finished the hardware, and created the application plus the remote dashboard. The reason why it’s so tricky to make IoT projects is because of the numerous ‘components’ that have to talk with each other. There are many points of failure. I really lucked out that I didn’t hit many snags.


The one snag I hit was with the conductive foam in the DIY force sensitive resistors not un-compressing fast enough. Instead of the weight being recorded after it automatically detects removal/putting back of the food on the module, a button is pressed instead. The sensors are still a little glitchy, however they can be improved.

Reading the feedback from comments, with some heads nodding thinking it’s an interesting idea, is very motivating. This project is only the first try at the idea. With the future modifications in mind, it will get better.

Future Modifications

- Adding wireless radios to broadcast the data to the internet
This way, there will be no computer needed (except to access the remote dashboard).

- Improving the weight sensors
The conductive foam is very DIY, and this can be done much better to result in more accuracy and reliability.

- Shape detecting mat
Instead of modules, have one ‘mat’ (or plate), that can detect the shapes of many foods placed on it. And detect the weight within that shape area. It will be easier to clean than individual modules.

- Better remote dashboard
Currently the BMI is hard-coded into the desktop application. This should be able to be input via the remote dashboard. Also, ensuring privacy and security of the data is important to be improved.

There are also other interesting ideas suggested, to increase battery life, when to send the data, and maybe switching the place of the module (on the food, instead of the food going onto the module).

One of the obstacles will be the elderly using it / not dismantling it. They may still believe they do not need help, or they may believe it is a spy device by the CIA.

It would be great to run a beta test with some of the future prototypes. I wonder what the feedback would be?

Our future will be full of connected devices. It will be so interesting to have everything synced, communicating with each other, and helping our lives.

Now, I am looking for people who are experienced with health/medical/connected devices. If you know of anyone (or are someone), please email me!

Also, if you are interested in potentially beta testing this (or know of someone who would be able to beta test it), let me know.

Until next time, make something weird or connected, maybe both- weirdly connected!