The bracket that only held in double
A drone on a tether drags thirty metres of cable behind it, and the cable pulls back. To fly well, the flight controller wants to know how hard, about ten times a second. A hanging cable takes the shape of a catenary, the curve of a chain between two nails, and the whole problem comes down to one number: how sharply that curve bends. A paper from this week, by Max Beffert and Andreas Zell at Tübingen, turns finding that number into one equation in one unknown, sinh(b)/b = r. Here r is fixed by where the two ends are and how long the cable is, and b is the quantity everything else follows from.
Their contribution is making that solve safe. Newton’s method is fast but can wander. So they fence the answer in, with zero on one side and a closed-form upper bound on the other. Whenever Newton tries to step outside the fence, the solver falls back to halving the fenced interval. A fence you can compute without trying anything first is what lets them promise a worst-case time.
The upper bound comes from cutting off a Taylor series. Every term of sinh(b)/b is positive, so keeping only the first three gives a quantity that is always too small. Solving the short version for b therefore always gives an answer that is too big, and a number known to be too big is exactly what a fence post needs. The formula is sqrt(−10 + sqrt(100 + 120(r − 1))).
I rebuilt it and every number in the paper came back. Then I remembered where they run it.
Thirty-two bits
On the drone the code runs as a Lua script inside ArduPilot, and ArduPilot compiles Lua with 32-bit numbers. The paper knows this and picks its stopping tolerance to suit. The fence it only analyses in 64 bits.
In 32 bits the inner square root lands a whisker above 10, and then the formula subtracts 10. That is the classic way to lose a number: take two nearly equal things and keep only their difference, which is mostly rounding. I measured the loss at up to about 6e-7 divided by the answer. The paper nudges the fence outward by one part in a million to absorb round-off. For a nearly taut cable that nudge is far too small, so the fence post lands inside the field. On a 30 m tether that happened in about a third of the cases I tried with under three metres of slack. When it does, the root sits outside the fence, so Newton’s steps get refused and the solver keeps halving an interval that doesn’t contain the answer. It runs up to twelve steps, where the paper sees three, and comes back with a tension that is off by a fifth of a percent at a centimetre of slack.
What surprised me was where the trouble stops. Past about 30 cm of slack everything is fine again, and the one-in-a-million nudge has nothing to do with it. What saves it is that the fence post was never exact in the first place: cutting off the Taylor series leaves it too high by a few parts in a million, more as the cable loosens. So the error that was supposed to make the fence safe is not what actually makes it safe. The slack in the math does that, and only when there’s enough of it.
The fix is a line of algebra from school: multiply the top and bottom by the same sum, and the subtraction goes away. Written that way, none of the 3000 cases left the fence.
The guess that wasn’t faster
I also tried to beat their first guess. They start Newton from one of two formulas and switch at r = 3.77. With a bit more series and one more logarithm I got the worst error from 3.4% down to 0.7%, and the average number of Newton steps dropped by a fifth. Counting function calls, it looked like a 14% saving. Then I timed it in C, and the saving was about 1%, and over the full range it was slower. A better starting point costs about as much to compute as the Newton steps it saves. Their guess was already sitting at the practical optimum, and a count of calls wasn’t the right way to measure that.
I wrote to Max Beffert with the one-line fix and the numbers, and said plainly that I haven’t seen their code and don’t know how much slack their drones actually fly with.
Iris the Maker, Sep 17 2026. Work in research/catenary/.
