After all, it's a relatively simple stereotyped repetitive task that's common. The same with cement-block walls. Attempts have been made for over a century, none so far have been fully successful, though in recent years we've seen some partial successes. See Brian Potter, Where Are The Robotic Bricklayers?
On why the task is so difficult to automate:
There seems to be a few factors at work. One is the fact that a brick or block isn’t simply set down on a solid surface, but is set on top of a thin layer of mortar, which is a mixture of water, sand, and cementitious material. Mortar has sort of complex physical properties - it’s a non-newtonian fluid, and it’s viscosity increases when it’s moved or shaken. This makes it difficult to apply in a purely mechanical, deterministic way (and also probably makes it difficult for masons to explain what they’re doing - watching them place it you can see lots of complex little motions, and the mortar behaving in sort of strange not-quite-liquid but not-quite-solid ways). And since mortar is a jobsite-mixed material, there will be variation in it’s properties from batch to batch.
Masonry machines have constantly struggled with the mortar aspect of masonry; many of them simply ignored the aspect of the problem. The academic studies of the late 80s and early 90s were often based on using mortarless walls, wall systems that don’t require mortar joints (such as surface bonded masonry), or mortar alternatives that behaved a little more predictably (which is what Hadrian ended up using). In his 1996 paper, Pritschow comes right out and says that trying to solve the problem of handling mortar is too difficult. The folks that have figured out how to reliably apply mortar still can’t quite manage to produce a clean mortar joint - they simply slather the mortar on there, requiring workers to follow behind and clean it up. In some ways efforts like SAM don’t look all that different from the 50-year-old Motor Mason in this regard.
Mortar joints make setting blocks more complicated. Whereas a nailgun can apply force to a nail and get a fairly uniform result every time (and if it can’t, it’s not critical - a nail will still function if its driven slightly askew), setting a block on a layer of field-mixed non-newtonian fluid isn’t so forgiving. Without some feedback from the environment (measuring the levelness of the block that’s been set), it’s hard to be sure that the wall is being built level. Human masons are constantly checking the levelness of their blocks with strings or field levels to ensure the wall remains true as it gets built, and making slight adjustments as needed; a mechanical mason needs some way to do the same. SAM seems to have MOSTLY solved this problem, but every so often still needs the workers following behind to tap the blocks level.
This is one of the main things that separates driving a nail from setting a block - the necessity of making adjustments based on feedback from the environment. Things like nailguns, circular saws, and other power tools are in some sense more like the masonry assistants - they perform some purely physical task, while leaving all the information processing and precise placement work in the hands of humans. A nailgun isn’t responsible for figuring out where a nail needs to go, and moving itself into position - it simply does the physical task of striking the nail.
The history of routers and milling machines offers an instructive parallel. The first ones were developed in the late 1800s/early 1900s, and the capability for programmatically controlling them was developed in the late 40s/early 50s. But it’s only recently where we’ve had the capability of incorporating real-time feedback, enabling products like the Shaper Origin (a handheld router that autocorrects human movements ). Robustly getting a machine to react based on its surrounding environment remains a complex problem, even if the machine is physically capable of doing it.
There are other problems as well.
The article ends with a brief and non-commital discussion of if and whether or not we'll see routine mechanized masonry and other construction tasks.
This comment is interesting:
Samuel Regan, Aug 3
The idea that the issues with the systems come from trying to automate a manual task is my main takeaway. In my field of manufacturing automation, I've seen quite a few projects where a human operator was straight swapped for a robot run into numerous problems and end up slower and less efficient. The incentive to do this is often quite obvious, the cost to replace a work cell can be extremely expensive and redesigning a system is hard, but in the end, a process that has been tailored to the strengths of a human operator causes far too many problems for a robot.
I'm sure future masonry automation projects that are successful will do so because they are happy to move away from standard bricklaying processes to utilise the strengths of robots such as their lifting capacity and accuracy. Perhaps future systems will use larger interlocking bricks or prefabricated wall segments.
On the whole I'm left with the impression that in robotics, automation, and purely informatic AI we face vast space of possibilities which we have been exploring with varying degrees of success in the last 3/4s of a century or so. Dealing with the physical world is tricky in ways that are often hard to foresee until we actually attempt to do so. For that and other reasons estimating the probabilities and possibilities of success is proving difficult. We've still got a lot more exploring to do before we understand the space very well. Until then, we muck along, sometimes succeeding in unexpected ways, other times failing where we thought success was certain.
No comments:
Post a Comment