Developer Spotlight: How we made BattleBots

This post is the last in a three-part series covering the IoT projects that came out of our first internal hackathon of the year, and that we had on display at our first Integration of Things Zone at CONNECT 2015. Missed us there? Don’t fret, not only will you get a sense of the cool installations we built by reading the piece below, but we also share some of the code and tips that went into making them a reality. For now, step into the ring and see how we let people control Darwin Mini robots via an iPad, a Moto 360 smartwatch and even the good old internet to make them do handstands, the horse dance, as well as kick miniature footballs around.


came out of our internal IoT hackathon earlier this month and actually took the first prize. As we’re fond of saying here at MuleSoft, IoT is not just the Internet of Things but truly the Integration of Things, where exciting opportunities emerge when you integrate physical things like a robot to make them communicate with business applications like Salesforce.

I’m lucky enough to be writing up this piece on the blog, but none of this would have been possible without the team behind BattleBots, which was composed of the following engineers from our Buenos Aires office: Martin Cousido, Juan Desimoni, Pablo Cabrera, Sebastian Sampaoli and Esteban Wasinger.


BattleBots - Robots

The idea behind BattleBots was to take Darwin Mini robots that typically play football/soccer and make them do more things using novel interfaces. We also wanted to show that with Mule, integrating things, including robots, can be really easy work.

Connectivity, connectivity, connectivity

When we started working on this project for the hackathon, we all knew the key consideration was to build the connectivity layer with the robot–if we could not send messages to these things, all the rest of the work was going to be useless. With this important thought in our minds, we built an open API over the robots, letting connect, with Java code, and send messages and movements, but that was not everything, we wanted to go further.

Within the Mule ecosystem we’re lucky to have plenty of connectors, which makes life a bit easier via components that comply with the mule lifecycle, and that are reusable and also shareable. If we could write a Java API for the robot, why not develop it into an Anypoint Connector? That’s what we did using Anypoint Connector DevKit, which let us to create, in a few easy steps, a component that integrates perfectly in design time with Anypoint Studio and in runtime with Mule ESB.

Project Architecture

BattleBots - Architecture

The architecture of the project is quite simple, it’s a hybrid architecture, where there are 4 actors:

    1. Interfaces–for this project we did not want to limit our data input to a unique source, but have the robots be able to receive information from any possible service or source. At , we demonstrated two of them, a web console and a Moto 360 which had support for voice recognition.
    1. CloudHub was a key actor in the entire system, with two big responsibilities, 1.) it was in charge of the orchestration of the messages and movements exposing our REST API to receive messages from the interfaces, processing them and sending them to the on premise Mule ESB; and 2.) managing the player queue system that we built for CONNECT, where we let any attendee take turns playing with each robot.
    1. Mule ESB on premise had to retrieve the movements orchestrated by the API hosted on CloudHub, process those movements and send them to the robots via the Anypoint Darwin Connector.

  1. Robots, what would we do without fancy robots? These were waiting in for messages to be received via Bluetooth to do the hard work of moving and dancing all day long, obeying the orders of our CONNECT visitors

Why CloudHub + ESB on prem?BattleBots - Robots 2

Implementing a hybrid architecture gave us a more natural way to communicate between the interfaces and the robots, having a unique endpoint in the cloud where create and consume movements, easing the creation of new interfaces, just implementing the REST API, and consuming the messages, because the robots can be anywhere in the world.

An example of this was when the project was presented to the judges in the hackathon event, and we let our judges, who were sitting in San Francisco, control the robots that were in Buenos Aires in real time!

Project Sources

We'd love to hear your opinion on this post

One Response to “Developer Spotlight: How we made BattleBots”

  1. Indeed, making the BattleBots dance when a new SalesForce Opportunity was detected would have been quite easy using the MuleSoft ecosystem.

    Thanks for the code. The Android app is amazingly simple.