Coding4Fun Cannon – Project Overview

I think the best way I can describe this project is by telling the story of how I got into this. While playing a bit of xbox 360 at 7:52 p.m., I see a legendary email come in:

Clint,

Scott Guthrie would really like to have a cannon on stage at MIX this year that would allow him to fire t-shirts into the audience.  […]  We thought it might be something that you could build based on the fun stuff you’ve done in the past. […] Do you think you could build something like that?  Do you have the time to work on this for MIX?

So the Coding4Fun team had two weeks to build two robots able to drive, aim, and shoot t-shirts during a MIX10 Keynote demo of unreleased software? Piece of cake.

The following info will explain the who, what, why, and how of the project in order to help you understand the project’s layout.

Picture by Vetala Hawkins - Filmateria Digital

In this multipart article series, we’ll cover:

1. Project overview
2. Developing the phone application
3. Building the robot
4. Creating the phone user experience

Say hello to my little friend

Mid-February, we were asked to build a t-shirt shooting robot for the Mix conference on March 15^th, 2010. This required us to pitch our vision and then research, build, test, and ship our project—all in about 3 weeks. After Scott Guthrie gave us approval based on our SketchFlow demo, we had to divide and conquer the application with only 2 weeks left to build the physical robot, the server software, and the phone software. And on top of all that, since we were consuming an unfinished product, everything had to have backup plans.

Delegating workloads

The work was broken up into logical sections:

• Server and Robot (Codenamed: Betty)
  • Clint Rutkas handled this part
• Phone (Codenamed: Frank)
  • Dan Fernandez worked on this
• The phone user interface
  • Web design company, 352 Media created the look/feel for us
• Camera / MJPEG stream
  • Brian Peek updated his code so it would work on pretty much any platform

But wait, if we had a super-secret project, how did Brian and 352 work on it? We told them they were working on Silverlight out of browser applications! We didn’t tell them it was for the phone! We’re sneaky like that.

Frank and Betty sitting in a tree …

So why did we use code names? Dan and I got a bit confused when referring to certain item ownerships and the codenames allowed us to chat about the project in non-secured areas so it just sounded like we were gossiping about two people, albeit in extremely nerdy conversations and extremely nerdy tones. If memory serves, I wanted to name the robot Frank after the character Frank the Take from the movie Old School, but Dan had for some reason already jokingly referred to the robot as Betty and so the flip-flopped names stuck. During development, Betty and Frank fought and had some communication issues—just like a real couple. You may see references to Frank and Betty in the source code or throughout the series of articles on this project. Just remember, Frank is the phone and Betty is the Robot.

Design decisions

At a conference like Mix or PDC, thousands of people cram into a single room, creating a massive amount of wireless interference. Keeping this in mind while considering the communications aspect of the project, we decided to have Betty make HTTP communication calls while physically wired into the network. This required us to have some type of web server on the robot. Given enough time, I’m pretty confident that I can get the entire robot working without having a computer onboard or being 100% phone powered but we had to be sure nothing would interfere with communication so wireless was out of the question.

Also, since this project was due in an extremely short period of time, a lot of component decisions were based on my past projects. We looked at network cameras that transmit H264, MPEG4, and MJPEG along with the idea of using live smooth streaming from the server onboard the robot. Basically, having a computer on Betty gave us more options in case something didn’t work.

Due to the time crunch, every part had to be either on-hand or off-the-shelf. Creating custom parts takes a lot of time. So basically, my rule was that if it couldn’t be shipped to me in two days, I’d find something different to accomplish the task at hand.

Throughout development, Dan and I met in a SCRUM meeting first thing every morning to figure out what we should get done that day and to discuss any issues that were occurring. Here is Dan’s whiteboard after one of the final meetings before we flew out to the conference:

Betty, you can be a real robot if you try

Betty had to do three tasks: drive, aim, and shoot t-shirts. We used an HP Envy 13” laptop to manage everything and here is the hardware list per task:

