Solving Hangprinter's Biggest Problem

21-4-2022

So you've mounted your Hangprinter hardware. You've threaded all the lines and attached all the anchors. Motors are spinning.

Now there's just the configuration left and you're good to go! Weeee! =)=)=)

Ehem. Not so fast. Hangprinters kinematics is non-linear. Configuration is fiendishly hard.

Image source

Kinematics? Non-linear? What?

With non-linear here, we mean there's no flatness or straightness to be found in Hangprinter's physical parts. We use maths and physics to give it precision capabilities despite these weirdly shaped parts. Let me explain the problem more closely.

Hangprinter's movement commands are given in terms of x-, y-, and z-coordinates. Gcode files and user commands will tell the Hangprinter to "move to the position that has this x-coordinate, this y-coordinate, and this z-coordinate". Xyz-coordinates, sometimes called Cartesian coordinates, are flat and straight, with straight angles between them.

In a simple pattern like this, you can count the corners to know how many movement commands the Hangprinter got. Each movement command told the Hangprinter to move from one corner to another corner. Hangprinter needs to figure out for itself how to make the movement in between the corners smooth, flat, and straight.

Hangprinter's physical parts are neither flat nor straight, as we mentioned. Therefore, it can't control xyz-positions directly by moving three independent motors at constant speeds, like traditional gantry-style machines typically do.

Instead, its controls four motors, called A, B, C, and D. The motors are in turn connected to the moving unit (and each other) via belts, spools and strings.

None of the strings lie perfectly along the x-, y-, or z-axis. They point in all kinds of different directions at different times.

So to execute xyz-movement commands, the Hangprinter needs to convert xyz-positions into motor-positions (ABCD-positions). The conversion from xyz to ABCD is expressed in Hangprinter's firmware as an equation called the inverse kinematics equation. Let's abbreviate it as f(xyz) -> (ABCD).

Take a deep breath.

Sorry I lied to you. If it was as easy as f(xyz) -> (ABCD), then that wouldn't have been fiendishly hard at all. The inverse kinematics equation depends on many more values than just xyz. There are at least 25 other values. So f is better described like this:

f(xyzqwertuiopasdfghjklcvbnm...) -> (ABCD)

Each letter in the qwert...-part corresponds to a configuration value. All these values describe physically measurable things, like the moving unit's weight, the lines' stiffness, the anchors' xyz-locations, the lines' thickness, the spools' radii (including buildup from idle unused line), and the various types of gearing in the system.

The inverse kinematics function f is actually a fairly involved physics-model of your Hangprinter machine. If the model is configured wrong, so that it doesn't match reality, then the movements go wrong in reality. Typically manifestations of an f vs reality mismatch, are non-flat first layers, over-tight or slack lines, and generally horrible printing quality.

Ok Non-linear Bla-bla. But Still: What?

Yeah, we don't want to have you learn all that. The complexity will also continue to increase in the future, just because reality is complicated and we want to develop the inverse kinematics equation further.

How are you supposed to keep up with that? How are we supposed to give efficient support when 50% of users come and say "Hey, all my lines go slack"? Actually, it's probably 75%.

To be honest, configuring the qwert...-values from scratch drives everyone crazy. This is one reason why cable driven robots aren't very frequent out in industry already. Physics is too hard. We need to automate.

✨Solution: Verify✨

It's not enough to just hope configuration is good enough. With my fingers crossed all the time, I get less work done.

The machine must measure its own configuration values, as many as possible at once, and give us some proof that they are indeed correct.

This is now possible, and it works (ok, it has been possible for a while, but it works much better now). It builds upon collecting some simple data, mostly with the machine itself.

Check out auto-calibration-simulation-for-hangprinter, and its simulation.py program.

It works like this: You start with your mounted, but completely unconfigured Hangprinter v4. Put it into torque mode and push it to your desired origin point by hand. You send it a command who teaches the Hangprinter that this is the xyz=0 point from now on.

Next, you measure the line lengths (endpoint to endpoint along the lines) in all the four directions. This teaches your Hangprinter roughly how large it is, and helps you verify config values later on.

Then you locate some known points on your print bed, and one known point that is higher up. This teaches your Hangprinter what "flatness" is and where "upward" is.

