A short time ago, in a digital agency not too far away, experiments have been underway as we continue our voyage into the vast cosmos of physical programming. In our first instalment, 'An Internet of Things Thing', we told tales of blinking lights and Arduino boards as we took our first steps on this adventure. We've learnt much along the way and would like to share with you more of our findings on this mission to build, what we like to call, robots.
As we all remember, the droids of Star Wars were more than a few flimsy wires and flashing lights -- they were fully dynamic moving machines capable of computing complex patterns, not to mention the smattering of emotion and hint of free-will -- but let's not get ahead of ourselves. In this article we will begin to look at the trait of movement, as we move on from flashing LEDs and start to build our first robotic arm.
Building our 'robot'
Our rudimentary arm comes in the form of a servo motor. A servo motor differs from your average motor in that it doesn't simply spin with voltage. It actually receives two voltages -- one constant, to power its movement and another, Pulse Width Modulation, to act as a feedback, controlling the angle. This basically means that we can predefine positions for the motor to spin to, where it will hold until given further instruction. This is starting to sound more robotic already!
The above setup is simple and highly rewarding, but here our mission was to create proof of concept that would allow these physical actions to be controlled remotely, so that anyone with internet access, no matter where their location, can take control. The difficulty we have here is that the Arduino must be connected via serial port, which is not accessible over the internet. This meant that remotely communicating with our robot would require some creative thinking...
The solution was to set up a local machine running a Node.js server with serial port access and another, remotely hosted instance running a web application that would issue commands to the Arduino. With these environments setup, we then required a service to communicate between the two. For this we chose to use the online serviceCosm.
Cosm offers a specialist solution for real-time data flow with a core message of encouraging communication between physical devices and real-world data sources, enabling a network of 'things'. A custom web service could be another approach, but the ethos and simplicity of Cosm make it an attractive solution.
The Cosm API allowed for the push and pull of JSON data to synchronise our feeds and also provided a web socket abstraction in the form of data streams. These data streams act as the communication link between our two environments, allowing our 'Droid Control Facility' to issue its directives to the robotic slave over the internet; in our case, switching lights on and off and controlling our robotic arm position.
This application, despite its simple nature, has got us thinking about how we can use the web to interact with the world around us in a more fundamental way. Admittedly, we have a long way to go before we can remotely command a galactic droid army, however, engaging with this project has raised some interesting questions. Can these experiments move beyond superficial, indulgent play and solve real world problems for clients or community?
Our lives are increasingly becoming connected in ways that transcend our rooted physicality -- the 'cyber city' is rapidly being built around us and swiftly moving towards the everyday. This reality is being exploited to great effect by the bigger players in the digital realm, from Google Maps to Foursquare, as the 'things' we engage with gain a digital self of their own.
We believe there is abundant scope in the realm of kiosk and point-of-sale installations to bring a little physical 'wonder' to a world that is increasingly being lived out through the screen.