A short presentation and demonstration of a robot I made at MLOC.JS 2013.

2. Solving the robot problem
• I want to build a robot
• I love coding
• I want pro gear
– servos
– motors
– accelerometers
– GPS
– etc
• I want it on the web
• I want it now

3. So, this robot…
• has physical devices that attach simply
• is running a software framework that
– talks to those physical devices
– exposes their properties to the web
– responds to user input from the web in as close to
real time as possible
– can express a degree of autonomy
– is fast to develop in

4. But isn’t JavaScript a terrible language
to build robots with?
• JavaScript has bad timers
• Very slow and memory inefficient compared
to close-to-the-metal languages like C/C++
• All the C/Java guys I know are like, "What the
hell are you doing? Are you crazy?"

5. Those guys don’t know everything
• We have modern, low wattage RISC based ARM
processors
• We have modern interpreters (i.e. V8) that are
very good at optimising our code at run time
• Writing device drivers in C/C++ is a total chore for
most people
• We can buy off the shelf components that can do
our time critical
• It’s not the 90s!

6. What do we gain by using JavaScript?
• It makes a lot of high level tasks very easy
• These days it can do way cool stuff
• Big community FTW

7. Who’s crazy now?

8. What currently exists for JS robotics?
• The original talk:
http://www.slideshare.net/nonken/robotic-javascript
• Nodecopter (nodecopter.com)
• Nodeserial (@voodootikigod)
• Firmata (Julian Gautier)
• Johnny 5 (Rick Waldron)

9. What do they do for us?
• Nodecopter helps us talk to a proprietary
helicopter drone
• Nodeserial helps us talk to the serial port
• Firmata helps us talk with an Arduino
• Johnny5 helps us control that Arduino with JS

10. What’s the ideal architecture?

11. What’s the ideal architecture?
• We want a familiar interface
• Web pages are good
• Something REST-like would be ideal
• Express helps
• BackboneIO (Backbone over WebSockets)
• State machine representation of physical devices
• Adding a new physical device should be as simple
as plugging it in

12. What’s the ideal architecture?
• Model-Collection-Controller/Model-View-
Collection
• Discrete physical devices are represented as
discrete models in memory on server
• Models bound to device change events
• Controllers talk to client via WebSockets
• Robot's canonical state kept on server, allows
autonomous behaviour

13. Step up Raspberry Pi
• Modern ARM based SOC
• Low power
• Runs Linux
• Loads of storage space
• USB 2.0
• Bonus onboard graphics processor

14. Add some clever USB devices
• Wifi
• Pololu
– serial comms using serialport
• Phidget
– http/serial bridge using phigetapi

15. Add Node.JS and the SPD framework
• Listens on local TCP/IP network
• Serves up dynamic web pages
• Uses Backbone API
• Automagically builds models on client
• Changes in remote hardware bound directly to
client-side events
• Looks to all the world exactly like a web site
• We don’t even have to care about transport

16. Robot is online

17. Give me that checklist
• It’s got servos
• It’s got motors
• It’s got GPS
• It’s got accelerometers
• It’s got Arduino (should you really need non-USB based
sensor arrays)
• It communicates with the web in real time
It’s going to get a lot more
• Real time streaming HD video
• Kinect vision
• Firmata?

18. Enough talk
• Drive the car around the stage
• Get my Google Map on
• Detect a crash
• Damn

19. Notes
Bibliography Shout outs
• Available on request • jashkenas
• voodootikigod
• RIAEvangelist
• visionmedia

20. WE’RE HIRING
WWW.YAMMER.COM/JOBS
@rayui