Okay, our next talk will be from Pieter Himmer.
This will be on automated documentation.
Please give a warm welcome to Pieter.
Yeah.
Thank you for being here and thanks for the great programming because, yeah, my talk really
follows well, follows up well on the last talk.
So my goal for this presentation is to tell you about how to automatically generate IKEA-style
assembly instructions for open source hardware.
So before I do that, let me just explain a little bit about myself.
I've currently just started as a self-employed software developer or slash researcher and
I'm, my target is to make a living in open source software development.
So I'm currently, I've just had my first contract with Ansel that has been talked about before
and this allows me to work on a really nice project in Freca that's close to my heart,
is managing data for models, so improving parametric design.
I'm also a co-founder of the Open Toolchain Foundation, which is a foundation that aims
to support a whole tool chain for going from a design to a physical product and we've
seen great examples for that.
I come from academia, I've been a researcher in the area of high performance computing,
but a couple of years ago I got a chance to work on actually my passion, open source
software and hardware and I was in a project in Hamburg with which, in which my colleagues
from InMachines in Gratia were creating the OpenLabs starter kit.
So the idea was in a span of one year and a half create eight machines for FabLabs,
3D printers, laser cutters, CNC machines and three versions each, so rapid prototyping
so to populate basically FabLabs and all open source hardware.
But of course there is one problem that a documentation we heard about in the last presentation,
so documentation is really crucial for open source hardware, without documentation no
open source hardware.
And it's for replication but also for collaboration informing people how to improve things.
But as we probably all know here documentation is very labor intensive and it's always out
of date essentially.
So related work, there are two basically two approaches document after the fact you design
your machine or whatever you design and you start documenting with the potential problem
that you miss important things to, for example to tell collaborators the design decisions
that you made.
Another basic approach is document while doing but this has the problem that you may
document much more than you actually need.
So in the current state of the art I think in documentation for open source hardware
is git building and a difference with our approach and git building is, git building
is I would say text first, images second and for our approach is images first and we try
to minimize the amount of text.
And that helps us with something that we find very important is a semantic relation between
the source of the hardware, the CAD files and the documentation.
This is difficult to do in, this is difficult to do in if you have text describing a machine
for example.
So our goal for this research was to integrate a design and a documentation process, generate
assembly instructions automatically and support design evolution.
If the design evolves then we hope that we can just push a button and regenerate a manual.
So my colleagues of Ingressia in machines they created the Fabulaiser Mini and they
spent many months with three persons, a graphic designer, a CAD expert and a machine designer
to create a very high quality IKEA style assembly manual, assembly instructions and this was
really nice but also a huge effort and I believe that when the instructions were done it was
already out of date.
So this was our starting point in trying to automate this process.
So an overview of our approach is that we have a CAD file that we annotate in a CAD-like
manner with, for example, with layers and something that we call layer states and we
have a textual specification and the textual specification relates to the CAD source.
I will show you that later on and we combine that information and generate a PDF assembly
instructions.
So we created a dedicated workbench in FreeCAD to help us annotate the CAD file.
So typically for us the input is a step file and for example we have a button that allows
you to select some screws and then you press the button and then they will automatically
explode and show this red line that you can see on the screen.
Another thing to highlight here is that what I circled here is one of the step layers,
step one detail and that is something that we can refer to from the textual specification.
I will show you later.
And another thing is that the window that you see here with the CAD model, we created
essentially a button that allows you to take an SVG screenshot, high quality image of exactly
what you see here and we can remember the camera position.
So you can essentially move and rotate your model and think, okay, this is how I want
to show this in the manual.
You save the camera position and you can generate an SVG image out of it.
So let's go into the textual specification.
At the left we have a domain specific language that helps us describe the manual and at the
right we see the output and we can specify the title and we have a command for a bill
of materials and this is the only thing that we need to specify and then we get the visual
bill of materials that you can see at the left on the assembly instructions.
We can specify which main image we want and what kind of highlight we want and this is
what I ask you to remember step one detail.
So the image that you see here comes directly from that layer state that we defined in the
CAD program.
This is where you can see the semantic relation between the information in the textual specification
and the annotations, the CAD like annotations in the CAD file and everything that is underlined
rats are basically these references into the CAD file and that allows us to create this
page that you see.
So and we also have some annotations, remarks and how to that references a dedicated how
to page that tells you how to do things for example, combine to profiles for example and
we have commands to add tools to the page.
So what was the result?
So hopefully you are of the same opinion that the original and the generated are very similar.
There are some details that are that we don't have the same flexibility as a graphic designer
for example in the text on the top you see there is a red dot in the text.
Well so we cannot create so or we cannot do the same thing because we generate the page
and we just don't have the flexibility.
This is another page and again here is a problem with the flexibility that a graphic designer
has for example in the bottom you can see there are two options for the same for a tool
and that is difficult to do for us when we generate these pages.
So because the original manual was developed over a course of months with three persons
without any time tracking it was really difficult for us to measure scientifically what the
cost benefits in terms of time are but we tried to give at least an indication and we
didn't have the resources to create this whole manual so but on a small model of about six
steps a small vice and a vertical lathe to really create this manual was about 25 minutes
so but it was us who wrote the software so let's make it a factor two I think it's still
pretty good for creating these kinds of manuals.
So in terms of design evolution going from version N to N plus one we heard about this
in the previous talk so minor changes in the model let's say replacing small screws with
smaller ones do not require any action at all you just push the button and the new manual
has been generated.
If the changes are larger then we can show that because of the abstractions that we use
the changes that you have to make are all limited in scope and for example if you make
a larger version then you probably have to zoom out on one of and store that camera position
but after you've done that you can just push the button and it generates the manual again
for you.
So and the biggest change that yeah the biggest change that you can encounter is if you split
up steps assembly steps or you merge them then you basically have to go all over all
these abstractions.
So before I conclude this talk I would like to acknowledge the people that I've worked
with so the co-author of our paper is JC Mariscal Melgar at the Helmut Schmidt University in
Hamburg the team that created this example manual that was a huge inspiration Daniel
Ingressia, Markola and Liana Sayuri Honda of Inmachines Ingressia and so this project
has been funded in the context of the Interfacer project funded by the EU and to make the professional
to make the software a bit more less research software I received some funding from the
NGI-Dubb C OpenCall as part of the Open Know-How project.
So my conclusion is that well our research proposes a novel solution to the documentation
update problem in the collaborative environment of open source hardware so I'm happy to take
any questions.
Hi, thank you for the presentation.
I wish this existed two years ago when I was writing the documentation.
The question is is there the capability to also add a photo or like an external picture
to this tool?
Yeah so we don't prefer photographs because they tend to get out of date so we prefer
to have 3D renders but yeah I think it would be possible to add that to a layer yes it
needs to be customized a bit.
Okay because I do not want to model glue in Frickad when I need to.
Right thank you.
Is there a reason why the steps are explicitly numbered rather than automatically enumerated
because if you add a step two between step one and current step two you need to rename
all the things.
Yes no there is no reason you can name it whatever you want.
We just did this to make clear that these things represent steps but no you're right.
Hi Peter thank you for the great talk.
I can use this not only with Frickad designs but I can use any step file that I have some
step assembly and take this apart or is it limited to Frickad?
No actually it works better with step files than with for example assemblies in Frickad
because for us it was difficult to choose which assembly because there are so many.
But and the hardware designers in our case used Fusion and the CAD expert took the step
file from Fusion, drew in many more things and used Rhino so for us the input was step.
I have one more question.
I saw the point from the camera was in your code so I saw the point from where you're
looking was in the code.
How do you select which part would be taken out like the screws or the hinge?
Is this done by clicking and selecting or how do we do that?
Very good question.
What you do is you have something so the idea is to create layers in Frickad and we have
a layer for parts for each step.
You have your model and you can select things and then these parts will automatically go
into the layer that you just selected and will disappear so this makes it very easy
for you to basically go down your model and select everything in the right step and that's
the basis for the bill of materials.
Then we have layer states that define which layers are on or off and so you can basically
go from one layer state to another layer state and this positioning for example, the positioning
of the screws is also stored in a layer and if you turn that layer on or off it's straight
switches between the actual view, the assembled view or the exploded view so you can switch
very fast between all those views.
The parts are like manually.
The screws are taken out from the transport menu or are they taken out on the transport
menu?
The question is whether the screws are taken out manually or not.
No, it's automatic.
You just select the screw, you hit a button and we can.
So the technique is we take the center of the bounding box, the center of mass for a
screw that is a bit more, well if the screw is here, the hat and there it's a little bit
to the right so we know which direction to take it out so it's automatic.
Okay, thank you very much for the very interesting talk.
Thank you.