The actuator is a genius flexure design that is both mechanically simple and accurate. Breaking Taps 3d-prints a working replica and describes the design. I highly recommend: https://youtu.be/5MxH1sfJLBQ
The actuator breaking wasn't as concerning after seeing the design.
Thank you for the link, that was incredibly interesting. For other people following the link: don't miss out on going into the comment section and finding the original designer of the mechanism complimenting the video and then sharing his own original model - in Legos!
Slightly exaggerated paraphrase: "You YouTube kids with your fancy 3D printers, here at Ball Aerospace & Technology we didn't need all that, we had Legos"
Thanks for the video, flexure-based designs can be so beautiful.
It reminded me of a collaboration I had with a small Swiss company that did wonders with electro-discharge machining such as this flexure-based mechanism machined from a single block of aluminium:
https://i.imgur.com/PDAVDmJ.jpg
Thanks for that video and channel. See what you mean about simple and accurate, strongly agree with the presenter calling it genius. Can't help but feel there is a strong lesson in there for software people.
> Can't help but feel there is a strong lesson in there for software people.
Hmm, can you elaborate on that? What is the strong lesson for software people specifically?
Don’t get me wrong it is a beautiful design, and I’m a big fan of flexure designes in general. There is this amazing open source project which uses similar flexure mechanisms for very accurate positioning of microscope samples: https://openflexure.org/
But I fail to see any obvious takeaways which would generalise to software development. Other than perhaps “Think and work on the same problem for a decade and more and you might find a compact and elegant solution.” Which is nice, when one has that luxury.
We tend to make complex solutions to simple problems.
The thing about any problem, is that "the devil is in the details." It may seem simple, from a high level, but, once we start to "drill down" into the issue, the "rough edges" appear.
At that point, we start to break out the baling wire and bubblegum, to kludge our original "graceful" design to meet the facts on the ground.
It doesn't just happen for software. Hardware suffers from the same issue, but software makes it easy to start coding before modeling the requirements and context completely.
I actually leverage this, in my own work. I call it "Evolutionary Design"[0]. It's not for the faint of heart, because a big part of it is recognizing when I'm rabbitholing, and tossing out what may be weeks of code, wholesale. I'm actually going through that process right now, with the app I'm developing. I'm working on the final feature set.
"There's always an easy solution to every human problem; Neat, plausible and wrong."
"The fact that I have no remedy for all the sorrows of the world is no reason for my accepting yours. It simply supports the strong probability that yours is a fake."
-- H. L. Mencken
“When the map and the terrain disagree; believe the terrain.”
The takeaways are limited, IMHO. Yes, in software engineering ingenious, simple, sometimes a bit crude solutions exist and can solve otherwise complex problems. More often than not, overly complicated, endless stacks of abstractions are developed to solve relatively trivial problems. But, software engineering is usually about maintaining something as part of a larger, dynamic, distributed system (comprised of humans, other tech) and reliance of brilliance is a limiting factor, since brilliant engineers rarely want to support their creations for years. With age, I am growing more and more tolerant of bloated, verbose, boring code that can be passed from one individual to another without too much trouble.
I think the actuator is an equivalent of a very clever Perl one liner.
Very cool. I know nothing about these types of actuators but you're right that they seem pretty robust. When I heard actuators I was thinking of the common types that definitely don't last forever :)
Unrelated: reaction wheel assemblies (used for attitude control) typically would have one extra wheel as a "spare." Redundancy is important enough on spacecraft you expect it wherever it is practicable. I used to work in aerospace - spent enough time coding spacecraft simulation tools that I had to develop at least a working familiarity with how some of the common satellite bus systems are supposed to work :)
The actuator breaking wasn't as concerning after seeing the design.