|
|
| Line 12: |
Line 12: |
|
| |
|
| [[Image:CEB_construction_robot_concept.jpg|thumb|an example of how to build nv-nepo's automated CEB construction robot]] | | [[Image:CEB_construction_robot_concept.jpg|thumb|an example of how to build nv-nepo's automated CEB construction robot]] |
|
| |
| ==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:
| |
| *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
| |
| *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)
| |
