MoCoTiLa

We’ve been making some good progress since quarters:

Parts ordered/received:

• We ordered and received some of the servos we’ll be using (pan/tilt assembly, turret)
• We’ve got the Lynxmotion SSC-32 servo controller board (and a 9v wall-wart for it)
• We’ve got the Canon EOS 7D DSLR camera we’ll be using for our project (this thing is a beast)
• We’re waiting on a final design before purchasing any raw materials

Mechanics:

• We’ve got a Mechanical Engineering intern! Kyle Gee seems excited about the project, knowledgeable about his area of expertise and started off strong already with some Solidworks models. We’d started him on designing the tripod head adapter for pan/tilt assembly so we have a temporary holder for it, he emailed us a few hours later with a total breakdown, design and render in 3D. We’ll be getting it spec’ed, designed and machined… kind of like a gold-spike in our Mechanical pipeline once we get the materials and machinist.
• Mike created a mockup that more closely resembles our final design using the erector set we got. This lets us work out some obvious kinks in the design as well as better describe our end product to faculty and visitors.
• The armature is pretty much figured out, but we’re under heavy discussions about the dolly/track-transport mechanisms. We need cheap reliable (read accurate) movement on the track with very small steps… we’re talking with some Professional Engineers about this as well.

Software:

• Reworked the code from Girl-Tech Lynxy arm to use the newer heavy duty servos we got. Already ran into a small problem, the servos take a long time to get to their destination point even when the Lynxmotion controller sets pulse-width to the final value… this means that even though the controller and computer think the servo has finished moving, it isn’t… this is very bad. We’ve got 2 solutions, use a soft-wait (time.sleep() in python of a guesstimated timeout while the servos move) or, as Mike suggested, try to tap into the potentiometer readings that are attached to the servo rigs we bought and run it into the computer (via a phidget) to read the true value. We’ll need to research the hardware a bit more, but until then a soft-wait it is.
• Got the camera controlling via Linux! This is all thanks to the libgphoto2 open-source library… actually had to get the latest version 2.4.8 (it wasn’t in the Ubuntu repository yet) and compile it. Started off using the gphoto2 program to execute commands over the shell but that just wasn’t practical and the libgphoto2 library was written in C while our code is all Python… enter the awesome ctypes library! It took me all of a night to port their preview/capture C gphoto example code over to Python and linking into the libgphoto2.so shared library using ctypes as the glue. ctypes is freaking awesome! Cleaned up the code and wrapped it up in a camera class capable of producing actual high quality images as well as pulling the viewfinder/preview images.
• Developed a curves class (in Python and Javascript) capable of interpolating curves of type: discrete, step, linear and Catmull-Rom… this is our fundamental building block for all motions so it’s very important that it works right.
• Started designing the layout of the GUI and the system-framework on paper.

There’s much more but I’ll leave it at this for now.

Thanks to the Blizzard of 2010 our Quarter Presentations were reduced to a 15min walk-around by the faculty on the Friday of 1/4s week. We quickly reworked our original presentation and slides to work with the new format (gutting it out for the most part). We had to repeatedly present the same thing to every small group of faculty that came in the door. Vastly different than the normal 1/4 presentation routine… We started off a bit rough but got into a rhythm quite quickly. BTW, Tom created an awesome looking theme for the slides and we’re hoping to integrate that over to the website soon.

The Quarter Presentation/Walkaround went rather smoothly, with very minimal questions from the faculty. Either we explained ourselves extremely well or we totally lost them 🙂 . Brenda did make a good point that we were being pretty technical but weren’t expressing the “why” [it would make her interested in it]. I remember Jim Burke from Lockheed Martin telling us in Bat-teK to always ask and answer the “why” question at every step of the way… ok so I’m a slow learner. We’ll need to expand on the “why” of our product for next time. During the presentation we showed Mike’s “Fiber One” camera intervalometer (it keeps your camera interval regular :P), the Bioloid robot and did a quick demo (python script to pan the camera taking pictures and compile it into a quick movie), showed them a potential GUI layout and showed them some test videos we’d made both with the Bioloid as well as the timelapse video Mike and Mark made of their trip to Canada.

So now that the Quarter Presentations are over we’ve got to take all the things we’d learned in our Research phase and start designing and implementing our robot. We’ll be making heavy use of the people we’ve met so far outside of this project. In fact, Prof. Messner (from the CMU Mechanical Engineering department) was kind enough to allow us to pitch our project to his under gradclass to recruit an intern for our project. More on this later. We’re starting to talk to actual suppliers and builders also to see what resources we have available and what we’d need to buy etc.

Now the fun begins…

Same rig as before, only this time its strapped in to the back seat of my car. The images were taken at 6 second intervals with a 2″ exposure time (Meaning 4″ between the end of one photo and the beginning of the next).

Here we are testing our recently completed intervalometer. It is constructed from an Arduino, a reed relay, a potentiometer, and a 2.5mm jack.

The photos were taken at 1/2 second intervals on a Canon Rebel XT.

The pan at the end was done manually.

Here, we have more time lapse tests we ran with the Bioloid rig:

MoCoTiLa Bioloid Tests from Michael Hill on Vimeo.