Automated construction

=CEB 3D Printer=

Robotic "crane" for automatically building walls out of CEBs.

"This idea is to develop a robotic system that can build homes from the ground up, literally. Open Source Ecology has developed an open-source tool, the CEB press to make compressed bricks from dirt.   Combining the raw materials, the bricks, with a conveyor belt and large gantry robot (below), homes or structures can be printed out, much like rapid-prototyped designs." -vc_nepo

discussion of the idea in the forum

It's a lot like the Skycam



thoughts on how the CEB printer could work
It seems like a really good bang-for-the-buck approach. A little automation in the right place can be a real force multiplier. My personal interpretation of the GVCS concept is incorporating automation as soon as possible, but not chasing it for its own sake. Running a CEB press automatically makes sense, and so does moving the bricks automatically. Theoretically you could build a structure with just two people. One delivering dirt to the CEB press and the other monitoring the CEB printer's performance. Actually, I should probably clarify that. I don't think it would be worthwhile to make the CEB printer capable of autonomously placing the bricks. I think its highest value is in grabbing the bricks off the CEB press and quickly delivering them to wherever the brick-laying-human is. They could prep the surface while the CEB printer head is traveling, then press a button on it that either releases the brick into their hands or sends the brick to the reject pile. It wouldn't take much code at all if a universal grabber like that coffee balloon jammer was used.

A few accessories would help turn it into a true (semi-) automatic construction system. A tent, mostly supported by the pillars, with a vestibule large enough to cover the CEB press and a big pile of dirt, would allow construction to continue through poor weather (rain, dust, snow, etc). A brick positioner; something that would sit at the end of the CEB press rollers and ready the bricks (lift it up and hold it in position) to be precisely picked up by the CEB printer head, would ensure the lowest possible level of sensor performance was necessary.

Having the print head deliver the brick to within arms reach of a human brick layer seems like it would dramatically simplify the whole system, with parallel cost savings. Not only would the system be able to get by with low-resolution encoders, but it wouldn't need any z-axis rotation or closed-loop positioning sensors. As long as the system can stay calibrated to within about an inch or so for an hour or two of continuous operation the workers could just take a minute to recalibrate it when they take a break. Maybe it would need some buttons on top to manually activate each axis so it can continue to support its own weight without needing sensors to tell if the worker is trying to move it somewhere. Actually, it might be worth making the print head battery operated. The extra weight would only marginally affect the requirements of the pillar motors and it would significantly improve the jamming grabber's ability to squish down around the brick.

Could you send actuation signals to the pillar motors through the metal rope supporting the print head?

Here's how I picture it working:
 * operator positions CEB printer head on top of brick located in brick positioner and switches it on
 * CEB printer head automatically establishes that as the home position
 * operator walks the head, now holding a brick, to the nearest two corners of the foundation slab to calibrate the x/y position
 * operator hits "print" button and print head begins executing g-code (or whatever it uses) loaded into it
 * operator goes to wherever print head is waiting, grabs the brick and hits the "release" button, then fixes the brick in place
 * print head returns to home position and picks up a brick
 * print head continues executing g-code by going to next brick position
 * operator grabs and positions brick
 * repeat

The operation has a natural "pause" point every time the print head delivers a brick to the specified location. Until the operator hits "release" the print head will just wait there, so the operator can inspect a problem, make a phone call, install electrical components, take a piss, whatever and then pick up right where they left off. No need for continuous logical contact with the printer electronics.

This method of interaction would also allow the workers to use the printer as a generic utility crane. They could just manually guide it to pickup and move things. They could also manually program waypoints to create arbitrary, on-the-fly g-code like operations. Hell...you might be able to implement all that without a microcontroller. Well, I suppose interpreting the g-code will always require one, but it definitely wouldn't need to be any more than an Arduino Uno.

Also, the structure automatically lends itself to enclosing the entire work area in a tent of some kind, which will not only help keep the work area clean and dry but also keep the printer components clean and dry. Or the tent could be excluded. If it was included then one or more of the pillars would have to have an extension on it to create a slope in the tent's roof.

So that looks like: * HOME (mark location as source of bricks) * CORNER (mark location as a corner of the workspace) * GRIP (activate the function that secures an item in the crane's gripper) * RELEASE (deactivate the griper) * REJECT (send item to a predefined reject location) * EMERGENCY STOP * WAYPOINT (mark position as a waypoint with option to add a command to be executed at that location (like GRIP or RELEASE)) * joystick with x,y and z variable speed controls (move crane manually)
 * 4 pillars with powerful servo motors and wire rope spools (maybe one motor to position the wire and another to spool it up?)
 * 4 lengths of wire rope long enough to cover the full diagonal of the workspace
 * a crane with a power supply, computer, human interface, and universal grabber

Universal Jamming Gripper
Basically, you put coffee grounds in a bag/balloon and then suck out all the air. It holds on to damned near anything.

"Universal contact grippers with granular vacuum jamming pads provide very high possibilities of grasping irregular shapes, but currently these systems still have speeds and grasp reliability which are too low for normal P&P operations."

overview from Cornell University

video 1 video 2 video 3

Skycam


Skycam's major components: image of reel The cables are kevlar ropes. Steel would be too heavy and dangerous. The winches are driven by 20hp or 4.5hp (depending on the system) motors that can spin up to 3,000rpm The spar weighs about 15kg. "The camera's position is updated 200 times each second by the Overdrive motion control software, which runs on RTLinux..."
 * The Reel: motors that spin spools that control cables
 * The Spar: the camera and support assembly
 * Central Control: the main computer


 * Takes 9 people 4 days to setup
 * The system uses two ropes. One controls x-axis movement and the other y-axis movement. Z-axis movement is controlled by moving both ropes together. Each rope can support the weight of the camera in the event that the other rope breaks.

Quick Aluminum Truss
These are the things used to quickly erect stages and platforms and whatnot. Here are some specifications.

=See Also=

1/4 inch low stretch synthetic rope is $1.50 per foot

comparison of synthetic fiber ropes to steel

=Tiger Stone= The Tiger Stone is sort of a manual 3D printer for cobblestone paths/roads.

