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.