I climbed down a rabbit hole recently. Nearly half a year working on hp-mark. The past 84 days even skipping blog post and newsletter writing.
Progress has been steady. It works now. hp-mark measures positions, like:
Accuracy is not fantastic. The image above is a lucky one, with only 3 mm of error. A more commonly seen error is around 35 mm.
A lot of hp-mark work remains. I ticked 2 boxes, and added 6 new ones in the roadmap today:
Aquire camera 6D pose (this includes defining our world coordinate system)
Aquire effector 6D pose
Detect all markers on 95% of training images
Take image ourselves upon request, don't rely on other programs to take image first
Create a continous stream of position measurements (video?)
Get a statistical idea about size of error
Respond to RepRapFirmware/Duet request for position measurement
Integrate a second camera, to reduce error
I'm a bit overwhelmed still. I need to look backwards a bit.
I've been surprised.
I chose C++, OpenCV, and a very traditional approach for this project. I just wanted the most basic code that would mecanically find circles among pixels, and then apply static geometric equations to transform circles into a nozzle position. No AI stuff, no GPU stuff, no fancy hardware control, just $$ f(x) \rightarrow y, $$ where \(x\) is an image, and \(y\) is a nozzle position.
Such an old and explored problem! I felt confident.
Some things that took long for me to program, in descending order:
SimpleBlobDetectorwas ok, but ultimately not robust enough for our purposes. I was lucky to find ED_Lib, and spent a little over a month integrating it into hp-mark. For example, I had to fight a little to get sub-pixel accuracy in the center and size data. More about that here.
I feel like I'm almost too tired of it to even write about this stuff now. But before I climb out of this rabbit hole, I can show you something about how the ellipse detector works internally:
In the image above, we see that one marker was missed, despise ED_Lib's many different heuristics. I tried to tune the heuristics for the hp-mark use case. See how that went, here.
Ultimately failing to tune the heuristics convinced me to put background plates below my markers. That is what I'm currently working on. They will probably end up looking something like this:
The final background design will probably be flat and circular, and hp-mark will use the edge of the background, as well as the marker itself, to determine its position, further improving both robustness and accuracy of the system.
But not today. I'm so tired of that kind of programming. Let's celebrate the restuls at the top of this post for a while first. And let's rest.
Hangprinter Campaign: Bountysource Salt
Hangprinter Merchandise USA: Spreadshirt.com
Hangprinter Merchandise Sweden: Spreadshirt.se
Hangprinter Project: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , 
Hangprinter Project Homepage: hangprinter.org
Github Profile: link
Gitlab Profile: link
Hangprinter project on Gitlab: link
Vimeo User: link
Youtube User: link
Twitter User: link
Master's Thesis: link
Linkedin Profile: link
Appropedia User: link
RepRap Forums User: link
Source for this blog: Gitlab repo
Everything on this homepage, except those videos who are published via Vimeo or Youtube, is licenced under the Gnu Free Documentation Licence. The videos published via Vimeo or Youtube are also licenced via Vimeo or Youtube.