Coding4Fun Cannon – Project Overview
- Posted: Mar 16, 2010 at 11:20AM
- 7,644 views
- 7 comments
Loading user information from Channel 9
Something went wrong getting user information from Channel 9
Loading user information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
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:
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
Mid-February, we were asked to build a t-shirt shooting robot for the Mix conference on March 15th, 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.
The work was broken up into logical sections:
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.
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.
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 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:
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.
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.
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 became:
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:
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.
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.