• Aiming:
  • Aiming was accomplished with the Servo City Pan-tilt and a Phidget advance servo controller.
• Shooting:
  • Shooting was accomplished with a Phidget 0/0/4 Relay controller, a drinktendr wiring board, and the t-shirt cannons.
• Driving:
  • Driving was made possible the battle-bot chassis by Robot Marketplace, which uses an Ampflow motor controller. This is the motor controller I used on my self-balancing skateboard project and I found out that it is actually a rebranded Roboteq motor controller. I highly recommend using the Roboteq software to configure and upgrade the firmware.

Here is the first time Scott got to drive the robot and fire off a few test shots at real-world pressure all via the phone.

Seriously, you built it in 2 weeks?

Yes, but we didn’t build just one. For redundancy, we had to build two Betty’s. If a part broke or something didn’t work, we had to be able to swap robots without anyone knowing. And for the record, I only had one very small electrical fire, which was due to a crossed wire. Having completed a few projects like this in the past, I knew what I’d get hung up and when I should ask for help. My experience completing previous projects also taught me which part vendors are the best.

The robot was under constant work and my desk / office was literally covered in wires and parts all the time. Since I had such little space, even the robots were covered in wires and parts! I cleaned up multiple times, but within an hour every square inch of space had some type of part on it.

Frank gets a tux for prom

Silverlight and WPF use XAML for the design aspect of the application. Since it allows for an extremely nice separation, XAML gives both the designer and developer great power in creating the application. Dan told the great folks at 352 Media what controls we were using and their Silverlight 3 final product was inserted directly for consumption with minimal change. In the User Experience and Phone articles in this series, we’ll go into more depth.

What it was:

What it became:

What is with the code?

Rather than risk breaking our code, we’re showing you the keynote rev in all its glory. Dan and I know we have some cleanup to do. We are the first to admit this. We were dogfooding the Silverlight on the Phone and issues of course came up. Due to this, our code may look a bit interesting in a few places.

For communication, you’ll notice some of the code looks like it is a WCF (Windows Communication Foundation) service, and this is because it was at some point. We liked the idea behind WCF since it allowed us to lock down the service and prevent someone from sending in outside commands. This also allowed us to create very segregated services that only dealt with the service we wanted. Aim, Drive, Settings, and Shooting each had their own and if we wanted to add in another, it was extremely simple.

But as we got to a point where we were giving the phone tools, we had issues getting it to work and so we had to adapt. We shifted to a simple web project and sent in commands. Rather than refactor stuff, since we thought stuff may be fixed in later builds, we consumed the project as a reference and treated our services as classes. We never did go back and check

The key projects are:

• Coding4Fun.Cannon.Phone
  • The phone application
• Coding4Fun.Cannon.Robot
  • Handles all direct hardware communications
• Coding4Fun.Cannon.WCF
  • This will be abstracted out to a new, non-WCF project. It creates a simplified command from the Phone and the web server. A quick example of this abstraction is with the servo code. The servos expect a certain value that isn’t an angle. With this abstraction, the phone can send in an angle and the servos then can do the translation into a value that is meaningful.
    Another big thing that needs to be added in to this namespace is capturing and sending back the photos off the web server. Right now, this logic is all contained in Coding4Fun.Cannon.Web.
• Coding4Fun.Cannon.Web
  • Handles all requests from the phone, it is basic ASP.Net website.
• Coding4Fun.Cannon.MVC
  • In case you want routes instead of query string parameters

Fins make a car go faster, right?

Building this application, we figured out some ways make our application to act faster. We also built out some cool utilities we found very useful in our application, we’ll be abstracting these out into a tool chest project shortly. We will discuss these performance solutions later on in the series.

Conclusion

I hope everyone enjoyed the project and is ready for a more in-depth look on how it was accomplished. This was a fun and exciting project that pushed us by the short deadline and complexity. If you have any questions, please post a comment and we will be sure to address them in the future articles.