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