Internet, Otis. Otis, Internet. Now that the introductions have been made, let me tell you the story of how FourSquare helped me find Otis the goat.

In September of 2010, I went on a vacation in Vermont which involved driving around the state looking for cool places to visit. While in Montpelier, I stopped at the Morse Farm because it was on a travel guide as a good place to get maple syrup products. As I had been doing, I checked in to FourSquare when I arrived at Morse Farm and saw the following:

I wasn’t quite sure what to make of this tip. At first I thought it was just a goof, but I asked the store clerk and sure enough there was a goat out back. I discovered a neat wood enclosure with a staircase for the goat to climb. At the top of the staircase was a pulley system which had an empty syrup container cut in half attached to it:

I know, you’re thinking ‘who cares?! it’s a stupid goat!’. But, you haven’t seen Otis’ trick yet! Behold:

Thank you FourSquare for helping me find Otis the goat and thanks Geoff for leaving the best FourSquare tip ever.

If you have read any technology blog in the past few months, chances are good that you have seen an ever increasing number of blog posts about people hacking their Xbox Kinect to do all kinds of really cool stuff. If you are like me, you found yourself thinking ‘I have got a really cool idea to do ________ with my Kinect, I should see what this is all about!’. Problem is, there is no definitive entry point to developing software using the Kinect.

The goal of this blog post is to provide a general overview of the tools available and where you can go to get started. The information below represents my experiences on a Windows XP SP3 platform, using Visual Studio 2008 for an IDE. If you are looking for OS X or Linux help, sorry! Maybe some of the information will still be relevant. Let’s get started:

Why don’t I just use a USB camera?

There are two main advantages to using the Kinect:

• Depth sensor: the Kinect has a fancy pants IR depth sensor built in which is great for doing any kind of depth tracking and/or 3D stuff.
• Brains (if you use the OpenNI library with NITE middleware): One of my favorite things about working with the Kinect thus far is how quickly and easily you can write a neat application. Normally you would have to worry about lighting, background corrections and all kinds of other environmental parameters that aren’t much fun to deal with. First time out of the box, I had my Kinect tracking my movement in a room with zero lighting while it was facing a giant mirror with no complicated code. If you ask me, that’s impressive.

Choosing your development tools

There are currently two main development tools which you can use to work with the Kinect:

