MARCO

Each image below represents the same input image data after various layers of processing.  I'd recommend clicking on an image to bring up the gallery view, since it's much easier to follow the continuity of the data that way. Raw greyscale image input, the image is rotated because of the way the docking camera is oriented on my test rig. Transition filtering: Each pixel is fed through an iterative algorithm which picks out sharp transitions in the image.  The high contrast of the black and white target make this a pivotal first step for culling away irrelevant image data. Grouping: Based on the results of the previous layer, the raw data rows are grouped as regions, each of which has a series of parameters such as average color, size, endpoints, and variance which are considered in the next layers. Scoring: Each region is fed through an algorithm specially designed to determine how likely it is that a particular region is the center of the target.  ...

After taking a close look at the MARCO code I was writing, and the bear of a project it was turning into, I decided to change gears to something more manageable and practical. If you're unfamiliar with how color images are captured and stored, the short version is that color images are captured on most small cameras by rotating a series of three filters in front of a CCD or CMOS, taking three pictures in rapid succession, and combining them into one unified array, with three values corresponding to a different color on each of the camera's pixels. This adds a lot of overhead time and memory before even beginning of the image processing stage.  To circumvent this problem, a lot of computer vision and image processing systems use only one color channel which, if you can get away with disregarding the color data, is the preferable way to go. With that in mind I designed the new target below, which is much more-easily identified in a grey scale image and also much more useful...

So I took some time, got a real job at NASA and I've been out traveling a bit, and I only just recently had some time to settle down and take a good look at this project from a more seasoned perspective.  For reference, when I set out to make this happen, I didn't know python, I had little experience with linux, and "computer vision" was little more than a buzzword to me.  I knew the math worked out, however I had a hard time translating the principles of MARCO from the realm of math where everything is clean and orderly to the real world where colors sometimes don't look like they should and the sun shines more brightly on some days than on others. I was not well-prepared to take on this project, and it's a good thing I started as early as I did because there's no way in hell I would have been able to achieve the fairly-positive results I got with less time. Be that as it may, I'm now in an incrementally better position to tackle this task, and I ...

The purpose of this post is to bring this project to natural stopping-point so that I can say "Yes, I did my senior project and it's actually pretty neat."  I guess it's important to mention before I begin that I do not intend to just forget about MARCO now and move on with my life, I've poured a great deal of effort and ingenuity into the system and I believe it has demonstrated some great potential, though I am not currently in the best position from an educational or financial perspective to develop it to the greatest extent.  I am actually going to start this off with the bad news, as many of the things MARCO does well must be taken in context with the things it sucks at: 1: Color Recognition Despite some of my best efforts, MARCO cannot reliably look at numbers in an array and say "Yep, that's the color I'm looking for."  MARCO struggles under even slightly variable lighting conditions to identify the colors of its targets, frequent...

As I've described before, the task of the vector transformation module is to ingest the results of fine acquisition and output an interpretive attitude reading.   The input to the transformation module is the x & y coordinates of each black dot in the center of each target.  This allows MARCO to generate the set of 6 unique vectors which I drew beautifully in the diagram below. As the more mathematically-inclined of you may know, in a perfect world with infinitely-precise centroid pixel coordinates I would need just 3 targets and two linearly-independent vectors, however this world is far from perfect and the additional target and vectors serve to greatly increase the accuracy of my readings. To save us all a great deal of time and brain-hurt, I will not talk in-depth about the mathematics that drive this transformation.  The actual equations boil down to relatively straightforward trigonometric operations and anyone who's taken college-level linear ...

All development related to target centroid finding is complete, with a few setbacks, the foremost of which being that Fine acq. translated nicely from a great heap of nested code into a nice warm dumpster fire.   I had to hedge my bets on a backup algorithm called black acq. which serves the same purpose, but requires a black dot in the center of the target where fine acq. could work with or without the dot (if it worked at all, which it doesn't). This marks the much-anticipated end of the computer vision/image processing phase of the project, which is nice.  The next step is vector transformation, which should be easy-peasy compared to the image processing portion.  I actually had most of that math worked out on paper with the intention of passing the coarse acq. results to it, but I could not narrow down the possible attitude past two distinct solution-spaces without more precise target centroid data. The green dots on each target are the results of coa...