Greetings!

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.


USD


CAD

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

All posts tagged Arduino

Promulgate

promulgate_icon

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 RoboBrrd.com/promulgate. 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!

patreon_robotgrrl_800

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

IMG_7286

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.

promulgate_demo_1

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

promulgate_demo_5

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.

promulgate_demo_2

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.

promulgate_demo_3

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.

promulgate_demo_4

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.


Next

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.

patreon_robotgrrl_800

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.



Other

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!

Progress Update: Nintendo DS + 3DP Game Controller

3dp_game_controller_pkmn_2

The goal of this hack is to make an interface to the Nintendo DS. We use Caleb Kraft‘s 3D printed game controller pieces (D-Pad, 4 Buttons) for the interface.

Been working on this for a little while now, and finally hit a milestone with it.

Here is a progress update video!

Took a while to figure out how the buttons on the DS worked. Finally figured it out, and use a level shifter to trigger the buttons from the Arduino. The Arduino is also checking the button presses from the external 3D printed controllers, then sends the corresponding press to the DS.

I want to document this very well so that other people can do this too. Been taking lots of photos throughout. Caleb Kraft’s talk at the Open Hardware Summit was really eye-opening, and I think it’s cool how the ‘copy & paste’ empowerment can have such a huge effect on people that really need it. Games are fun, and everyone should be able to play them. Why should physical ability prohibit what happens in the gaming worlds? So unfair.

Will also be trying out a speech recognition interface, wonder how well it will work. If you have any other crazy ideas for interfaces, let me know.