• OpenKinect (http://openkinect.org/)
• OpenNI + NITE (http://www.openni.org/)

Here is my general impression of the two given my extremely limited exposure time with these libraries:

OpenKinect is great if you want to access the raw data from the image sensors and write your own algorithms basically from scratch. With OpenKinect you can drive the Kinect motors and access the data streams coming from the image sensors. There are also four microphones on the Kinect, but as far as I know the OpenKinect driver doesn’t support data acquisition from them (yet).

OpenNI + NITE is great if you want to hit the ground running and do not really care too much about the internals of the provided tools. OpenNI has an advantage as of this writing, because Prime Sense has given developers free access to some functions which have not currently been developed in OpenKinect. For example, OpenNI works with the NITE tools which provide skeletal information and hand, gesture and joint tracking. If you want to do these things with OpenKinect right now, you will have to implement them yourself. Here is how I understand the OpenNI + NITE toolset to work (I’ve put this together from my limited experience with the code, so it’s quite possibly wrong):

I am sure I have oversimplified, as there are also potential licensing issues to discuss, but the 10,000 foot view will have to suffice for now. At this point I will assume you have chosen a tool set (or plan to test both), so let us move on.

The USB Device Driver

The first thing you are going to need is a USB Device Driver. Without one, all you will see is an unrecognized device that you system cannot communicate with. As of this writing, there are two device drivers, each one specific to the programming tools that you would like to use:

• OpenKinect (http://openkinect.org/wiki/Getting_Started_Windows). The Wiki is pretty well detailed, so I’ll leave it at that.
• OpenNI/NITE (http://www.openni.org/downloadfiles/30-openni-compliant-hardware-binaries). This route is a little more complicated right now, mainly due to lack of comprehensive documentation (or maybe I just didn’t RTFM).  You’re going to need the following files: OpenNI device driver, OpenNI binaries, NITE device driver, NITE binaries. The specific files that I used are named: OpenNI-Bin-Win32-v1.0.0.25.EXE Sensor-Bin-Win32-v5.0.0.25 .exe, SensorKinect-Win32-5.0.0.exe, NITE-Bin-Win32-v1.3.0.18.exe

That’s it. Once you have your favorite toolset downloaded and installed, you should see the Kinect listed in your Windows device manager. If you get that far, you can poke around in the demos folders to get a feel for what you can do.

OpenFrameworks

As a quick aside, I recommend checking out OpenFrameworks forums. There are quite a few people who have been working on OpenFrameworks extensions for both OpenKinect and OpenNI/NITE. The code I’ve been working on started out as an OpenFrameworks OpenNI/NITE project that someone posted there. This is a good place to poke around if you want to see a collection of OpenFrameworks demos:

http://www.openframeworks.cc/forum/viewtopic.php?f=10&t=5125&hilit=kinect+driver

The Project

So all this information is great, but what can you do with these tools? Here’s what I cooked up: a combination Lynxmotion robot arm controller and 2D live motion ‘puppeteer’ demo. Before getting into a project, I would suggest poking around in the ‘demos’ folders included with both OpenNI and OpenKinect. This will give you a rough idea of where to start (at least it did for me). If you’re using OpenNI + NITE, playing with the demos is also going to teach you that most of the useful data requires users to perform what is called a calibration pose. I didn’t find this pose documented anywhere officially, but a bit of Googling revealed it to be be a pose where the user holds both arms at right angles up from the torso and also the arms bends up at the elbows (think of Beavis and Butthead). It looks something like this:

After starting the software and performing the calibration pose, the NITE middleware starts providing X,Y,Z coordinates for all of the user joints (head, hands, elbows, shoulders, torso, hips, knees and feet). I’m sure it does many other sophisticated things, but that was all the information I needed for my demo program.

After a bit of a refresher course on basic geometry, I had a simple system working to determine the angles between various body parts based on joint coordinates. After that point, all it took was a few calls to OpenFrameworks/OpenGL functions to rotate robot bodyparts and send signals to the Lynxmotion arm over a serial port. Here’s the end result:

This project was also on display at the 2011 Scripps Florida Science Education Saturday at the Gardens Mall in Palm Beach, as seen in this video:

The Code

I have uploaded the code used for this demo (minus the robot graphics which were purchased from a stock art site) and it can be downloaded in a ZIP file here (~32 MB):
http://www.jiggywatts.com/files/projects/Kinect/ofxONI_notYetAddon_sampleROBOT.zip

The End

Thanks for reading this blog post, I hope it has been helpful! If you found any technical errors, please contact me (@Kabong on Twitter) so I can correct them. Happy hacking!

As a bonus, here are some slides from a presentation I made about this project at the totally awesome, first ever South Florida Hack & Tell (http://hackandtell.org/):

This project represented a few interesting challenges, primarily including:

• How to integrate a temporal dimension to the analysis while providing real-time feedback. The video analysis would be useless if analysis took so long that the robot arm could not respond in time.
• How to mathematically describe movement of an air hockey puck and then use those descriptors to predict future movement.

Solution
After a bit of testing, it was determined that mounting the USB webcam at a height of 4 feet 8 inches above the table provided an ample field of view for video capture and analysis. The two images below demonstrate what the air hockey table looked like from the camera’s perspective.

With the camera and robot arm mounted to the table, it was time to develop the algorithms. The final program worked by initializing the camera and taking a reference frame of the air hockey table (seen to the left). After capturing the reference frame, the program would enter a loop and retrieve every 7th frame in the video frame. Image subtraction was used to compare the newly acquired frame against the reference frame. The resulting image would show only the air hockey puck (seen below), which was then used to determine object location. The loop used every 7th frame as a trade-off to allow the system to respond in time. Analyzing every frame provided greater accuracy, but was too computationally expensive and would not provide ample time for the robot arm to respond.

Once sufficient data was acquired, it was fed into the algorithm to calculate location and predict motion, seen below.

As previously mentioned, one of the major obstacles was the amount of time it took to process the video and perform the necessary calculations. The initial revision of the program took upwards of 3 seconds to go from image subtraction to arm movement. With a bit of tweaking and some help from MATLAB’s program profiler (seen below), that time was reduced by nearly half and allowed the system to be more responsive.

Ultimately, the system worked decently well and was capable of playing air hockey at a moderate speed, assuming that the puck did not bounce off the table walls within the camera’s field of view before reaching the arm. Within those boundaries, the arm was capable of defending the goal and returning the puck to the other end of the table.

A video of the system in action is below.

While in service at Motorola, the robot originally functioned as follows:

1. 1) Phones were loaded onto custom aluminum pallets which would hold them in place.
2. 2) The pallet would roll down a conveyor into the robot where it would be electromechanically locked into a fixed position.
3. 3) The robot end effector inside of the system would use a vacuum to pick up a barcoded label from a label printer, apply it to a cell phone and then inspect the application with a camera which was mounted on the end effector.
4. 4) The pallet would be released, roll down to the next station and the process would be repeated.

The project broke down into two main technical challenges:

• How to modify the robot end effector to pipette liquid instead of handle printed labels?
• How to reprogram the robot to work with modified pallets that now held microtiter plates instead of cell phones?

The end effector
The modification to the end effector involved a bit of rather clever engineering. The liquid to be dispensed would be gravity fed to the pipette tips via a reservoir which was mounted on the end effector. The reservoir was connected to a plastic block, seen below, which had four vertical holes drilled through it for liquid to flow through. Inside of each hole sat a metallic ball and in front of each hole was a coiled copper wire which was connected to the robot’s power source. When power was applied to the coil, a magnetic field would be created that would pull the metal ball up from the bottom of the hole, essentially unplugging it and allowing the gravity fed liquid to begin flowing. By controlling the length of time the coils were energized, we could control how much liquid was dispensed. When power was cut, the ball would fall back to the bottom of the hole, thereby plugging it and preventing any additional liquid from flowing.

Reprogramming
Unfortunately, when the robot was donated there was no accompanying documentation. After a bit of reverse engineering, we were able to work out how to reprogram the system with sample code left on the system’s embedded computer. This involved updating the GUI (seen below), setting proper parameters for the conveyors, and reprogramming the end effector to be at the correct coordinates in sync with the conveyor.

End effector coordinates were obtained by manually positioning the Hirata robot’s end effector using the control pendant. A palette would be run through the conveyor to the correct position at which time the end effector was moved to the pipetting locations within each microtiter plate and the X, Y, Z and W (end effector rotation) coordinates were recorded. These coordinates were then programmed into system memory using the Hirata HARL 3 compiler. Robot control pendant, Harl 3 coordinate editor, BASIC compilier and robot programming screens are seen below.

Ultimately, the system function as desired, as seen in the video below.

Dr. Peter Hodder donated a Zymark Twister II robot arm for the project, which was primarily used to move labware between various scientific instruments in the High Throughput Screening laboratory. After a bit of brainstorming, the team decided that the robot would be used as part of an interactive display and should be specifically configured so that someone with no knowledge of robotics would be able to walk up to the system and interact with it. As a tie-in to the grand opening ceremony, it was determined that the end result of the interaction would be the robot giving the user a test tube filled with candy.

This project involved a number a technical challenges which had to be addressed for it to work:

• How to modify the robot to handle test tubes filled with candy instead of microtiter plates?
• What control system should be used to interact with the robot?
• How do we program an out-of-warranty robot that we have no documentation for and which the vendor will not support?

These challenges were addressed as follows:

Gripper Modification

The main obstacle which was not related to any programming task was how to make a robot that is built for handling one type of object (microtiter plates) handle something else (test tubes). The fingers on the robot gripper were not thick enough to grasp the tubes when the gripper closed, so modifications were needed. A custom gripper was designed, fabricated,  installed and tested to ensure test tubes could be retrieved from storage points and delivered to the user without becoming stuck or dislodged in transit.

Control system
After considering a variety of control mechanisms and user interfaces, we settled upon the idea of using an accelerometer based remote control (Nintendo Wiimote) to control the robot in real time. Fortunately, Microsoft’s Coding4Fun (http://blogs.msdn.com/b/coding4fun/) blog had published a Wiimote managed library (http://wiimotelib.codeplex.com/) which simplified the task considerably.

Wiimote circuitry

The image below illustrates how Wiimote signals would be sent wirelessly via Bluetooth to a control computer running NI LabView, which would then process the input and send movement commands serially to the waiting robot.

Programming the system
As a second stroke of good luck, it turned out there was a National Instruments LabView interface available (http://decibel.ni.com/content/docs/DOC-1353) which made use of the Wiimote managed library. With all of this code in hand, the last remaining hurdles were to build the logic to handle control input in LabView and program the system to output robotic commands via RS232.

Initially without any supporting documentation, it was not clear how best to manage robot communications. As one final bit of good fortune, we happened upon a Journal of the Association for Laboratory Automation (JALA) article by David S. Pechter titled ‘Controlling a Twister II with VBA and the Zymark ZyRobot ICP‘ which described how to communicate with the Twister via the provided ActiveX library in Visual Basic (http://www.jalajournal.com/article/S1535-5535%2804%2900227-8/abstract). With the provided examples, we were able to build a similar control system in LabView.

After a bit of testing with the Wiimote and robot, a control scheme was chosen as seen in the image below. This would allow users to control the robot using either the accelerometer control in the Wiimote or the D-Pad.

With the Wiimote libraries in hand, the control scheme defined and robotic communication working, it was time to tackle the control logic. The resulting program is as seen in the block diagram below.

ScrippsBot LabView control block diagram (click to see full-size image on Flickr)

Over a two year span since it was first programmed, hundreds of people have had an opportunity to interact with the ScrippsBot. Happily, the system has worked quite well and has hopefully inspired a few future engineers and/or scientists!

ScrippsBot setup at the robotics booth

ScrippsBot in use

The line of people waiting to use ScrippsBot at the 2009 Scripps Florida Grand Opening

The first year it was on display (2009), ScrippsBot made the local newspaper:
http://www.palmbeachpost.com/localnews/content/local_news/epaper/2009/02/28/scripps_030109.html

The second year it was on display (2010), ScrippsBot made the local news!

And finally, a video of the ScrippsBot in action at the Education Outreach event in 2010 at the Gardens Mall.

This project came about as part of a Digital Image Processing class I took in the Spring of 2004. The course was taught by Dr. Oge Marques (Blog – Twitter) as part of the curriculum for the Computer Engineering degree I was pursuing. I mention this because Dr. Marques had an incredibly positive impact on my academic career by encouraging me to be creative, went out of his way to provide a fantastic environment to learn and has been a great teacher, mentor and friend.

The Project

Part of the coursework involved proposing an image processing project which would have to be implemented by the end of the course. For whatever reason, I thought it would be interesting to incorporate a robotic Lynxmotion (http://www.lynxmotion.com) arm into the image processing project. Mostly, this was just an excuse to buy a robot arm. It was decided the project would consist of a robot arm that could use a USB web camera to analyze objects in a fixed area on a table and then retrieve one of them based on user input.

The objects to be analyzed came from a Fisher-Price sorter box, you know the one you had as a kid where you would put the square piece of plastic in the top of the box and it would fall inside, or you would try to see if the star would fit into the triangular hole sideways or if there was some amount of force you could apply which would deform the plastic object just enough to slide through, which it never did.

The Solution

Once the project had been defined, it was time to design the software and start building the whole thing. MATLAB was used as the development environment (this also included the MATLAB Image Acquisition and Image Processing toolboxes). There were two main implementation challenges: (1) How to mathematically describe and identify an object based on the shape of the object and (2) How to determine object position relative to the robot arm and move the arm to retrieve the object.

The first of these challenges was tackled when Dr. Marques suggested using a MATLAB image processing library by Gonzalez and Woods (http://www.imageprocessingplace.com/) to calculate boundary signatures of an object. This involved taking an image frame and doing a bit of preprocessing as seen in the image below. Specifically, this included applying a threshold to binarize the image, removing spurious objects and then back-filling the remaining objects.

Once the image was cleaned up, the frame could be parsed by the signature library which would produce a data set representing the distance from the center of the object to the boundary. As you can see, the unique characteristic is the number of peaks in each graph which represent the number of corners an object had. The graph of the star has 5 peaks, square has 4, triangle has 3 and the circle has a flat graph (not pictured below). At this point, a horizontal line could be placed across the vertical midpoint of the graph and we can count how many times the graph’s line passes through that. Divide that number by two and you have the number of peaks (or # of corners).

At this point, it was not too difficult to differentiate between a red square or a blue circle for example, but the system still needed to know how to actually command the robot arm to retrieve the object. A few simple geometric calculations later and the solution was at hand as seen in the image below.

With all of that sorted out, a user could walk up to the system, input selection criteria (shape and/or color) and the MATLAB program would find the object of interest, calculate its location, send the robot movement commands to the arm over a serial port and retrieve the object.

The question is did it work? Yes, it worked brilliantly! You can see a video of the system in action on YouTube here:

In the summer of 2003, three enterprising individuals by the names of Rick Corbett, Jim Prestia and Pierre Baillargeon undertook a project of awesome proportions. You see, they wanted to graduate from college, yet before them stood a requirement to design and build senior project. It started innocently enough, with a dot matrix printer no one loved anymore.

It didn’t take long for the dot matrix printer to be stripped down, leaving only a stepper motor and drive system.

Great. We had a stepper motor with no documentation or drive circuitry. What do we do now?! Well, we hooked it up to an OOPic-R microcontroller, some transistors and a device that would display the signals being sent to the stepper motor.

Once the motion control circuitry and programming was established, we had to determine how to electro-mechanically blow air into and suck air out of a harmonica. One short trip to Sports Authority later and the solution was in hand. A pair of air pumps used to inflate inflatable mattresses would solve the problem, all we had to do was reverse the air hose attachment point on one of the pumps and we would have one pump to blow air and one to suck air. The two pumps and associated electronics were then unceremoniously stuffed into a metal box.

A custom mouthpiece was fabricated to direct the air at the optimal point in front of the harmonica and final assembly began. Pumps, microcontroller, control electronics, air solenoids, a control keypad and display LED were all connected and mounted onto a piece expertly painted plywood.

The final remaining item was to tie it all together with usable software. This was accomplished with a Windows application that came with two predefined songs and allowed users to load their own songs from a text file.

That’s all great, right? But did it work? It sure did!

The iMovie app is fairly intuitive to use. You can scroll left or right along the timeline of your movie, add media in the form of movies, pictures or music and edit transitions among other things. The biggest gotcha for me was figuring out how to trim videos within iMovie. When you are in edit mode, click on the timeline at the bottom of the movie to highlight that particular clip with an orange box then scroll to the beginning or end of the clip and you will see an vertical orange line with an orange circle at the top. Drag this circle in the direction you would like to trim the video and you will see the new individual clip and overall movie times displayed as you are dragging.

You can set a project theme by scrolling to the beginning of the movie timeline and clicking the sprocket icon. Your choice of themes will dictate how titles appear in the movie and make the theme music available.

To add titles, simply double click on a clip, choose a title style and then edit the text of the title as appropriate.

Transitions can be set by scrolling to the transition icon between two clips and double clicking the transition icon. The default transition settings are seen below.

When you are finished, simply return to the iMovie projects page and choose the export option where you will be asked what resolution you would like the movie saved in. When the exportation is completed, move the file off your phone with your transfer tool of choice and voila!

Overall, I’m quite impressed at both the quality of the video and the ease with which it was created. There are a few minor issues, some of which can be easily addressed in a future software update by Apple:

• Image stabilization – I’m not sure if there’s sufficient processing power onboard to solve this using software, but this is the true limit of videography on the iPhone

• There is currently no way to sort or filter media before adding it to your movie (unless I’ve missed something). When adding video clips, they were listed in descending order from their date and timestamp, while photos were listed in ascending order. If you have 600 photos on your phone and you want to add the newest ones, it’s a bit of scrolling. Oddly enough, audio is easily filtered by playlists, albums, artits and songs.

At the end of April this year, NASA announced a tweetup would be held at the Johnson Space Center in Houston, TX during the STS-132 mission. I had never been to JSC or to Texas for that matter, so it did not take much consideration to apply when registration was opened. Luckily enough, I received a confirmation email and soon had a flight booked.

A few days before heading to the Lone Star State, I was determined to watch the launch of Atlantis and headed to Cocoa Beach. Once again, NASA made it look easy as the Shuttle lifted off right on time:

Fast forward 5 days and 1,000 miles and it was time for the JSCTweetup.

The tweetup kicked off with a presentation by Astronaut Jeff Williams (@astro_jeff) about his experiences aboard the ISS, launching to space on the Shuttle vs. Soyuz and a presentation by Boeing engineer Talat Hussain about the Ku-Band antenna which is used on the ISS to communicate with mission controllers. Oh yea, and one of the three screens in the auditorium was showing a LIVE SPACEWALK during the whole thing! Awesome.

After the presentations concluded, we were transported from Space Center Houston to the Johnson Space Center. More specifically, to Shuttle Mission Control (!!). ISS Flight Director Ed Van Cise (@carbon_flight) spoke to our group and answered questions as we watched a spacewalk occurring on the big screens.

From Shuttle Mission Control, we walked to the historic Apollo Mission Control, where we were allowed inside to explore the room.

Photo Credit: NASA/James Blair

From Apollo Mission Control, we boarded a bus to the Neutral Buoyancy lab, where we saw four astronauts training in the pool.

Last, we stopped at the Space Vehicle Mockup Facility, where we spoke with Astronaut David Leestma who discussed how the SVMF was used for training to familiarize Astronauts with the shuttle and various parts of the ISS which were in the building.

Once again, NASA put on a fantastic event. The behind-the-scenes access was phenomenal, even if I was not successful in convincing them to let me dive in the NBL with my PADI certification. Thank you to everyone at NASA!

Sure, I know what you’re thinking: “Pierre, the STS-129 NASA tweetup was EIGHT months ago and you’re just posting about it now?!”

What can I say. The Ku-Band antenna on my computer was down… It takes a while for blog posts to reach the internet from the edge of the galaxy! Anyhow, the point of this post is to kick-off the revival of this blog, to create a public record of my experience on that weekend in November of 2009 and to commemorate what may have just been the final flight of Atlantis with STS-132. The story starts at some point in 2008 when I found out NASA was using Twitter to post updates from the Mars Phoenix lander under the @MarsPhoenix account. At that time, NASA was using the account to share information about the mission including pictures, like the one below, as they came back from the lander.

Mars Phoenix Robotic Arm Photo credit: NASA/JPL-Caltech/University of Arizona/Max Planck Institute

When you consider the huge amount of media and information generated by a variety of NASA missions which never makes the major news outlets, this was a great way to make the information available to people who were really interested in keeping current.

Following the @MarsPhoenix account led to following a variety of other NASA twitter accounts including the official NASA twitter account (@NASA), the official NASATweetup account (@nasatweetup), and the first astronaut to tweet from space: Mike Massimino (@Astro_Mike). Long story short, NASA extended an invitation to 100 twitter followers to attend the official tweetup for the STS-129 launch of OV-104 (Space Shuttle Atlantis) and I was selected.

The tweetup was a two day event which consisted of presentations by NASA employees, a tour of the Kennedy Space Center which included a stop outside Pad 39A and …something else…… Oh, yea. A friggin’ space shuttle launch! The first day was kicked off with talks by John Yembrick (@yembrick) from NASA public affairs, NASA-JPL news manager Veronica McGregor (@VeronicaMcG), NASA orbiter engineering manager Jon Cowart (@rocky_sci), former NASA flight director Wayne Hale (@waynehale), STS-125 Mission Specialist Mike Massimino (@Astro_Mike) and former CNN anchor Miles O’Brien (@milesobrien). Instead of rambling on about how cool it was to hear Jon Cowart describe what shuttle ‘twang was or how Veronica McGregor chose the geekiest possible final tweet for the Mars Phoenix lander, I’m going to recommend you watch the proceedings which are available in three parts on YouTube:

STS-129 NASA Tweetup – part 1 of 3

STS-129 NASA Tweetup – part 2 of 3

STS-129 NASA Tweetup – part 3 of 3

After the presentations concluded, we loaded onto buses which were bound for Pad 39A. It is not easy to describe how exciting it was to stand that close to a vehicle that was about to take humans into space. Luckily, we were given time to admire the orbiter and take pictures, so I’ll let the pictures speak for themselves:

The pad tour concluded day 1 of the tweetup. Day 2 commenced when we arrived at an off-site location to board buses headed to the press site. The press site had a twitter tent setup (twent?) with more people to talk to the group about closeout procedures, ISS gyroscopes and miscellaneous parts (hold-down bolts and nuts, foam, etc.) which were on display inside the tent.

After a few presentations, we heard that the Astrovan would be stopping in front of the VAB, so we all ran to the adjacent road to whoop, hollar and cheer the astronauts on.

A short while later, we heard the final polling and that all systems were go for launch. It was time to head to the countdown clock where we could see Atlantis sitting just past the trees in the distance….

…..and the countdown closed in on the moment………4….3….2….1…..

LIFTOFF!

And with that, Atlantis was off. Thanks again to everyone at NASA for all that you do and providing the tweetup folks with a once in a lifetime opportunity. You can be sure that everyone who attended will continue sharing our experiences and enthusiasm with our friends, family and colleagues.

Photo Credit: (NASA/Carla Cioffi)

Looking for more info about the STS-129 NASATweetup? Check out the following sites:

STS-129 NASA Tweetup Flickr Group – http://www.flickr.com/groups/nasatweetup/pool/

Space Tweep Society – http://www.spacetweepsociety.com/

Shannon Moore’s blog post (@Ageekmom) – http://geekhabitat.com/2021/nascent-nasa-tweetup-blog-post-im-cheating/

Scott Beale’s (@laughingsquid) blog post – http://laughingsquid.com/nasa-tweetup-at-kennedy-space-center-for-launch-of-space-shuttle-atlantis-sts-129/

Stuart Gleave’s (@the_defiance) blog posts – http://www.stuartgleave.com/blog/?p=439 and http://www.stuartgleave.com/blog/?p=376

Keith Barrett’s (@KeithBarrett) blog post – http://keithbarrett.com/blog/nasa-sts-129-shuttle-launch-tweetup-the-impact/

David Allen’s (@DaveFlys) blog post – http://www.daveflys.com/news/events/sts-129-nasa-tweet-up/

Rob Wilson’s (@RoBOotc) blog post – http://www.outofthecradle.net/archives/2010/05/space-shuttle-launch-nasatweetups-past-and-present/

Beth Beck’s (@BethBeck) blog post – http://bethbeck.wordpress.com/2009/11/16/space-tweeps-flying-high/

]]> http://www.jiggywatts.com/space-exploration/sts129-nasatweetup/feed/ 1