Here's a video showing how I pushed my mover around, collecting data at each of the green, known positions.

Animation showing where I collected my first nine data points. Shows best in fullscreen.

Since I use hp-mark, I have known positions all around, but you can create known positions by for example using objects of known sizes, aiming plumbs and similar tools.

Lastly, you collect motor encoder data in lots (~40) of unknown xyz-positions, but with lines still straight but not super tight, thanks to torque mode. This teaches the Hangprinter how a valid, safe position looks like, where no slackness but also no over-tightening happens.

Animation showing where I collected all my data points. Shows best in fullscreen.

If your data was high quality, then the simulation.py program will find good configuration values for you, and tell you exactly how good they are:

In the 44 positions show in the animation above, positional error will be maximum ~2mm, and the line lengths found were ~23 mm different from the hand-measured values, summed over all four directions, so a ca 6mm error in each direction on average. The configuration itself is the three lines of copy/paste-able M669 and M666-commands at the bottom.

Now, why is this a proof and a verification that the inverse kinematic function can work with these configuration values? Because the same inverse kinematics function that run on Hangprinter's controller board also runs inside simulation.py. If it works in simulation.py, together with the reality-check that collected data provides, then it works in the physical Hangprinter as well.

For the time being, collecting all the data and running simulation.py is a bit cumbersome but well documented.

Having a program that tells the user exactly what to do while double and triple checking the data, and running simulation.py in the background, is the next big step in making Hangprinter easier to use. However, all the underlying maths and algorithms are established and working already.

Why Collect All This Data? Why Not Just Use Measurement Tape, Like In the Good Old HP3-Days?

Finding good configuration values based on collected data has three large advantages over hand-measuring everything and hoping for the best:

In addition to this, the approach of simulating Hangprinter gives me many advantages as a developer, allowing me to push Hangprinter technically forwards faster than I would have otherwise.

I Use The Simulation To Double-Check hp-mark's Measurements

Actually, simulation.py gives us an opportunity to check how accurate hp-mark is, and the general direction of its errors.

Click the image for a closer view. This rendering is taken from roughly the hp-mark camera's point of view. The cyan colored points is where hp-mark thought the nozzle was. The red points is where simulation.py thought the nozzle was. We see that cyan and red points generally line up along the camera's depth direction.
Click the image for a closer view. This is the same scene, but rendered from another point of view. The hp-mark camera would be located in the top right corner of this rendering. We see once again that errors are mostly along the depth-direction of the camera. Most often, but not always, the hp-mark position (cyan one) is closer to the camera than the simulation.py measured position (red one).

The idea that hp-mark has measurement errors that are larger along its depth direction makes sense, and suggests that hp-mark must add a second camera before it can create data for the simulation.py configuration automation.

Configuration based on accurate positional data would be significantly faster to acquire, and also more precise than the current procedure. This was the motivation for developing hp-mark in the first place, but as the images above show clearly, we're not there yet.

I Use The Simulation To Double-Check Hangprinter's Forward Kinematics

I've described the function f(xyz) -> (ABCD) and called it the inverse kinematics equation. There's also an inverse of this equation in the Hangprinter's firmware, doing the opposite of f. It's called the forward kinematics equation. Let's call it F and describe it like this:

F(ABCD) -> (xyz)

Developing the function F is as hard as developing f, and I frequently use simulation.py to double-check that changes to F work before putting them into the real Hangprinter firmware.

I Use The Simulation To Check The Quality Of Force-Data

The ODrives are capable of emitting some force data. My investigations have shown that the data is still too crude to be useful for any purpose.

However, once we get accurate force-data, the simulation.py script is prepared to take advantage of it, to give us even faster and more accurate configuration values.

Having All The Equations Coded Up In simulation.py Makes Hangprinter More General

The equations are really a large part of the value that the Hangprinter Project provides to the world. Having them coded up in Python is useful whenever one wants to make a plot or do a quick experiment.

Having them coded up in Python also opens up for easily implementing good Hangprinter support in Klipper or other Python based firmwares in the future.

That was all for today. I hope you will use and enjoy auto-calibration-simulation-for-hangprinter for years to come.

- tobben




