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 have a few short-term goals to drastically improve the system performance:
1.) Replace the dumpster fire that is coarse acquisition with a neural network.
My plan for acquiring the targets on the target surface initially was quite bad, and despite my efforts to shore up its deficiencies as the project continued, its consistent poor performance reared its ugly head time and time again. This is a crucial first step towards improving system-wide performance, since coarse acq. effectively marks the start of the docking process.
2.) Solve the attitude determination equation.
If it doesn't determine the three-elements of surface attitude, MARCO has no purpose. This should take priority over rewriting coarse acq. but having a strong coarse acq. process will greatly increase the speed with which I can resolve this issue.
3.) Build in a full-FOV acquisition process to acquire the target surface within the complete field of view.
This is a function that I knew would need to be built in to MARCO, if I were to expect it to ever gain any traction. Previously I required LiDAR contact with the target surface to initiate the docking sequence, however this is an unrealistic expectation of the parent system. This also leads into my fourth objective:
4.) Ditch the LiDAR.
LiDAR modules are prohibitively expensive. In this case, the LiDAR does allow MARCO to take some shortcuts through the math, but given the data encapsulated within polo file, every possible combination of target centroids in the FOV maps to a unique distance and attitude metric, or in other words the LiDAR is expensive fluff that should not be required for MARCO to work.
5.) Release MARCO as an open-source product.
In order to reach its target community, MARCO must be downloadable through Github, via a simple shell command. That's all there is to it. I will have to look into what rights I can retain vs. what gets forfeit when released as open-source technology, but I think I have options if I want to retain portions of the IP for potential ventures.
And that's it, I don't think this is really as tall an order as it seems, but I guess only time will tell.
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 have a few short-term goals to drastically improve the system performance:
1.) Replace the dumpster fire that is coarse acquisition with a neural network.
My plan for acquiring the targets on the target surface initially was quite bad, and despite my efforts to shore up its deficiencies as the project continued, its consistent poor performance reared its ugly head time and time again. This is a crucial first step towards improving system-wide performance, since coarse acq. effectively marks the start of the docking process.
2.) Solve the attitude determination equation.
If it doesn't determine the three-elements of surface attitude, MARCO has no purpose. This should take priority over rewriting coarse acq. but having a strong coarse acq. process will greatly increase the speed with which I can resolve this issue.
3.) Build in a full-FOV acquisition process to acquire the target surface within the complete field of view.
This is a function that I knew would need to be built in to MARCO, if I were to expect it to ever gain any traction. Previously I required LiDAR contact with the target surface to initiate the docking sequence, however this is an unrealistic expectation of the parent system. This also leads into my fourth objective:
4.) Ditch the LiDAR.
LiDAR modules are prohibitively expensive. In this case, the LiDAR does allow MARCO to take some shortcuts through the math, but given the data encapsulated within polo file, every possible combination of target centroids in the FOV maps to a unique distance and attitude metric, or in other words the LiDAR is expensive fluff that should not be required for MARCO to work.
5.) Release MARCO as an open-source product.
In order to reach its target community, MARCO must be downloadable through Github, via a simple shell command. That's all there is to it. I will have to look into what rights I can retain vs. what gets forfeit when released as open-source technology, but I think I have options if I want to retain portions of the IP for potential ventures.
And that's it, I don't think this is really as tall an order as it seems, but I guess only time will tell.
Helpful post.
ReplyDeleteccna Training in Chennai
Python Classes in Chennai