Vector Transformation and testing results

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 algebra could probably bulldoze through the derivation in a few hours.  I will talk a little about the transformed subspace however.

First off, as you may know, attitude in three dimensions requires three quantitative, linearly-independent measurements to map every unique possible configuration. Initially, my three measurements were to be classic roll, pitch & yaw however this method imposed significant complexity and expense on the transformation protocol.

I instead settled on a different method that is something like a quaternion with additional restrictions that eliminate some of the uglier math.  The resultant angles are roll, phi, and theta, with roll defined as the angular difference between target i and camera i, phi defined as the angle from 0-360 starting at target i which describes the direction towards which the target surface is tilted, and theta (0-90 theoretically) which describes the angular tilt of the target surface in the direction of phi.

For example, since target i is defined as the unit average of -v12 and v34, if the target surface were to yaw 30 degrees to its left, phi would be 0 and theta would be 30.  If it were to pitch 30 degrees upwards, phi would be 90 and theta would be 30.




The next post will close out this phase of MARCO as a senior project and as a proof of concept.

Comments

Post a Comment

Popular posts from this blog

Preliminary Results and higher-order error sources

Image
I have some test results today, and I'm quite happy with how they turned out.  Quick refresher of the parameters: range refers to the target distance in centimeters, a_ang is the rotation of the major axis of the projected ellipse, and b_ang is a measurement of the target's rotation about the major axis, both in radians. The convention when dealing with rotated ellipses is to measure the angle of rotation of the major axis from +j (beh) clockwise (BEH!) but also, since I went through the trouble of rotating these images so that they're not sideways, a_ang is measured clockwise from -i.  The elliptical fit is programmed to run along the inside edge of the larger target circle. {'range': 42.27010789888579, 'a_ang': -0.04591864992309163, 'b_ang': 0.3644755561635681} Standard up front shot, I'm impressed that the software picked up that the target is actually tilted upwards relative to the camera though I think .36 radians (20 ish degree...
Keep reading

The Future of MARCO

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 ...
Keep reading

A Working Filter Actuator

It may have taken a week and an unwieldy hardware solution, but I now have an operational filter actuator.  hooray The transistors I tried just simply could not supply enough current in series to the solenoid when biased by the 3.3V digital output of a GPIO pin, so I threw together a servo-operated switch that flicks the filters back and forth pretty reliably.  I've been testing the switch and actuator by setting the scripts that operate them on an infinite loop (see video) and after a couple of solder joint breaks and design revisions the assembly finally seems to be straightened out. In the meantime, I have continued working on the startup scripts. Of course I have scripts operating both lights and the actuator, and I am integrating them all into a sort of pre-mission check to verify functionality.  I have managed to take images using both the IR and visible light filters, and the pictures look good.  All that remains before the real hard part of this project i...
Keep reading