Boffins build sticky-limbed lizard-bots to tend spacecraft Researchers with the European Space Agency (ESA) have developed a class of robots which could one day grace the outside of orbiting spacecraft. Dubbed "Abigaille", the robot family uses a dry-adhesive material to cling to structures and move along surfaces even in extreme conditions such as space travel. According to …
Even at X8 speed-up on the video it is painfully slow and it looses a third of it's adhesion when navigating the inside of a 90 degree turn. Could it even navigate an external 90 degree turn which is the more likely on the outside of a craft?
At least the power cord can be used to haul it back in when it falls off, well providing it hasn't snagged it or wound it around some exterior protuberance.
Easier and and cheaper to just build in redundancy for the craft than waste the payload mass of this thing, it's power supply and controller unit.
Well, to be fair to the robot, we haven't yet put anything in space that isn't painfully slow. Even equipment like the Canadarm and Canadarm 2 operate near molasses speed. Watching Humans work in space is quite simply infuriating. Years ago we watched hundreds of hours of spacewalk and deep sea diving footage for a project and after the first few days I was ready to hurl myself out the window.
In my mind everything in space zips around really fast, but smoothly, accompanied by that neat high pitched servo sound from the movies. But the fact of the matter is that even the very pinnacle of Human technology is pushed nearly to its limits just being in space to begin with.
In the vast majority of applications there is a direct correlation between reliability and speed: As things speed up, the likelihood of failure increases proportionate to speed. Down here on Earth those failures can generally be managed through maintenance and/or the replacement of parts. In space, just sending the service truck up costs millions of dollars and that assumes spare parts even exist. Routine maintenance in space isn't even a thing. With that in mind, the path of prudence is to maximize reliability and sacrifice speed.
That being said, knowing why things are the way they are doesn't help much does it :)
Oh yeah, on redundancy.
You can't design effective (in either terms of cost or functionality) redundant systems unless you know, with some certainty, where, what and why failure is likely to occur. With spacecraft we simply don't have enough knowledge to make those decisions. Failure analysis, a requisite part of redundant systems design, is more like 'failure guessing' as the failure states are either spectacularly catastrophic or occur so far away it is unreasonable to go examine the failures. Aircraft and ships have effective redundant systems because we've seen and examined nearly every possible failure state. We know what's going to break.
Without that knowledge you are violating a core engineering principal by introducing complexity for no discernible benefit. Attempting to engineer around an unknown increases the likelihood of failure, not to mention the overall cost increase (redundancy costs don't scale like creation/build costs, it's vastly more expensive).
There's also the extremely tricky part of redundant mechanical systems. In an electronic system you can build in scads of redundancy fairly cheaply because nothing is moving around. It's there, if it breaks just bypass it 'here', everything is on the board. With mechanical systems you've actually got to build two new systems for each redundant system.
You've got to have the actual redundant system, obviously, but you've got to have another system in between each primary and redundant system. The go between systems that manage available resources. Let's use a simple liquid cooling system as an example:
You've detected a pressure loss on the high side of the system so you want to stop the coolant pump and capture the coolant still in the low side but then you've got to transfer that coolant to your redundant system so you need another, completely different type of pump and control system between the primary and redundant systems because the cooling system itself can't operate without being 'charged' (primed/pressurized) first.
Simultaneously, you've had to shut down any other temperature sensitive systems until the redundant system comes online, but we'll skip all those complications.
So you've transferred the coolant to the backup system, but how much coolant is there? How much was lost? Which systems can be throttled down and still function properly and which have to be taken offline indefinitely? How is overall craft functionality affected by the new conditions and where do you set new operational parameters to reflect the new conditions? Lastly, do you make the redundancy management system itself redundant? There's a whole fuckton of questions there and the answer to each requires at least one sensor and processing capacity that asses the sensor output in context of the craft as a whole.
TL;DR, you can't make everything redundant, and you've got to know what and how to create redundancy. The existence of redundant systems actually increases the probability of a failure due to complexity and interdependence on resource management systems. Redundandancy is never as good, or as cheap, as robust design and resilient engineering.
"Aircraft and ships have effective redundant systems because we've seen and examined nearly every possible failure state. We know what's going to break."
Seems a bit counter intuitive that if you know what's going to break you'd add a second one rather than re-engineer it it to not break...
Well, sure, in an ideal world you'd reengineer things that were found to be prone to failure, but both financial and technical restraints often prevent reengineering from being viable.
As an audience relevant example, consider hot swappable power supplies in servers. It's pretty much guaranteed you'll lose power supplies so they build in a redundant power supply system. It's far cheaper to keep replacing power supplies than to go reengineering a product that works passably well in millions of servers.
It's the same way with many other systems. You know what will fail, and how, and can compensate for that with a redundant system. If you were to reengineer the system/component you'd be introducing new unknowns and potentially building redundant systems for that instead. You're sacrificing known and manageable problems for lots of unknowns.
When engineering a system, any system, the key to success is reducing variables, not trying to build something that never breaks, that's impossible. A virtue of well engineered system is that it breaks in expected ways that can be managed. Increasing the variables by introducing unknowns is a quick way to destroy something that once worked well.
Since this thing is meant to operate in free fall, why not make the legs very long, with several joints? Then it's easy for the feet to reach a variety of nice anchor points and the travel speed would be a lot higher. For operations requiring torque, just lower the main body and attach it with some stubby feet, then employ a strong servo arm.
The main body would stay far away from station clutter, with a good view of everything too. And turning corners would be no problem.
Also it would be a lot closer in appearance to those space spiders!
"That makes the robot itself bigger and makes for more small parts having to carry a lot of load as it moves, making it more likely to break. I expect it would also make dealing with the recoil of taking a pad off the surface harder, but IANAE"
I thought of that too, but there's this:
"Geckos' toes seem to be "double jointed", but this is a misnomer. Their toes actually bend in the opposite direction from human fingers and toes. This allows them to overcome the van der Waals force by peeling their toes off surfaces from the tips inward."
http://en.wikipedia.org/wiki/Gecko
So I envision a robot with long slender legs that have minimal strength. The pads have these backward bending toes which can be actuated via a strong wire running inside the leg and reeled in from the main body. All the wires can be pulled via the same motor/drum by splitting the drum into six (or eight) sections, with a sliding drive axle that's keyed to engage only one section at a time. Almost off-the-shelf stuff.
The main body doesn't have to be large, since even a thin weak leg can move it around in free fall, given a little time to apply torque. It's analagous to the shuttle's robot arm. Not really quick I admit, but still faster than that agonizingly slow gadget they got now!
Your mention of anchor points reminded me of something. Some of the very early conceptual drafts of the ISS had the station inside an enormous aerotrim, the rings of which were tracks facing the interior, toward the station.
The idea was that small dollies ran on the tracks and could be placed in nearly any position around the station by moving the rings around. They even had task specific machines that bolted onto the dollies, basically eliminating the need for live people outside the station and simplifying the overall design because the repair machine itself only had to move in one axis: Toward the station.
Obviously, the ISS does not have such a system. I suppose it was too expensive to implement properly. It sure did look neat though. I think I'll go looking for those sketches, they've got to be out there somewhere.
Thanks for the reminder Don! I had forgotten all about that.
Another design of the ISS that was abandoned due to cost was that is was supposed to be 2 parallel tubes for the main core, the design of which even made it as far as the first ground training facility of which I had the honor of being inside twice.
Could the Bot not fire additional anchor points and use these to transverse from one point to another as well as using the limbs for slow movement i.e its fires an temporary anchor point to another section of the station and once tested as firm the Bot could set an anchor point then use the two[or more] wires to traverse the gap.So more akin to a spider traversing its webbing.
"So more akin to a spider traversing its webbing."
You're halfway there. What about slapping a few thin 'king posts' all over the station that stick out a ways, with thin wires running from station points to post ends and between posts too? Then a bot could reach out to the nearest wire and pulley along it, switiching wires as necessary until arriving at the target point. All parts of the station are easy to inspect and reach with no possible damage along the way.
Of course you'd need a bot to rig the whole thing...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
