« swipe left for tags/categories
swipe right to go back »
The open data movement is great for business, but is also great for us as citizens. To accelerate that program, President Obama and US CTO Todd Park have created a national event to leverage technology and open data to strengthen our democracy in the United States.
On June 1st and 2nd the largest hackathon in the world is forming. Over 5000 people in 87 locations will be joining up to use their talents to make their communities a better place. The National Day of Civic Hacking is the first of a yearly event created by the White House to gather Citizen Engineers and have them use newly accessible government data to improve their communities and our entire society. The multitude of data that is being released as part of the Open Data Initiatives.
A company I’ve been involved for a long time with – Rally Software – is taking a leadership role in this. Rally’s product development team is devoting their talent and energy to participate and host the Boulder, Denver, Seattle, and Raleigh event (join up at these locations.) Through their corporate social responsibility initiative, Rally for Impact they are offering an exclusive and complimentary one-year subscription to AgileZen and Flowdock to all participants of the National Day of Civic Hacking.
Specifically for Coloradans, there are sites in Denver and Boulder. In Denver, the site is focused on open data from the State of Colorado and called Hack4Colorado. In Boulder, the Boulder Civic Hackfest, is focused on local data, the Census Bureau and the National Renewable Energy Lab’s Open Energy Info project. On Saturday, NREL engineers will join the local civic hackers too. Hacking isn’t just about writing code, it’s about exploring the boundaries of what’s doable and what’s desirable.
Rally is also donating three seats to their Enterprise Lean Startup training course to this effort. This highly interactive workshop, on June 5 & 6 in Boulder, teaches you how to systematically discover what’s desirable for users and customers. To claim the training seats be the first three people to send email to firstname.lastname@example.org if you are attending the event in Boulder or Denver. Awards will be given at the closing of each event in Boulder and Denver by Rally staff.
I’m proud of my long time friends at Rally for providing leadership here!
Last week President Obama played with a Sphero. This weekend you can win up to $5,000 at the Sphero Hackathon in Boulder. It starts Friday May 4th at 6pm with a Welcome Reception (which means beer and Spheros) and runs all day Saturday and Sunday where you can hack with Spheros and the Orbotix SDK. I’ll be around Sunday from 1pm to 3pm taking a look at what people have done, playing around with the apps, and answering any questions about why I think Sphero (and Orbotix – the company that makes Sphero) is so awesome.
Two new apps have recently come out for the Sphero. The first, Chromo, allows you to play with Sphero in a whole new way. While Orbotix’s other apps allow you to control Sphero from your device (kinetically and via a digital joystick), now Sphero is the controller. The video tells the story better than words.
The other app is MacroLab. Did you have a Big Trak as a kid? If not, you missed out, but you can relive those missed moments with MacroLab. As before, let’s start with a quick video.
MacroLab is a tool Orbotix developed for internal purposes that turned out to be so powerful they decided to make it available to all Sphero users. It is essentially a high level abstraction of the API that runs in the ball’s memory that commands the robot. It makes the API accessible to people who don’t know how to program an iOS or Android app.
When a user creates a macro they send a series of commands to the ball. Macros are made by stringing together 27 basic commands (by comparison the SDK has about 300 commands – most are UI/robot housekeeping based but 100 are ball control related). Each command is executed in sequence. Following is an example (called “test”) along with an explanation.
- Calibrate – this zeros out Sphero’s heading so you know which way he will go after you aim him
- RGB – this changes the color of the LED to purple – the numbers are the RGB settings
- Roll 0.5 0 0 – 50% speed (0.5), 0º heading = straight ahead, 0 second wait time before executing next command
If we stopped here the LED will flash purple and Sphero would run away at 50% speed and only stop when you exit the macro. Basically the macro runs for a fraction of a second with an open ended roll command. The Sphero goes white (his default color) after the macro is run. In order to not have an open ended command we need to add some more stuff.
- Delay 5000 – this means to wait for 5 seconds, Sphero uses milliseconds so 5000ms = 5 seconds
- Roll 0.0 0 0 – 0% speed (0.0), 0º heading, 0 second delay
- RGB – change LED color to orange
- Delay 1000 – Wait for 1 second
The entire macro runs for 6 seconds. Sphero will turn purple, drive for 5 seconds at 50% speed, stop, turn orange for one second and then end by turning white.
The commands for MacroLab are very basic but powerful enough that Orbotix uses them to run tests on the factory line and form the basis of programs like “Draw N Drive” (every line you draw gets converted to a macro and the ball executes the command). The complete command list follows:
- Roll – sets the ball in motion
- RGB – changes the main LED color
- Calibrate – zeros heading
- Delay – wait time in ms before executing next command
- Fade – fade between two colors over a set period of time
- Back LED – turn the blue aiming LED on/off
- WaitUntilStop – don’t execute the next command until Sphero has stopped moving
- Rotate Over Time – turn xº in y seconds
- SD1, SD2 – global variables for system delays – useful when you want a bunch of commands to use the same delay
- SPD1, SPD2 – global variables for ball speeds – useful when you want a bunch of roll commands all at the same speed
- Roll SD1, SPD1 – roll command that uses the system SD1 for delay and SPD1 for speed
- Roll SD1, SPD2 – roll command that uses the SD1 for delay and SPD2 for speed
- RGB SD2 – change LED to RGB setting but use SD2 delay time for duration
- Rotate Over TIme SD1, SD2 – rotate over time command but uses the system delays SD1 and SD2 respectively
- Goto – calls another macro or restarts the same macro
- Rotation Rate – set how fast the ball can turn
- Stabilization – turns the control system on and off -when off the robot will not move inside the ball
- Raw Motor – command the motors without any control system enabled
- EMIT – Displays a message on the phone when the ball hits that point in the macro – useful for debugging
- Sleep – Puts Sphero to sleep
- Loop For, End – Create loops within the macro
- Comment – ability to add comments to your macros – no effect on the ball
When I first heard the idea for MacroLab I smiled a huge smile. It’s the beginning of Orbotix opening up their robot control language, which is part of the magic behind the premise for our investment in Orbotix. I’m amused when people say “why did you invest in a toy ball company?” when what we really invested in was a bunch of geniuses working on a robotic operating system that happens to start life out as a robot ball that you control with your smartphone.
Orbotix is the gang that is “reinventing the ball” while also creating smartphone apps that control robots. The November Hackathon is all about hacking Android apps and there will be a contest that I’ll be judging on Sunday afternoon along with Paul Berberian (Orbotix’s CEO) and Julian Farrior from Backflip Studios.
The Orbotix guys understand that beer and pizza are required at a two day hackathon and there will be plenty of it. If you are interested, all you need to bring is your Android phone and computer (with Eclipse and the Android SDK) – Orbotix will supply everything else.
If interested, contact Adam (adam [at] orbotix [dot] com).
Over the years, a number of companies I’ve been an investor in have had hackathons. These are typically day long events where everyone in the company works on whatever cool new ideas they have. On Monday night I got a note from a company I’m on the board of about a hackthon they just completed. As I looked through the list of things that the various teams created, I got chills of excitement.
Most of the companies we invest in release software at least once a month. Some release weekly, or even daily. I’ve become a big advocate of true Agile development (partly because of my experience with Rally Software – the leader in Agile software development environments) and – more recently – the notion of trying to get to continuous deployment which has been popularized by Eric Ries.
If you are releasing at least monthly, it’s easy to do a full day hackathon at least once a quarter. And, rather than have it be an “engineering thing”, you can (and should) make it a full company thing. Here’s how:
- Pick a date during the quarter for the hackathon. Mondays and Thursdays are best.
- Designate one person in charge of managing the hackathon. This person has a budget for food and prizes and is encouraged to do whatever they want to publicize it throughout the company (easy for 10 people, not so easy for 1000 people). The goal is to engage 100% of the company in the hackathon.
- Form teams. The teams should be between two and five people. The teams should be self-selecting. The Hackathon manager should come up with an easy way to manage the team list (hint – wiki). Each team should have a name and, in advance of the hackathon, should spent at least one meal together talking about what they are going to work on. People should be encouraged to work with folks they’ve never done anything with before, although this shouldn’t be a requirement.
- The hackathon starts at 12:01am and ends at 5pm. Whatever is done, is done. Demos and awards start at 5:30pm. Food is included. The hackathon manager is responsible for coordinating all of this, including the mechanism for judging.
In the best hackathons, there is a wiki that is very dynamic during the hackathon. This way all of the activity is captured and can be reviewed afterwards. The goal is not to include everything from the hackathon in future releases; rather it’s to stimulate a bunch of ideas, generate some prototypes, end up with some useful code, but get everyone in the company thinking about all the products.
Not all of the hackathon projects need to be about code. I’ve seen things like help systems, new web sites, better customer support processes, better management of social media activity, and lots of business process stuff created and implemented during hackathons.
After the hackathon is over, publicize what you’ve done to the world. FeedBurner used to do a great job of this with a simple blog post that highlighted every project and the teams that worked on them.
Oh – and don’t forget to invite your board members. If I can make it, I’ll always spend a day at a hackathon. It’s one of the best ways for me to really engage in and help out the companies I’m involved in. Plus it’s a blast.