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.
Open Source Devs Have The Same Question
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:
Must be open source in order to make sense
Help the creator survive
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.
Strategy 1️⃣ Politics
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.
Strategy 2️⃣ Fence In
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.
🤺Fence 1: Private Donations and Grants
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.
🤺Fence 2: Licenses
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.
🤺Fence 3: Insurances and Law Firms
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.
🤺Fence 4: Insider Mentoring and Treasury
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.
🤺Fence 5: Insider Trade Agreement
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.
🤺Fence 6: Union of Open Source
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.
🤺Fence 7: Pooling Patents
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.
Strategy 3️⃣ Survive In Self-Made Niches
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 Licensing
We can skip licenses on our open source work.
We can ignore copyright and law enforcement altogether.
That's one less burden.
We Can Skip Self Censoring
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 Create Art
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.
We Can Hide
Carving out and hiding within a niche where
closed source can't follow
will help an open source developer survive on the sharing end.
We Can Change Our Perspective
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".
Strategy 4️⃣ Hibernate
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:
☄️A Mass Layoff
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.
☄️A Digital Divide
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.
☄️A More Open Web
The way browsers download javascript code in clear text
has already made javascript the most vibrant open source community.
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.
☄️A Modernized Democracy
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.
☄️The Mother of All Scandals
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.
☄️Closed Source Funds Dry Up
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.
☄️Food On The Table Becomes Free
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.
Wrapping Up
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.
- tobben
Torbjørn Ludvigsen
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.
Hopes, Dreams, and Agendas
26-9-2021
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.
Getting Propelled
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.
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.
Star Shaped Networks are Easy and Rewarding, but Unfair and Fragile
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.
Distributed Networks Considered Desirable
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 Are Hard To Create And Maintain
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.
Distributed Production Requires Humans Who Require Rewards
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.
Fencing In
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.
Giving Up on Distributed Production?
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.
The Next Leap
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.
- tobben
Torbjørn Ludvigsen
HP4 works well enough for everyday use.
Tiny things remain. Like attaching a Z-probe.
Snaily Snails Fighting Line Wear
9-9-2021
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.
Experiments
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.
What Has Been Done and What Has Not Been Done
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.
Trick 1
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
Trick 2
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.
Hangprinter's Snail History
Hangprinter's Snaily Snail Slow Design Development in General
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.
- tobben
Torbjørn Ludvigsen
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.
Works
5-9-2021
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:
- tobben
Torbjørn Ludvigsen
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:
People hate Software.
Bugs, leaks, errors.
Cryptic messages.
Work-arounds.
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.
Against software.
The Plastic
People hate plastic.
Weak, cheap, poison.
Awful smell, cracking sounds, hysterical colors.
Short use.
Long trash.
Buries us, in lifeless artificiality.
Whatever disease you get,
there's always a chance
that plastic,
disturbing your hormones
triggered it.
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.
Against plastic.
The Robots
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,
themselves.
Other robots steal.
Grab attention.
Grab pictures, writings, and videos.
Robots intrude.
Take jobs.
Take lives.
Robots make money.
For the already rich.
Robots are
the ultimate source
of faceless power.
The Future
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 companies
or countries and companies
with superior robots
own the world.
That's the present.
People must defend themselves.
Against robots.
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.
Or worse:
Irrelevant.
They need free robots.
They need to be handed their free robots.
For free.
Extremely friendly robots.
Easy 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,
"economic realities",
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.
- tobben
Torbjørn Ludvigsen
People hate Software.
Bugs, leaks, errors.
Cryptic messages.
Work-arounds.
Menus, forms, and help-pages.
Torbjørn Must Test New Things. hp-mark Is Good Enough.
13-4-2021
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.
1: Publishing Is Not Finishing
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.
2: Working to Publish
The musician and I have different outputs and different metrics.
For music, success is to reach people.
hp-mark needs to
reach people, and to
work well enough for them,
to be successful.
My pain comes from ignoring/failing at the former while working to my bones on the latter.
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.
3 and 4 are Mostly the Same
I think quotes 3 and 4 mostly come down to the
same improvement of process for hp-mark as quote 2 did:
Make a small thing.
See if it flies.
5: Torbjørn Tests New Things
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:
Hangprinter with a very heavy effector
Hangprinter with big heat bed
Hangprinter with capable clay extruder
Hangprinter with two tool heads mounted
Hangprinter with as simple as possible tool changer
hp-mark with a GIANT marker
Outdoor Hangprinting
Collaboration with 3d-printing artists
Scripting auto calibration (easy now, after 7 months of grind :-P)
Load cells along lines
Store bought pellet extruder
Things that I don't yet know how to fit into the quick publish and outreach success template:
RepRapFirmware upgrade
Electronics (Duet Wifi to Duet 3) upgrade
Even more hp-mark precision and accuracy
Hangprinter v4 official release with documentation
More closed line guides, smaller bearings
- tobben
Torbjørn Ludvigsen
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:
hp-mark Is Good But Lonely
27-3-2021
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?
Keep Your Head Down And Work!
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.
AAAAAAA!
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.
What To Do
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:
Pay folks to suffer through your under-stimulating thing. Attention-as-a-service. Day jobs. Ads. This is the most common solution
out in the wild.
Find people who love your stuff by unusual amounts.
Put your thing into an exciting context/story.
Pitch! Learn pitching dark arts.
Accept defeat.
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.
Outlook
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.
Number 3 Suggestions for HP4
Hangprinting a body shaped house that's later sold as an art piece on a blockchain.
A variable size telescope rod framed Hangprinter on wheels that collects its own raw material and can flip pancakes.
Perfect for Burning Man.
Using HP4 as a motorized trampoline for cats. Computer vision detects cat. Ejects/bounces cat. Cat happy. The end.
A Hangprinter v4 built... inside Minecraft. And then being sold as an NFT on a blockchain. Just add the blockchain
to the end of every suggestion from here on.
A Hangprinter with AI that registers its own company, and prints and assembles an array of other machines to be its
employees.
A Hangprinter that just connects deeply with people.
Something simpler. A HP that puts cheese on a pizza and the slices it.
Hangprinter doing something oddly satisfying, like cutting paper, or 3d printing ceramic poop. With glazing.
A Hangprinter hanging down from space.
A Hangprinter mounted upside-down. So D-anchor is on floor, ABC-anchors in ceiling, and print surface is in the ceiling.
Mounted sideways would also work, for hype purposes, but not very well in practice.
A big Hangprinter outside using a hundred helium balloons as its D-anchor.
A single, fat, vertical, constant speed extrusion. Preferably made with the HP from space.
Printing a complete working bike in one go.
A flexible motor driven suspended Hang-print bed. A hangbed.
A HP that's just super huge, with ABC anchors mounted on big trucks, and D on a high crane.
This is the most frequently encountered one out in the wild, which more or less guarantees that it's a good one.
The word HUUUUGE by itself already tickles a bit. I'm sure you can feel it.
Short End Note
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.
- tobben
Torbjørn Ludvigsen
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.
hp-mark Exists Now
15-2-2021
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.
What Have I Done?
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:
Good enough ellipse detection. OpenCV's SimpleBlobDetector was 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.
Geometry. A photon bounces off a sphere, through a pinhole, and onto an image sensor. Many more follow.
They create a pattern, a projection, on the image sensor.
Given the position of the sphere, what's the equation of its projection? Or vice versa; given a projection,
what's the position of the sphere? Which projected point correspond to the sphere's center? I derived all relevant
equations by hand and wrote tests that wouldn't go
green before I was exactly right.
To bootstrap the chain of testable geometric functions, I derived the most basic equation in two different
ways, and tested that the two derived functions gave exactly the same results.
The system would never be good if the theory it rested upon wasn't sound, so I spent the time to make this
perfect.
Filtering among ellipses. The improved ellipse detector found lots of ellipses.
Getting hp-mark to determine which ellipses represent real markers, was hard.
To be real useful, hp-mark must be able to identify all its markers almost all the time,
so I spent extra time here as well. I will return to this point in the future, but we're at least finding
all the markers ca 80% of the time now.
Color recognition. The human brain is full of heuristics that helps us determine color,
in a wide variety of situations. Very fine details of camera settings, light/shadow,
and way of definition, throws a simplistic computer program off very easily.
The strongest heuristic I was able to program, in which all colors are relative, still can not
identify a non-marker in a set of six real and one false marker.
Still, I was able to keep color as a marker categorizer that lets us
avoid having to put QR-codes on our markers.
I fought a bit for the aesthetics.
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.
- tobben
Torbjørn Ludvigsen
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.
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.