Hangprinter v4 and Hangprinter v5

27-3-2022

Hangprinter is a cable-driven robot. HP4 is the latest version.

Goal for HP4 development was to create a reliable workhorse, that people enjoy using, for profit. That sounds a bit like magic. HP4, like any kind of magic, is complex and slow to develop.

I've made a list of HP4's features, as well as some plans for the v5.

🎠 HP4's Unique Features 🎠

That was 12 selling points for HP4. Nine of them are new since HP3. So HP4 is a cosmic upgrade.

🚀 HP5's Planned Upgrades 🚀

So the HP5 will be a big upgrade, although smaller than the HP4 was. Hopefully, HP5 will be designed and tested faster than HP4 was (which took four years).

The HP4 has impressed me and shown very much promise so far. Compared to HP3 it's a dream to use. It has encouraged me to continue along this design path.

I think it's successor, the Hangprinter v5, could become a real winner, a design that's very hard to optimize further, and a good candidate for mass manufacturing. I've written about local design optimums before. I think HP5 could be one.

- tobben




Projects as Subtractive Processes

25-1-2022

Technical projects are often thought of as additive processes. Engineers will often say that they're makers or builders of new products or technologies, adding value to something, or that they're designing a new solution.

Those are all useful ways to describe technology development, but it can also be good to describe projects with subtractive terms, as in "we're removing obstacles". I think I need some of that.

Let's make a little model of (or remove confusion about) projects in general, to explain the image above.

Imagine that every technical project is carving out a hole in a wall that separates a user or consumer from something desirable.

Obstacles can be categorized and layered. Different projects have different kinds and amounts of layers.

Let's look at the lowest layer. Before one starts a project, it's important to learn if the desired outcome conflicts with the laws of physics. Don't start a project where laws of physics stand between your user and success.

So product creation is a subtractive process, removing obstacles between the user and some desirable outcome.

To maximize the field of view for the consumer through the hole, we should shape it like this, ideally:

The field of view metaphor says that the more unknown or fundamental problems should be removed more thoroughly, or require more work per user happiness.

But product creation is a process. We need to plan some steps between start and finish.

The process is often designed to secure sustainable funding throughout the development process, like this:

A well known but ambitious project, like quantum computing or a space mission, will look like a pit dug down from above, at least for the first few years. This shape makes people expect breakthroughs.

An in-house product development or research project, will look more like a cone shape drilling up from below. The shape of invisible ground work. This shape makes people confused and surprised.

The ideal final shape of a hole can also be discussed. A heavily marketed product looks good from afar, like this:

A more niched or indy-style product is invisible from afar, but looks good if you come up close, like this:

I think Hangprinter has become a product with goodness that is almost completely unapproachable, like this:

... Or even this:

Or actually, most of the people that I want to reach haven't even heard about Hangprinter. Like the shape in the first image of this post, with no opening at the top.

Among the hard-to-see and hard-to-use stars in the Hangprinter Project are the line-collision-detector, hp-mark, and auto-calibration-simulation-for-hangprinter.

I'm eager to add other low level features like line force measurements and various kinds of online adaptive algorithms to improve accuracy, precision, speed etc. Really eager.

The subtractive way to look at Hangprinter makes it easier for me to wait, and instead focus more on getting the existing features to fit together. Sticking to what I wrote in the previous Hangprinter newsletter.

Anyways, I hope this home-made toy-model of a project can be useful or entertaining to you. Try it when you need to communicate project status or during project planning. Bye!

- tobben












Links

Hangprinter Campaign: Github Sponsors

Hangprinter Merchandise USA: Spreadshirt.com

Hangprinter Merchandise Sweden: Spreadshirt.se

Hangprinter Project: [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70], [71], [72], [73], [74], [75], [76], [77]

Hangprinter Project Homepage: hangprinter.org

Print Issue Solution Filter Project: [1], [2], [3], [4]

Sourcing RepRappro Mendel in Larvik: [1], [2], [3], [4], [5], [6], [7]

Archive: 2014, 2015, 2016, 2017, 2018, 2020, 2021

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

Forums threads: Hangprinter version 1, Hangprinter version 2, Hangprinter version 3, List of Hangprinter threads

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.