Wikihouse Engineering Day
Reflecting on a day of open-source structures and digital workflows
Wikihouse is often seen as an open-source construction kit, a kind of plywood Lego for making your own home, and understandably so. In truth Wikihouse isn’t a single building technology, it’s a common web platform for hosting ANY open-source building system which can be shared as code, from plumbing to doors to whole house types, like the Microhouse.
We began building the Wikihouse eco-system with the first structural technology, and named it ‘WREN’ to pave the way for other technologies to emerge. WREN is the result of thousands of hours of R&D in design and engineering, which can be traced back to the very first Wikihouse in 2011. The Wikihouse Foundation has been conscious of the need to better document and disseminate the engineering knowledge behind WREN, and make it easier for designers and engineers around the world to use, fork and improve it on their own projects.
With this in mind, we recently invited a small group of experts and partners to come together to explore the potential of engineering in open-source construction. The event was kindly hosted by Arup at their London office, and attended by professionals from structural engineering, architecture, academia, programming and manufacturing backgrounds. The day was divided into two distinct halves. The first part examined the principles of Wren and structural testing, while the second half explored engineers’ workflow in a digital supply chain.
Part 1: Testing the Wren System
Wikihouse co-founder Alastair Parvin kicked off events with a brief history of Wikihouse and the Foundation’s intentions to create an open digital supply for construction. Architecture 00 and Momentum Engineering followed this with a presentation of Wikihouse projects currently underway, including a 23 unit scheme in East London, before delving into the details of the WREN system itself.
WREN was developed to enable the self-build of 2–3 storey structures, which make up 95% of housing stock in the UK, using common off-the-shelf material (ie. 18mm plywood sheets) and low-spec CNC routers. The system is based on repeated moment-resisting portal frames, assembled from interlocking Fin and Spacer sub-components to form a rigid box section. The design principles have been compiled into a helpful guide, available on the Wren Github wiki. Momentum explained that while past projects have been designed through theoretical calculations, in order to really push WREN’s development forward, data from physical testing will be crucial.
The attendees broke up into two groups to discuss the structural testing of key components of WREN. The workshop was technically focused on the constraints of physical system and collectively explored the best way to document the methodology. While WREN is composite system, the fundamental element for testing is the Superbox frame. The suggestion was start small and cheap, testing joints in isolation and leave experiments open to be used on a range of testing rigs (in both scale and cost), from suspended weights to hydraulic rams. The point is to repeat each test a lot, and gather as much reliable data as possible. The group helped define the main variables such as length of joints, tolerance, load and duration, while setting constants like the thickness of plywood in the design standards.
The outcome is that each test will be worked through in detail and documentation made available on the Wikihouse website and Wren Github for academics, researchers and enthusiasts to find, test, and repeat. We hope this will also serve as a public repository for all results to be captured and shared back.
Part 2: Digital Engineering Workflows
Following a morning looking at hardware, the event after lunch (kindly provided by Kaffeine) pivoted to focus on software.
We asked the group what new software technologies are emerging that might change the way we communicate, analyse, and regulate? The general perspective was that the current approach BIM is a bit like alloy wheels on a horse and cart; a messy entanglement of proprietary tools bolted on top of a traditional industry. BIM tends to be broad across AEC disciplines at the design stage, but doesn’t run very deep through the supply chain.
As a case study for vertical integration, the Foundation team have prototyped a vertical supply chain for delivering Wikihouses, using an existing tools like collaborative spreadsheet engine and a linked parametric model in Rhino/Grasshopper to automate all the design and fabrication information.
Using this a base reference, the next group workshop asked attendees to map out their current supply chain, workflow and pain points. Were there any elements they felt could or should be automated? The common theme from the discussion was the daily struggle managing overheads, communication between teams, and the lack of certainty around cost implications at the design stage.
This lead into the Wikihouse Foundation team unveiling their central project for 2017: Buildx; a smart digital supply chain for the built environment. A brief demonstration illustrated that the aim is to go beyond BIM, to create a shared and open data environment for designing buildings on the web, integrating files, data and standards across a distributed supply chain of designers, manufacturers and contractors.
With time running out in the day, we asked the group, “How could this ‘open-chain’ could fundamentally improve the way you approach project tasks, liability and business models?” The consensus was that there is a significant opportunity to use rules and open data to instantaneously calculate cost, time, weight, performance, and produce ready-to-go manufacturing information. A big step forward would be reducing overheads and repetitive data transfer which typically slows down tasks and squeezes the scope for design and innovation.
In Reflection
We intend this event to be the first of several focusing on key aspects of Wikihouse, and it was an exciting chance to explore the more technical elements of open-source structure, and create insightful discussion between forward-thinking engineers and designers. For the Wikihouse Foundation it helps give us a clear direction for advancing the Wren system, with a focus on pilot projects, accreditation through property assurance schemes, and structural testing.
We also want to create an opportunity for anyone to contribute their expertise and knowledge to the development of Wikihouse technologies, through something called Open Challenges. These are specific tasks or research areas we’ve identified as milestones for advancing the Wikihouse project and its mission. We currently have 5 Open Challenges listed on the website (with more details coming soon), and encourage contributors to get in touch and help us grow the Wikihouse eco-system.
Likewise if you don’t feel like you have the right skill-set or available time, you can lend your voice to discussions in the Community Slack group, or alternatively support the project directly through a regular donation.
