In earlier texts I've linked open source to warm fuzzy feelings, freedom, and happiness. Critique often comes in terms of survival or well being of the developer. The most typical question is whether open source work can put food on the table. I've been thinking about that.
With "open source" in this text, I mean the practice of sharing intellectual work publicly down to excruciating detail.
The level of sharing is of course a continuum, and "open source" has many definitions. In this text, let's associate "open source" with the most sharing end.
This text is written to a community who wants to endure life at the sharing end. Food on the table is just one of many challenges we face, but we're asked about this so often that it deserves an answer.
Sharing requires surviving, which requires covering one's expenses. The typical dev wants to share, but must also pay the bills.
Perceiving a conflict between open source and paying the bills, the developer faces a stark choice. Either they must find an open source business model, or they must leave their open source work.
The economically pressured open source developer will search for projects that:
I find nr 1 hard to crack, but nr 2 really breaks my brain.
That's partly because survival was always hard. Look at the history of almost anything, and you'll find hardship and randomness.
But it's also because being open source is almost always a terrible business plan.
With risk of actually breaking my brain, I will chase this train of thought as far as I can in this text. Let's look at four strategies that might help the pressed open creator survive.
This strategy is obvious but infrequent. Don't ask me why. Elsewhere in society, all kinds of groups seek political protection all the time. Industries, religious groups, age groups and even genders use politics to benefit themselves. So why wouldn't we?
Through politics we could organize society wide efforts to support open source. We could fund our best projects with tax money. Or we could force companies that misbehave on the closed market to open source their products.
I find politics exhausting, but I also find that we should get our act together and do it anyways. Refusing to stand up for our beliefs in public debate is a self defeating attitude. (Talking for those of us who live in functioning democracies.)
At the same time the open source community must be mindful about potential downsides of political projects.
For example, politics can breed prestige and a tendency to inflate public expectations with helium.
Saving individuals could also drag the community down. Open source gets a bad rep if low quality projects don't die quickly enough.
In today's harsh conditions, any survivor project is exceptional. With politics in the mix however, we will risk that projects get life support just to save someone's face.
I think good technical leadership in publicly funded open source is possible, but let's not head too far into dreamery.
Let's stop it there. There's little appetite for politics within our community, and we're far away from political victories.
Let's look at some similar strategies that don't involve parliaments. These ones are much more common, so I'll explore them in more depth.
Let's generalize "fence" as anything that separates insiders from outsiders.
The basic idea: Somebody builds a fence around open source work. If those on the inside survive happily, then more will join. Once everyone is inside, we're all open and good.
However, if we get a few of these open islands, and not everyone gets onboard, then everyone is stuck in half-open source land, which would be bad.
Being open for everyone is exactly the point of open source. Those who would be shut out first are the ones we're the most eager to reach. Not reaching everyone is an openness failure.
So the downside of many fencing strategies is that they start with openness failure, and try to gradually reduce the amount of failure along the way. Having to lure people over to "the open side" leads to complications.
Here follows a list of common fencing suggestions. They are put in order of increasing distance from the naive free-for-all strategy that I wish in my dreams would work.
It's simple and helps creators survive.
A little confession here. Seeing the idea of retroactive public goods funding, pushed by someone wealthy enough to fund it, intrigues me. Very creative philanthropy idea there.
However, the reality today is that grants and donations are few and small. Very few devs can rely on them for food on the table.
The few large grants programmes I know about have created distorted markets. Talented people drift towards satisfying checklist requirements, or second-guessing vague requirements, rather than doing useful work. We need something more.
Copyleft licenses force devs to copyleft their work if it builds upon copyleft code. It has been in use for 36 years, but few are currently joining.
The grass inside the fence needs to be made greener for us to survive there.
To improve the status inside the copyleft fence, we could hire lawyers.
A law firm could take on large companies in court. Insured open source creators could enjoy legal security and stability.
Uninsured creators could be protected by proactive law firms who actively search for license breakers, sue them, and split infringement compensations with rights holders.
There's one more legal path. Users are given freedoms by open source licenses. If they value these freedoms, they should be motivated to sue license breakers. The copyright holder doesn't need to be involved at all. I've seen one such example of user suing license breaker.
Alas, law is exhausting work, almost worse than politics. Most open source devs, like most users, aren't too keen on punishing anyone.
Availability of learning resources and tools is what currently recruits every single programmer to be an open source developer initially. It's just impossible to learn how to program without also being exposed to open source history, methodology, and ideology.
A high rate of recruitment keeps open source in existence despite being a terrible business plan. When people leave open source, it's most often for "food-on-the-table" reasons.
Some contact with a more experienced open source developer would help many to stay in open source for longer. Opportunities could be highlighted, skills improved, and sense of community strengthened.
At this point in the list, pooling up some funds in a treasury would be preferable. Otherwise, the mentor would donate time. Relying on a few expert individuals who have the capacity to donate time is what we're trying to move away from.
Nice prices inside the fence could boost survival rates.
However, it only works if some closed source businesses still buy our stuff at non-discounted prices. We can't be too aggressive with pricing schemes, or it will backfire.
Only let good open source creators in. Make them help each other survive. All other fencing techniques could be strengthened by an organization that we all pay for together. Deployed carefully, a union is a turbo for any kind of worker's conditions, including paychecks.
Making it float is a tad complicated. We're getting close to politics again.
Inside something like a union, we could pool our patents and enforce them together.
With enough resources, we could create a service where outsiders could buy restricted access to our work. On our way to open source utopia, we could get rich! Survival with style, right?
These kinds of strategies are risky. Rent seekers could hi-jack the open source union. They would then own the treasury, all patents, copyrights, trade agreements, law firm contacts, and mentorship programmes.
I don't really think we should fence in that much. I think it's an arrogant idea.
Non-open companies are already specialized in surviving competition. Playing by their rules will drag us into their game. We can't beat them and have virtue at the same time. We're great, but I don't think we're that superior.
Rather, I think we're making an error of thought by pitting open source up against closed source. It's like pitting pets up against wild animals in the jungle. Or mammals up against dinosaurs.
We're looking for strategies to help our open source creators survive. To do better, let's stop treating open source like a broken business plan. It's not a business plan. It's more like a culture.
Being a culture gives us more options. We can untie ourselves from commercial culture and company culture. We can stay fluid and develop our own culture in the background.
Survival wise, be the little mammals in the age of big tech dinosaurs.
Open source can go where others can't.
We can skip licenses on our open source work. We can ignore copyright and law enforcement altogether. That's one less burden.
We can be vulgar, political, and personal if we like to. If others think we're wasting time, we don't have to care.
We can risk saying what we feel. We can do anonymous things and provocative things. Like jokes.
We can do computer generated art, and art robots. It's perfect for us! If art ever scales, it looses value. Closed companies must scale, so they can't do art.
We can play with all forcibly low volume things. Not just low in demand. I mean we can make few copies by design.
We can talk to whoever we want and collaborate with whoever we want.
Carving out and hiding within a niche where closed source can't follow will help an open source developer survive on the sharing end.
The new culture framework puts the question about food on the table in a different light. Food on the table is still hard, but the explanation to why it's hard, changes. The implied difficulties also change.
"Open source is bad business" changes into "you can't front-run the new culture development". That's the updated reason to why open source is so hard. No textbook model can predict what we will become.
The implied pragmatic answer changes from "open source is bad, so leave it" to something more like "keep re-inventing yourself until you can go where you want".
Surviving is about taking opportunity when there is one, and saving energy if there's none. Maybe there are few open source opportunities around you right now.
One can always do something else for a while, or cut down on expenses. If we know who we are, we can pause our work with confidence, and recognize opportunities to resume when we see them.
This strategy makes sense if you, as the early open source mammal you are, think an asteroid event will clear some survival space for the real and cooler you in the future. The asteroid could be any one of these:
Automation and economic downturns will hit all professions. Many developers will turn to cool open source culture if it exists. We saw this after 2008 and during covid-19, and we'll see it again.
Western and Chinese tech are increasingly being made incompatible for military strategic reasons. Closed source have to choose sides.
Open source can also be caught in the cross-fires, but we generally have more leeway to get around embargos. The growing gap between east and west could create big exclusive open-only zones.
The next web is being built on blockchains. Regulations are currently forcing these blockchains to be open and distributed. If it continues, the next web will become a gigantic open-only zone.
Algorithms make important decisions in our society today, and a few powerful people control them. It's reasonable to expect democratic control over the code in the future. Representatives will vote on what code gets deployed and what doesn't.
To learn about the code, the people must see it, so it must be open source.
This style of governance is commonplace in the cryptocurrency world. If proven effective over time, companies and governments will copy parts of crypto's governance structures.
Scandals already drive a lot of open source adoption, and we'll probably see more of them. The question is how big they will be.
If they're very big, the closed source world might be the one coming down like burning zeppelin. This would leave loads of space for open to grow into.
Mega-scale uncritical data collection is continuing in the US as well as in China. We have no historical precedence, so we don't know how that will play out.
For the past 50 years closed source technology has been good investments. So investors have created closed source jobs.
We don't know if that trend will continue. Tech giants have stopped emerging. That's understandable, since yesterday's new names still haven't made any money.
Uber and Snapchat are still loosing billions per year, after 13 and 12 years in the red. Will they ever pay down their debts?
What's appearing instead of new tech giants is crypto projects. Hundreds of them. They're typically very profitable and all open source. They gladly go into profitable spaces that closed source can't reach.
Universal basic income has been suggested and piloted since forever. If it became reality, open source would thrive even more. The tens of years you spent building a CV that would give you a job that would put food on the table, they would be in vein. You could have been doing open source all that time, and your CV would have looked much better.
The future is a volatile place, and a bet against open source might be as irrational as a bet in favour. Building a portfolio takes time, and it's too late to be early when everybody wants in.
But with all that said: Does open source put food on the table? Not in the most straight forward way. Not in all versions of the future.
HP4 works well enough for everyday use. Tiny things remain. Like attaching a Z-probe.
I'm thinking about what's next. Do I want to become a kit maker? Maybe sell big machines, or prints? Print houses? Rockets?
To get down to what I want, we must rewind the tape a little bit. It was one image in particular that propelled me into the Hangprinter project:
RepRaps have been spreading through a print-it-forward culture. That's an unusual and awesome way for machines to spread.
I was already hooked on an idea. I wanted to make a robust and distributed worldwide network of manufacturing. Peer to peer. The image above looked like an indication that it could happen.
It was a very frequent idea at the time, ca between 2011 and 2016, and lots of people were working on it. Reference for example the Wikipedia entries on Distributed manufacturing, Commons-based peer production, and Peer to peer for context.
Central to the idea is eliminating thresholds for newcomers. Easy access. Anyone can join and become an independent manufacturer.
Also central is ease of replication. Anyone can easily help anyone else become an independent manufacturer.
The ethos of distributed production was copied from free/open source software, and from the Internet itself. We had achieved universal access to information and publishing in the preceding decade. Now was the time to achieve universal access to goods and manufacturing.
Praying it would take only a decade or so.
Let's zoom out a little bit. Humans generally organize in star shaped networks, where the central node is very special.
Allowing for special treatment of central nodes helps star shaped networks off the ground. The prospect of ending up in center themselves motivates people to build stars around them. The star shape is also good for making quick decisions, critical in chaos and early phases.
Although easy to build, star networks can be fragile and unfair in the long run.
Democracies have moved away from the star shape in their power and politics, to avoid the risks of authoritarianism.
When designing the Internet, the US military avoided the star shape. Its center would have been too easy to attack.
Democracy and the Internet have become very popular. Many like, and even idealize, their robustness/stability as well as their perceived low threshold, equality, and fairness.
Distributed networks have few ways to reward its early creators.
In the cases of the Internet and of free software, it would undermine the projects' fundamental goals to give anyone special treatment. Being non-owned and distributed, there were no stock options to hand out. (Before tech giants appeared, but let's not go there yet.)
Harder yet: these networks had to recruit new, independent drivers of the network. A single group can not be a distributed network all by themselves.
Even still harder: All networks gravitate towards star shape. It's what people are used to, its easy to build, it's short-term efficient. A gravitation towards star shape should always be expected.
With few ways of reward, why did anyone work on such hard projects at all?
Many of them called themselves activists. In this simplified recollection, I will use that term for all of them. The Internet and free software were built by activists. They were eager to build something better than star shape, even at a personal cost.
Strong forces was put in place to counter act the gravitation towards star shape. For the Internet, it was automation (egalitarian protocol executed by computers). For free software and democracy it was law (copyleft, with its threat of punishment). Keeping a non-star network topology in check required such clever and quite ad-hoc solutions.
It's questionable whether non-star ideals could be automated inside a manufacturing network back in 2011. Terms of Internet communication are agreed upon by computers. Terms of RepRap manufacturing were, and still are, agreed upon and executed by people. We can automate a lot, but not the people parts.
The free software movement's use of the law to keep the non-star topology in check has generally fallen out of favour. People dislike threats of punishment. We don't want to punish.
So people must be rewarded. Otherwise, they do something else.
Duplicating Internet's topology template within manufacturing requires more automation, or more reward to be present within the network than outside of it. It sounds hard. But we tried anyways.
For me, it was like this: I wanted to be useful. If accepting lower rewards made me more useful then, well ok then.
Hard and complex work was done under umbrellas such as RepRap, Arduino, and Open Source Hardware. Code and design files were maintained and improved. Plans were crafted and executed upon. Manifestos were written.
There were some Distributed Production success. The first image in this blog post convinced me that it was real. In fact, RepRaps were printed forward at least in the thousands, maybe in the millions, before more centralized brands and companies took over, and made the once distributed network of RepRaps more familiarly star shaped.
The same star shape was given to the Internet by tech giants around the same time. Centralization of the RepRap network was maybe even faster than that of the Internet. RepRap was centralized by the very earliest RepRap activists themselves.
Predictably, at the center of star shaped networks, tired creators are currently building fences around their work. The vast majority of open source projects have become star shaped networks. Also those who try to be distributed networks. See Nadia Eghbal's book for numbers on this. The gravitation towards star is stronger than any individual or company can overcome on their own. And we're not collectively building distributed production right now.
Having followed the activist track for a few years, creators typically need more stability and rewards. Patents, strict copyright licenses, and secretive development practices give stability and rewards.
No one blames a fading activist. Everyone wish them all the best. Competitors, customers, and myself included. Even as production is tamed and locked into star like shapes, we should not call for distribution at any cost.
In the fading activist's wake, we find a richer commons (from early years, and through doors left open), and awesome products, retro-fitted into centralized manufacturing. No low threshold network, but old gems and happy customers.
Since I started working towards distributed production, I feel the manufacturing commons has plateaued, but at a higher level. I enjoy the heights we've reached. I feel grateful, even as we gravitate back into star shaped organizations.
But I can't help but think we're lowering our ambition by fencing in. We got half way towards an Internet-like manufacturing network, then rolled back to the old system.
We have achieved a manufacturing increment, still not a manufacturing revolution. We're not automating, we're not winning. I feel like we're retiring. We're tired.
I probably won't become a kit maker. I want to make a distributed production network. Hangprinter is too star-like already.
If I offer kits, and solve user experience issues, then I sink deeper into the middle of the Hangprinter star shape. I will get tired, and start building fences in there.
Zooming back in on the present again. I think I know what to do next.
Blockchain projects, with their cryptocurrencies are a more fruitful attempt at duplicating the Internet's ideals and success. It is cyberpunk flavoured free software money, squeezed into the Internets own design template. Made by unknown activists towards whom we should be grateful.
They are protocols of rewards. Automated rewards. Non-activists stay on the network, and keep their computers on the network, because of the rewards.
As mentioned earlier in the text, distributed production needs more automation and rewards.
Let's try again, starting at the other end. Let's design protocols for decentralized manufacturing.
Let's reward manufacturing efforts with tokens. Let's introduce a blockchained manufacturing network, capable of representing and transferring real value. As real as the objects we make.
Let's create oracles who measure and quantify what we do, and what we could do. Let's get the data out. Transparently, on chain.
Let's build a treasury owned by the network itself. Let's govern it on chain, according to our own protocol.
We can't shoot objects through Internet cables. But we can shoot more things through them than we could before. Deals, rights, rewards, money, commitments, contracts, designs, plans, hopes, dreams, and progress. Let's try.
What do we have to win? Well, all the objects we'll make. We want to make things. We want the money. We want the pride. We want the craftsmanship. Manufacturing, baby!
And I think freedom. A place in society. Resilience. Owning ourselves more. Also described in 2016.
And yes, the little HP4 things that remain. My goal is, as it has been for a while, to not be the one who fixes them.
The HP4 has done ca 75 hours of printing now, and shown great promise! I shouldn't be surprised that it's working well, given the insane amount of work hours that I've put in, but I am.
However, there's one thing that bothers be a bit. The lines already show slight signs of wear. I want to run HP4 unattended for thousands of hours. So I need to stop any fraying.
I first tried filing down the surfaces of the bearings of the most frayed lines, to see if the rate of fraying slowed down.
The result above called for experiments with line lubrication. So I tested to rub one line with stearin, just from a room tempered chunk. It seems to have stopped the fraying from getting worse from what I can see. I've also greased up one of the lines with some "multi grease" that I had lying around. That also seems to have mitigated the issue.
But even if my unstructured experiments with stearin and grease might have worked out, I don't particularly like having to lubricate my lines.
From the results above, I don't know for sure if it is the bearing surface, the sharp bearing radius, or maybe the white ceramic eyelet that causes the line to fray. But I'm making some guesses.
Since my sanding of bearing surfaces didn't immediately reduce the fraying by a lot, I'll let that potential cause rest for now.
I know that the previous Hangprinter v4 prototype also had fraying issues, but it didn't use eyelets at all. It frayed due to shear forces between lines and angled entrances to the vgroove bearings. That's why the new prototype has tilted bearings, so the line always can enter them in a straight line.
I think the ceramic eyelets probably contributes to the problem, but I think there must be other factors contributing as well. There are some line guiding bearings on the ceiling unit, with no ceramic eyelets. The line shows some very slight frying around those, which can't be explained by wear from ceramic eyelets.
So something else must be contributing, and let's believe/assume/hope for a while that shear forces are already mostly dealt with.
Based on those preferences, experiences, beliefs, and hopes, it is clearly time to test if bigger bearing sizes could be helpful. Meet the "Snaily Snail" line roller anchor, with a 608 skate bearing in it:
Only time will tell if snails can eliminate the need for lubrication.
All other cable driven robots I've seen out there have bearings that rotate freely around an axis. Only Hangprinter has insisted on stationary snails.
The reason for this is that the line coming from the ceiling comes at a constant angle into the snail. If the bearing rotated freely, it would not point directly towards the effector, it would point halfway between the effector and the ceiling unit. Except, there exist at least two tricks one could use to design around that problem.
We could let the line from the ceiling enter the "snail" in a particular way, so that all forces from that entrance goes through the desired axis of rotation: o
If the snail's bearing had two axes to rotate around, then any entrance direction could be matched up with any exit direction of the line, without any shear forces on the line.
Both of these tricks seem ok-ish as solutions to the fraying problem. They're both not the most complicated mechanics in the world, but they add a significant amount of moving parts. There are six of these snails in every Hangprinter. If we count the line guides on the ceiling unit as well, since they do a similar job, there are 18.
Good bearings are expensive, and each will fail after X hours. Before failing, they will start asking for lubrication, with squeaking and rattling sounds. Not the end of the world, but we're trying to reduce price and maintenance burdens here.
The thought of implementing those tricks make my thoughts wander back to the good old days, when Hangprinters were barely working, but extremely simple.
We're moving towards what other cable driven robots have been doing since forever, right? Why do we do it so slowly?
Hangprinter is searching the design space at the cheaper end of cable driven robotics. None of the other cable driven robots have become wide spread either, so we can't copy/paste or do "the obvious" while we're searching for solutions that aren't obvious yet.
There must be some deliberate searching on our end if we're to reach our goals. I wish we could search a bit faster though, but alas.
Hangprinter version 4 works now. It is the default Hangprinter design in the repo. It has some documentation, and it has some builders. It prints decent quality things, like this:
... and this:
... and this:
People hate Software.
Bugs, leaks, errors.
Menus, forms, and help-pages.
Software says "Ok, doing it".
And you wait, you don't know how long.
You don't know what it's doing.
You need it to work.
It sometimes fails. After a while.
Like the most under-funded government agency imaginable.
Broken windows, rotten apples, full trashcans everywhere.
People defend themselves.
People hate plastic.
Weak, cheap, poison.
Awful smell, cracking sounds, hysterical colors.
Buries us, in lifeless artificiality.
Whatever disease you get,
there's always a chance
disturbing your hormones
That's what people feel.
Plastic comes from an unknown place, underground.
Plastic poison can penetrate your skin.
Get into your body.
Like the devil.
All other materials are natural.
Only plastic is not.
People defend themselves.
People abhor most robots.
Plastic and software with motors.
Commanded by others.
In our surroundings.
The few robots that people love,
are exactly those
that they control,
Other robots steal.
Grab pictures, writings, and videos.
Robots make money.
For the already rich.
the ultimate source
of faceless power.
A single person
with superior robots
could subjugate all other humans.
All you need is scale.
This risk was not in the past,
but is in the future.
A group of countries
or countries and companies
with superior robots
own the world.
That's the present.
People must defend themselves.
And the only way
is with robots.
The power over yourself,
can stay yours in two ways:
through kindness of others,
who have robots,
Or you can have robots yourself.
People who hate software
who hate plastic
who have little money
will stumble into non-ownership of robots.
Through defending themselves
against software and plastic.
They must be given ownership,
or they will be owned.
They need free robots.
They need to be handed their free robots.
Extremely friendly robots.
Entirely under their command robots.
But strong and valuable robots.
Robots that they will accept.
Robots that will eventually defend them.
But people hate robots.
And receive robots with stiff smiles.
Least wanted pair of socks, on Christmas Day.
Hangprinter is me, knitting socks.
I hate software and plastic. But I need Robots. And also you.
Just my kindness,
will not be enough to cover all,
when robots of power march in.
They will call it,
and do what they want.
They will harm you only by accident.
Because they won't notice you at all.
But if you have robots.
A few for yourselves,
that you love.
Then you can step aside.
Not care about those in power.
And be free.
I saw this talk about one of my favourite artist's creative process. Here are a few quotes from it that I've reasoned around the last few days:
1: "Publishing is not finishing. All the emotions are different. [...] Publishing is deciding to stop when you want to keep working. And it's super painful."
2: "Publishing works best if you think of it as a style of working. It's an attitude that persists throughout the entire creative process. Working to publish is about getting shit done. Your whole mentality shifts when you're working to publish. You focus on the stuff that matters, and you ignore the stuff that doesn't."
3: "Working to publish, it's selfless, it's outward focused, it's about results, and giving back, and contributing to the world."
His shortest version of the good work to publish method is this:
4: "... doing only what matters, the whole time, and then stopping."
He explains that this is a great strategy because most ideas and attempts flop, and you don't know which will succeed beforehand.
5: "You can't choose what you're famous for. ... I can't make a song a hit. I can't control how my songs are pushed through the world and are experienced by others. What I can do is be prolific, I can be creative, I can make great stuff. What I can do is work to publish. You write the next scene, you record the next instrument, you build the next set, you shoot the next tape, you design the next synth, and I can [publish all that] and then I can move on, and I can go to sleep at night, knowing that I did everything I could."
I want to see if this musician's points can help me think better about where to take hp-mark and Hangprinter from here. His work is different from my work, but we're also similar. Let's see if we can make our experiences fit.
Things are never finished, we have that in common. I like his emotion focused description.
With where I'm at with hp-mark right now, I don't want to keep working. So we're not exactly at the same spot, the musician and I. That's because hp-mark is not like a song. It's more like an instrument.
Since even before starting to build hp-mark, I've thought of it as lifting Open Source Hardware over a threshold, closing the loop, ending the guessing game in open source hardware positioning. A short-term grind, a long-term investment for the common good.
Proprietary machines have had motion tracking for decades. Everyone knows an OSHW motion tracker could be made. It just requires someone's work hours. That might as well be me, I thought. But it's not very fun, no, and I knew that. It's painful to continue. It will be delightful to stop.
My hp-mark process changes after this month's demo, because hp-mark is good enough. I have improved both code and hardware a lot, and tested it thoroughly over the last month. It can take OSHW over the threshold just fine, if it reaches widely.
The musician and I have different outputs and different metrics. For music, success is to reach people. hp-mark needs to
But the musician's point makes a lot of sense for hp-mark in the continuation. Just make a small thing and see if it flies. See if you can have a little success, quickly. I will get back to that way of working.
Make something small work well enough, then try to reach people. Make something else work then try to reach people again. And again and again and so on.
I regret not pasting a giant Aruco marker on the Hangprinter back in November 2020. I could also have dropped the spherical markers in December, when I found they were hard to make/source. And the colored markers stayed with me for too long also. I would have reached more collaborators and supporters by doing something simple, and then spent time reaching out instead. Imperfect decisions there. Well, well.
I think quotes 3 and 4 mostly come down to the same improvement of process for hp-mark as quote 2 did:
I interpret quote 5 as "test new things, test different things, do the next thing". The last couple of Hangprinter years have felt a bit stagnant. Particularly on the outreach side of things. Why?
Many worthwhile Hangprinter related projects are hard and time consuming. Robustness is not quick, easy, cheap, or sensational. We need robustness. So I had to dive into "doing it right", and swam across the swamp.
Still, I should have done it more quick, easy, cheap, and sensational than I did.
There's always a light version of any project, one that breaks you down less. I must break down less. Economically and motivationally.
Quick things to try:
The rabbit hole has gotten deeper. But progress is fast at this stage. Average error (that's accuracy) has shrunk from ca 35 mm to ca 3.5 mm. Maybe even smaller. I haven't tested accuracy thoroughly yet.
Precision (that's stability of repeated measurements) at the origin is down from ca 5 mm to ca 1 mm. And also:
CHECK!Detect all markers on 95% of training images
The markers have changed from small colored spheres to bigger retro-reflective disks. They're cheaper, lighter, easier to manufacture, and perform much, much better.
I had to go and implement the disk geometric equations. My body protested for days when I picked up that task. Luckily, this time I had a research paper to guide me through most of the theory, and I could quickly replicate my old test structure. This made me ca 10x faster compared to when I did the sphere geometry.
I've posted a couple of demos since last time:
The first video shows the more fundamental use case for hp-mark: auto/assisted anchor calibration. It enables all other hp-mark use cases, including homing.
So hp-mark is growing up.
The extremely high recognition and identification rate I have now is thanks to some LEDs that I put around the camera:
I know I could enhance accuracy and precision further by mounting these slightly higher end, low distortion lenses:
However, changing the camera PCB and lens means having to calibrate it and also make a new mounting bracket for it. Plus all the fiddling with wires, focusing the camera, unexpected stuff etc.
My guess is 1-2 days of work. Is it worth it? What are my goals?
This sprint's goal is "high accuracy auto calibration". The higher level goal is "a reliable work horse". Peace of mind.
The better camera achieves all of that. So I have to do it. Just like I redid the markers.
This isn't how I worked a few years back. This isn't how the HP1, HP2, HP3, and first prototype of HP4 were made. They were all just barely working systems. This is why HP4 will be different.
Body is shouting loudly. And for good reason.
Rest of World, aka everyone I meet, care extremely little about hp-mark in its current form. It you're reading this blog post, you're among very few (source).
As much as I crave attention, Rest of World craves brain tickle. Humans need this always. Brains want to light up.
Current form hp-mark just isn't very...
... stimulating. For me, a person who is constantly dying for attention, this is a problem.
Even at nanometer precision, hp-mark without a context would be nano-stimulating to the non-Hangprinter owning world. Common solutions to this kind of problem:
All of these have their own pros and cons. Too much to write down here. I will do number 5 for the rest of this sprint, and then try my luck at number 3.
The first slightly more exciting context, at least for hp-mark, will be HP4. End-to-end, released machine, with build manual and all. I look forward to that.
HP4 is not very interesting on its own either though. It will need it's own number 3 eventually. A context creates a story. Without a story, humans can not understand, or hardly even perceive your stuff.
The old HP story is basically "a living thing that creates economic value". Fully automated, self-replicating, printing furniture, taking zero space when not in use. I'm not sure if that is tickly enough from my attention cravings' perspective. Before it's even out there we'll never know.
hp-mark does more than just exist now. It's getting quite good, but also quite lonely.
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:
Acquire camera 6D pose (this includes defining our world coordinate system)
Acquire 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 continuous 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 mechanically 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 results at the top of this post for a while first. And let's rest.
Hangprinter Campaign: Github Sponsors
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 licensed under the Gnu Free Documentation License. The videos published via Vimeo or Youtube are also licensed via Vimeo or Youtube.