All right, welcome back to the open hardware and CAD-CAM Devroom at FallsDem26.
Next up, we have Julian, who is many, many things, but I think he is most known for his work
on the open flexure microscope.
Right, hi everyone.
So I'm glad to have bid Mike back again this year.
We gave a talk last year in this room about the open flexure microscope.
I thought we'd delve a bit deeper into how we do the documentation,
the validation.
I'm so glad that people actually turned up for a talk with documentation
and validation in the title.
You'll also see at the bottom the humanitarian technology trust.
So in the last year we've set up a UK non-profit,
so we can push forward a lot of our humanitarian goals for building microscopes.
So just for an idea of how much people know how many people were here
at my talk last year.
Well, a few people in for more.
How many people have heard of the open flexure microscope?
Nice.
How many people have an open flexure microscope?
Yeah, pretty good.
How many people were too scared to put their hand up?
None.
Ah, one.
Okay, good.
So, normally we start with microscopy for everyone.
And you start thinking, well, those people go, what?
Does everyone really need a microscope?
I don't think everyone needs a microscope.
Why would everyone need a microscope?
And it's not the microscopes for everyone, but microscopy.
So, while you might not want a microscope,
you would be really sad if your local hospital did not have any microscopes.
If the people let check your water quality, do not have microscopes,
it's important that everybody has microscopy available for what is happening in their life.
So, particular microscopy is the gold standard for many diagnosis.
Cancer diagnosis, malaria diagnosis, number of other diseases.
And the survival rates are so much higher if you catch it early.
So, malaria is almost 100% curate if you catch it early enough
and treat it appropriately.
It's still half a million people die every year from malaria.
And that's predominantly children on the age of five and subsaharan Africa.
So, here we've got a picture of Dr. Elisa.
He's got a manual microscope there.
He's looking at biopsies, looking for a cancer diagnosis.
They've got one manual microscope.
Now, if he is the only hystropophologist in his area of Rwanda,
if he wants to have a discussion about a difficult case,
he does not have that option.
So, I think in the UK for most cancer diagnosis,
you need two hystropophologists to both agree because it's so hard to diagnose.
So, how does he build up that ability to see these difficult cases
without the conversations with his peers?
Now, we're in a place where inequalities are widening.
So, sure, you can get big digital equipment
that can scan the entire slide.
But, you go to a conference now.
Have a conference.
Guess what everyone's talking about.
AI.
Yes.
So, everything is AI.
But, if you're now in Dr. Elisa's lab,
you don't have one of these microscope that can scan the entire sample.
So, you're now left behind from that.
And we can't exactly just buy one of these and just stick it anywhere,
because it will assume it has perfect stable power.
It's not going to run off a USB power bank.
It probably assumes it's in air condition.
It doesn't like humidity.
Certain things need proprietary consumables.
I'm not sure about this one.
So, we actually end up in a situation where we can't just throw money at the problem.
Donating medical equipment is something that people think of a lot.
But, between ten and thirty percent of medical equipment
that is donated to sub-Saharan Africa is used once.
Just once.
That's because people, you might send it without the instructions.
You might send it.
It's not in the local language.
It needs training.
There's proprietary consumables.
You get something working.
And then what happens.
So, this is also in Dr. Elisa's lab.
This is a tissue processor.
It's not working.
It's currently not working because there's probably one little thing
wrong with it.
But, no one's going to send you a troubleshooting guide
and some spare parts.
They want the company engineer to fly over.
If you don't have a company engineer,
close by and you're paying for a long haul flight.
A lot of companies with long haul flights want them to be business class.
You have to pay for a long haul business class flight.
It might cost more to get something mended than to get a new one.
So, if somebody is giving you money to get new equipment
and they're not giving you a service contract,
then how are you going to keep it running?
The answer is, most of our tissue processing is a machine
that dips things in containers.
So, you have containers and a guide with a stopwatch
and that is now the process that is being used in the lab.
So, back to microscopes.
Why don't we just build them locally?
If we build them locally, they can be supported locally.
That's the best thing to do.
How hard can it really be to build a microscope?
I mean, you just sort of need to move something around the optics fairly easy.
Now, traditional dovetails have to be machine really smooth,
otherwise they sort of stick and slip and slip and slip
and you can't do the fine motion you need.
But actually, if you 3D print some plastic
and make some thin bits, it bends at the thin bits.
That doesn't have any of those problems.
You then go, well, 3D printers give you this ability
to print weird shapes.
Each of these red dots is basically a hinge.
This is an early prototype of the microscope.
And now suddenly you've got, this is the next wide translation stage.
You can add in a z.
And you then need a camera, a couple of bits of optics.
Boom, you've got a microscope.
So, it's an open flexion microscope.
Now, can everyone build a microscope?
Yeah.
So, why can't they build a microscope?
Well, open hardware itself is a really hard thing to do.
So, think about open source.
Open source, we always normally think about open source software.
What is your source is really easy.
Here are my code files.
I put them in its open source.
But with a CAD, it might be giving me problems this time.
I'm going to have normal mic.
So, yeah, we can have a repository of CAD files.
Sorry.
Can you still hear me?
Yeah, right.
We can have a repository full of CAD files.
But that is pretty painful because if people don't have the CAD package,
know how to use it, people have different CAD packages.
Trying to actually build each of those files really painful.
We could just wing all the step files or SDL files into a repository.
That's not actually open.
People can't continue to work on it.
Final solution is put both of them in there.
And then your repository gets enormous.
And it's really hard to work with.
Also, documentation.
You need pictures of each step.
So, people can understand what's happening.
You need words, especially for different, difficult things.
This is how you do things thinking about troubleshooting.
As you go through it, you need to build a materials.
And they need to be up to date.
If you're doing open source properly, you're continuously iterating on the design.
And the number of times that you change something.
And then need to think about how do I change the documentation.
Ah, well, this is back from a different time.
So, here is some early open flagship documentation.
Please get all of these parts.
Put them together.
And then, and you get a message saying,
Mind didn't turn green.
Was mine meant to turn green?
Well, no, it doesn't need to turn green.
That's just a photo from a different time.
Normally, we didn't quite get it.
It doesn't turn green.
But, oh, I think it's a different part.
These motor logs have gone.
I actually go through the documentation.
It was going from red with motor logs to green to red again to green.
And everything that we're actually doing there is perfectly explained.
Because nothing has actually changed that you're doing.
But anything in the background that's changed,
if you're not sure what you're building, it's confusing.
But, if you write really good documentation with 3,400 photos,
and somebody says, can I change this bit?
Oh, I'm not taking 400 new photos.
You can change that bit if you take 400 new photos.
So, why else is open hardware?
Because of atoms.
Atoms are very problematic.
You need the correct ones, and you need them in the correct places.
And so, you have to work out, what are you even calling different things?
So, great thing about software.
You build it somewhere in a Docker container.
Somebody clicks a button.
They've got the software.
That means if somebody wants to contribute,
it's quite easy to get up to scratch.
You want to contribute to a hardware project.
You need to get all the bits of hardware.
So, first of all, you've got to buy all the parts.
You've got to put the bill of materials and source everything.
And you get to weird problem of naming.
Anyone know what this is called.
Robscrew.
Great.
It is a grub screw.
So, here we have a grub screw.
Anyone American?
What's it called?
It's a set screw.
Thank you.
So, this is a set screw.
So, kind of confusing.
So, maybe I should just write set screw,
because we can look that up.
However, in the UK, this is a set screw.
Because you can use it to set a thing in a place.
So, now, how do you actually do it?
I can say that what I want you to buy is a DIN 933.
Because then it's really, really, really specific.
And no one knows what you're talking about.
So, the other reason why it's so hard is collaboration.
You've got different collaboration.
How do you do the collaboration tools?
We've got collaboration tools that work so well for software,
but for hardware, most of the collaboration tools
have business in mind.
You're talking like tens of thousands of euros per seat per year.
And if that is the barrier to entry to your open hardware project,
it's not that open.
So, talk a little bit about that later,
but how are we doing things now with open flexure?
So, in our repository, we entirely use open scad.
Only open scad files are in the repository.
All of the STLs are generated in CI.
Does everyone know what I mean by CI?
Basically, you, every time we push something to the Git repository,
something starts up in the server,
and it builds every single STL.
So, as zip of STLs appears,
they're the files that go on the printer,
but we don't have any of them in the repository.
That way, I know that if somebody changes something,
they're all always up to that.
So, I put this picture in that we had last year.
One thing we can do if they're being built in CI
is we can even put the Git hash on the side,
so as you're working towards medical device quality,
you've actually got traceability of you know exactly
what version the source code was
when you made that particular file.
The other thing we have is no photos.
This way, we don't have to retake any photos.
So, open scad didn't actually have an assembly thing,
so we had to build a bunch of assembly tools in open scad,
set up some rendering.
We have a rendering script, so now I have this particular picture
we're putting in a sample clip,
but I have multiple variations of the microscope.
I have the one where the slightly different lens here,
or there's an upright one,
or the low cost one where the low cost camera.
Everything or one of these is completely consistent,
so then we only have to write the CAD once,
we've got code switches in it,
of which one are you building,
you create the optics assembly,
put the optics assembly in place,
and you run through each iteration,
which means that with four variations of the design,
we can have all of the assembly instructions,
always up to date, and entirely consistent.
Because before that,
I don't know if anyone had those books,
so it was make your own adventure books that used to have us kids.
That was what our early documentation was like,
it was brilliant, you get to it,
why are you building the low cost one,
or the one without the feet,
unless it is the third Thursday of the month,
in which case this, if you do pick up this,
unless it's impossible to go through it,
so having one perfectly standard,
this is the microscope that I'm building,
and all of the pictures consistent is enabled by this,
but it's only enabled by this,
if we have a platform that can actually mean that we don't have to write
those bits of text multiple times,
so we've written a program called GetBuilding,
so it's our own documentation program,
where we can write snippets of Markdown,
or we can hold bits of Markdown.
Inside it, we have tagged parts,
so when you use one, you say,
I'm using four screws,
and then when you use more screws later,
it adds them up, but if you're putting in
different sections for different variations,
the microscope, each of them then has a consistent
bill of the materials, each of them has a consistent set of photos,
and we're not maintaining multiple copies of the same text.
If you want to learn more about GetBuilding,
there is a QR code here to my talk at Fastdown in 2022,
some things have changed since then,
but you get a better idea of what it's there.
So, I then write a sentence,
automation enables process,
and I felt I'd become very corporate,
but I feel automation has enabled us to do something
that we would have not been able to do without it.
So, I did my whole presentation in a way of framework,
so I could have better everything,
and then GitLab gave me security warnings about iFrame,
so I can't.
So, this is where we test if the internet is working during my talk,
if it's not, I'm going to do the rest with interpreter dance.
Oh, you're lucky.
Right.
So,
so,
we've now got a process for knowing what happens
whenever we change the design, which is so important for doing hardware well.
So here, William,
once to make sure that the range of motion is working fine,
we've found a couple of places where if you move to one side,
we manage to crash part of the stage into something else.
So, what embarrassing that we didn't find this earlier?
But rather than William just saying,
okay, I want to make the change.
This is what I've done.
We've got, of course,
all of the particular changes to the code,
and this is one thing that's so nice about a code-based cat,
as we can actually see the diffs through,
of exactly what's changing,
and we didn't have to redraw anything.
But William showing me that the legs were crashing.
He first cut something out.
We had a discussion,
decided that we'd maybe cut too much out.
There's some pictures of different parts of it.
But as we go down,
we can see we've got our checklist of what we're going to do before we merge it.
We have a CI that I'll come back to in a little bit.
But all the way through,
we've got our whole conversation about
what is happening,
why we're making these decisions.
We can put cutaways from it,
decide what we're doing as we go through.
But my favorite thing about this,
so we can see in the CI that we first,
we do a silly version check thing.
We then do some linting that we vote for open-scad.
We have a spell checker because if anyone has worked with me,
you'll know that if we have documentation with that spell checker,
it's terrible.
We build all of the SDLs.
We render all of the files.
We build 3DGLTFs,
so we can spin them around and see different things.
We do a check for the SDLs and check some hashes,
and then finally we build the documentation.
But that means in the merge request,
I know that each of those things have passed
and all the SDLs have been built.
And if I want to build Williams Modified Microscope,
I click this button that says View App.
This is the documentation,
not now of the open-flicture project,
but if I accept this merge request,
every single place, if I go in,
if I zoom in on a particular part,
I will be able to see those little bits that I cut out.
I can go to Build the Microscope,
I can go to Print the Parts,
and if I find where it says MainBuddy,
this is loading over the Wi-Fi,
the MainBuddy with those little cutouts,
I can download it, I can print it.
And this means that I know exactly what is going to be merged,
and I can check everything from the documentation
through to the final files.
What I found really interesting the other day
is William was talking to me.
He's done most of the documentation for the last two years.
And he went,
I'm really going to need to get the Render Script
to work on my own computer one day.
And what you've been doing this for two years is like,
I've never needed to actually run it.
And you're almost going to the point where
I start using somebody's professional cab tool
to use this and you're like,
okay, yeah, yeah.
And there's like, right,
so then, no, you have to do that on your own computer.
What am I, a peasant?
But you know, we've got a cloud.
It's so anyway.
But having this process allows us not only to document
everything that is happening,
but also to make sure that we do all of the quality checks
for hardware.
Anyone who does a lot of software engineering goes,
yeah, this is normal.
But it's a tool chain that we've had to build ourselves.
And it's been enabled because we're using entirely open source
top to bottom tool chain of tools.
Back to a presentation.
So also enables collaboration.
I've got one more URL for you.
I apologize it's another merger question.
But this is something that I thought was particularly brilliant.
We had somebody joining the project and they started trying to
change something in the build system.
And I kept saying, oh, I don't want to change that right now.
Eventually, they got a little bit upset and, you know,
why am I not letting people from the community change things?
And it's one thing where it's really hard as a project
to explain your process.
You know, it's not that we don't want collaboration,
but just that we've got certain places where we are going towards.
So in this case, I said, these changes are needed for the Delta stage,
which is a different version of the microscope.
And actually, I have a release checklist of what I'd like to do
to finally release version seven.
Florian turned out to be one of the greatest people in the world.
He then started doing the things that I hadn't got
around to on my release checklist.
And one of them, we were talking for a while.
And I was saying that there is one place where we're still tapping
the machine screws into plastic.
And I just needed to get rid of it.
And I didn't know how to do it.
If you try and put it in from the front, it would break.
And I think I mentioned on the forum at some point that
if anyone ever fixed it, I would buy them a bottle of wine.
So I particularly like, we have this merger question, Florian,
where the branch name is, why?
But, Florian has gone through it.
And you can see there is an enormous number of different questions
back and forth.
These are the nut traps he made of how we go through.
How it will affect different versions of a testing,
gearing.
We've got lots of conversations going through.
And we managed to work through something which, for years,
a number of us who are very close to the project had failed to do
because we had an idea of how we were going to do it.
And it didn't quite work.
Somebody came in from the outside.
It looked at it.
Thought of a much better idea for how to do it.
Of course, to actually get it merged, involved us,
making sure that all of this worked across different branches.
And other things, it was quite a long process.
But it's considerable upgrade to the microscope.
And I think the point I'm trying to make here is,
we've had a lot of things in the news recently with,
you know, process saying the open hardware community
doesn't contribute back to hardware.
I think we just need to accept that hardware is hard.
And therefore, if you want somebody to become part of your project,
it is a long term thing.
So I talked about community.
What I always think with building the community around the project,
when you first start a project, and especially one,
if it's a hardware project, it takes a long time for people
to actually get the hardware and start building it.
No one's going to be able to join your community,
unless they can see what you're doing.
But it's also very weird to go to GitLab,
and write your to-do list in the third eye we need to do this,
and write everything out when you do it, respond to yourself.
Are you basically feel like you're shouting into the void?
But then at some point, there's enough information there
that the void starts to shout back to you.
And so now, we started at one point just asking,
hey, if you build a microscope, please tell us where you are,
and we'll color it in on a map.
So obviously, this doesn't give a good idea of the distribution.
There might be one microscope in Antarctica,
has a lot more influence on a map than 30 microscopes in Singapore.
But having this, the fact that it's people feeding back means
we've got all these wonderful stories of different things
that different people are doing around the world with the microscope.
And so, if anyone on here from a country that's still gray,
get on it.
So, where are we up to now?
We're really happy we were recommended by the World Health Organization
in a report on innovative healthcare technologies
for low resale settings.
Thank you.
In tiny design for local manufacturer and local repair,
it is a robotic microscope that can move around.
I didn't do the live demo this year.
I had an advantage that I wrote the abstract of what we were going to do
and I decided Joe would do the live demo.
This year, you can go over, we're in a W building,
we've got a number of microscopes scanning.
And so, once we scan a sample and stitch it together,
we get something, so this is a papsmith,
if you were screening for cervical cancer,
we can see into individual cells,
and we can zoom right out to about 600 images.
Almost a giga pixel, done a couple of thousand images.
We get around two giga pixels,
when you have more than two to the 16 pixels across
and JPEG as a format breaks.
We've managed to do a bit bigger than what JPEG can do.
We realize that we can actually stitch JPEGs together
on a two gig Raspberry Pi that a two gig Raspberry Pi
cannot open, but we've got a deep zoom viewer as well,
but people quite like having a JPEG.
So, everything there is open source.
This is mostly a slide that I put in for people
that don't really know what open source is,
so I'm not sure I left it in my first demo talk,
but it is open from all points.
The software is open, the hardware is open,
but also building the knowledge of how you build and understand
a microscope is such an important part of the project
to make sure all of the knowledge is open.
And if we have the knowledge open enough,
we can enable local production and local innovation,
because everywhere, you have slightly different challenges.
Local innovators will always be better
at understanding the problems in their community
and fixing those issues.
And local ownership stops one,
the flow of resources out of the country,
but also means we can never turn off the lights
and say you please stop doing this.
If it's locally certified as a medical product,
then you can have local support and local maintenance.
So what's next for us?
We're working, so we've set up a UK charity,
we're working with medical centres,
collect the clinical evidence of how it works,
working on the productisation,
making sure the quality control of the software,
the hardware, how we document things is better,
working on knowledge transfer, capacity building,
documentation is a funny thing.
If you don't have good assembly manuals,
no one tells you you don't have a good user manual,
because they can't assemble it.
As soon as they assemble it,
they start going away as they use a manual in the car.
So you write the user manual,
and they start using a lot,
I've used it so much,
I need a maintenance manual.
Every time you do anything,
you need more manuals.
So what else?
And so I think what else is over to you?
We're focused on the medical side.
Some of you reached out a few weeks ago saying
that they've just got approval
to send an open flexure into space.
So hopefully,
yeah, it's March 27.
It's a modified open flexure.
It should be going into space.
Think this cross for that.
There's a number of different things
that are popping up in all sorts of different places.
I'm really excited to see what next.
But that's not for me.
And so yes,
with all of your help,
we can make my cross could be available for everyone.
Thank you.
All right.
Thank you, Julian.
Quick note for anybody who is about to exit.
Please leave through that door and take a right.
There has been a medical emergency out there.
It is under control,
but it is causing havoc outside the room.
So again, exit through that door and take a right.
Any questions?
Thanks, Julian.
I love it as always.
How did you feel for this long discussion
on one of those murder requests?
But looking at many branches as you were talking about
how do you get when it's software,
you can abstract the problem and it's
and therefore you don't have to look at the specific implementation
that much because you abstract the problem.
If you figure out there's a conflict,
it means you haven't understood the problem.
With hardware,
like well,
this problem doesn't exist in many places.
One conflict,
one conflict may lead to a solution
that creates a conflict in another case.
I mean,
mind the standing of it.
How do you look at this conflict resolution
for those different versions that are based on the same base?
I think it actually is similar to how you do it for software,
because I think software is something where
if you're writing a little bit of software for yourself,
you sort of go,
ah, look,
I can prove it worked.
As soon as you're writing a library
that a bunch of people are going to use,
you just need to understand the larger ecosystem
of what has happened in different places.
So this is why tools like GitLab give you things like
code owners,
you know that in your team,
this person knows so much more about this.
So if that file is changed as part of it,
you call their men and go,
does this break things?
And so this is why it's not just that we have,
so to sign off,
two people from the,
ah,
we've got,
I think,
four or five people who can do sign off,
at least two people must sign off on it.
So,
the plan is that two people,
and if I come to it and there's something
I don't know,
well,
I'll go to the core team,
can somebody else review this.
We will then get all of us
who've thought through and been through
so much of this design process to talk through it.
But that act of talking through it,
enables other people on the core team
to understand parts of the discussions,
which sort of self documenting process
that helps build that knowledge.
But yeah,
at some point,
what happens with the different variations.
I mean,
lovely to have collision tests.
It would be good,
but partly you go,
this part is different in these different variations.
We might have to print all of them,
but it's still,
like anything,
in a hardware or software,
there's somewhat a manual thinking process
that you still need experts.
You can't just give it all to AI.
I'd like to piggyback on the previous question.
With software,
whenever you see a bug,
you can design a regression test.
That you include in your CI pipeline.
How could you do that with hardware?
Yeah,
I mean, that is a brilliant question.
So I heard we're in the loop CI.
There've been some wonderful talks in this dev room
in previous times.
I mean, it depends if it's the mechanical version of it
or if it's sort of the whole system.
So we've been thinking about with the motor controllers.
Wouldn't it be cool if,
when we push changes to the motor control code?
We've got the motor,
but then an Arduino with a rotary sensor,
and you can check.
So there are thoughts for hardware in the loop CI testing.
There are things that we can at least check
if the models are complete.
If you had a different CAD package,
and you've got your FEM simulation,
you would be able to check things.
It would be a really slow pipeline.
But partly the testing in the loop for us
is the human who go,
right, they've changed this.
Well, the unit test is a 3D print that unit,
and see if it works.
So it's not particularly automated,
but at least you can have a checklist and a workflow,
and at least we're not each individually building it,
because one thing we had in the past was somebody went,
ah, yeah, I've changed this.
Cool, I'll build it and you build the SDL,
but actually you've got an old version of that file
because something didn't change.
And so at least you know that you are all checking
the same component.
We also do a lot of putting the old version,
the new version, the slicer,
and moving up and seeing exactly where the layers
have changed.
So we were checking it's going to print in the same way.
But yeah, it's somewhat more manual.
I would love to just be able to write a unit test for it,
but we're working on it.
All right, question if you have insights
on the 3D print and design,
heat set screw inserts, thread itself tapping,
and differences like POA, PETGE,
yeah, what did you find in approach showing fasteners?
Very, very, very good question.
So I mean, we'd use to do a lot of tapping directly
into plastic, which I think was the availability
and easy to specify machine screws,
but also not wanting to go through all the different parts.
It did slightly better if you made the holes
triangular, so you're basically yourself tapping
and moving the material out to the side.
We now use self tapping screws in triangular holes
in a couple of places.
We've tried to move to machine tools machine screws.
We have a nut trap that we use all of the time
rather than heat inserts.
Heat inserts may be better if you're good at putting in heat insert.
With a whole community and I tried to get one line,
I've got a conical soldering out,
it'll be fine and they've got stuck on it,
and I'm melted the side off, something else is like right.
It's probably good if you had a production process,
but not great for us, so we've got a nut trap
where there's a little slot,
and a little sort of hexagon up,
and getting this to print well has been a bit of a mission.
But then it's sort of tapers.
So before you put the screw in,
you put the nut at the bottom, get a screw,
and you tighten it, and it forces it up into the nut trap.
But the great thing about it being open-scad
is they're basically a sub-routine for that.
So we write that in one place, and as we iterate on it,
we click change, and 40, 50 places through the design,
all of the nut traps get better.
There's no redrawing and going to individual files.
But yeah, I could bore the rest of this room
to death with that, answering that question.
I could have question if you have your own project
that you want to get into open-source.
Is there a guide of something?
How you set up the whole documentation?
Like the whole generation part, and then.
Yeah, I mean, no, I think is the short answer to that.
I think it's a really not well-established way
to do open-source hardware.
I think how to set up an open-source software project.
There's so many guides, there's so many things.
I wouldn't necessarily say everybody should do what we're doing,
because for almost all use cases, you should be using freecat.
Not open-scath. There's a lot of problems with it.
The specifics, like when you're the whole updating process
and the more documentation.
Yeah, so I mentioned the, what was it?
Get building?
Yeah, so just very quickly to finish the thought
because it moves into that.
A lot of how get building works is based on
it assumes that you can get images of each assembly step,
but that is specific to your CAD.
So, Peter, you might be somewhere.
There's Peter. Peter's doing some really cool stuff
with freecat to get the images out,
and we worked out a way to make it work with get building.
Get building itself.
I wrote some sort of documentation.
When you start writing the documentation
for the documentation tool that you wrote for your hardware
that you started making, because you wanted to do something,
it gets very meta, but yes, there's a little bit.
Somebody's made some videos of it on the gathering
for open science hardware form.
You talked about updating the pictures
in the documentation.
Yeah, I'm also very worried about the text segments
getting silently out of date.
Do you have a system in place to sort of alert you
that maybe this section of text needs revision
or do you do that by knowledge purely?
Yeah, so it's by knowledge.
I mean, I think it's the fact of, if it's a somewhat
let's say modular design.
So, I think it's part of it, it's process again.
So, somebody shouldn't make a bunch of changes
and that's a revision.
If somebody changes nine different things
and opens a merger quest, we say,
please open a merger quest on one thing.
So, then, at least if somebody is changing one thing,
part of our process is going to where that thing happens
and updating the documentation.
That doesn't mean that we don't sometimes find
some things where you go, oh no, this is a bit out of date.
But, a lot of its diligence,
but yeah, if you keep your merger quest small,
so you're only changing one thing,
that should highlight where that happens in the documentation
and the nice thing, so get building the tool,
has marked down files that are in the repository,
so they can build.
So, the actual merger quest will make sure
that when you make a change that it builds correctly
and you also should change the documentation,
that's the part of the same merger quest,
so it should be a small contained thing
with all the documentation as well as all of the,
as well as all of the CAD.
Good time for at least one more,
because we can't find Wayne.
I was just wondering if you have anything
or a translation of the documentation in an automated way.
I guess you had that example of the screw,
and that just feels like a sort of British English
to US English translation.
Yeah, I mean, that will be the hardest translation.
But, so the short answer is no.
As people have made some documentation
in other languages for open flexure,
we've had ones in Spanish in the past.
What we don't have is a good system for keeping them up to date.
So, I have pie in the sky ideas of being able to sort of
check by paragraph and see which ones changed
and then highlight which, which versions of other things.
And I know some of the wickies have really good things for that,
but then because we're in different tooling,
we'd need to write it and so.
I think partly I might need to get over myself
and my grand vision of it all working great,
just except that maybe we should just start
and same with the software we need
to actually work on the internationalisation thing.
We've got such an international community,
but as the community is growing,
we've got more contributors that really has to be a cool focus of us soon.
So, there was just a preview stock in another room
about education and open flexure.
Oh yeah.
And there was talk about Lego-like IKEA-like documentation for building.
Yeah.
What you were showing here with the Alan Key going,
is that what you were talking about?
Is that a whole separate?
Yeah.
So, I mean, our documentation.
I mean, I assume I've gotten till Wayne turns up,
so I can probably.
I mean, if Wayne doesn't turn up for a week,
you guys are going to get really bored.
But yeah.
So, we tried to make it so here are the parts you need.
Here is the screw.
It's going into the gear.
You've got these tools.
So, you turn this round.
It pulls it in together.
Now you got that.
So, we're trying to go through point by point of the sort of,
I think it's more Lego than IKEA style,
because it's in color.
If you use free CAD and Peter stuff,
it ends up IKEA style.
So, yeah, we've got a number of different things
just going through.
So, it's all rendered in that sort of way.
We probably need for education one with fewer words
to make it sort of more kid-friendly,
because it doesn't matter maybe for one for a kid.
Matters that it works, doesn't matter that is absolutely perfect.
So, different variations.
All the documents might be sorted.
All of it.
Yes.
Yeah, I don't know if you mentioned it,
but are you doing anything in terms of translating this documentation?
Yes, or is it all in English?
Yeah, so we were just talking about that.
It is currently all in English.
We've had some past versions,
but yeah, exactly how we do it in a way
that it stays up to date is painful.
So, we want that we need to get on that very soon.
Thanks.
You know, speaking of which would you consider using AI
to automate the translation?
I think having it in the loop for doing bits of it
as long as there was a human to check it over,
I think it's fine.
It's how we make sure that we stay up to date.
We need some tracking even if it's on a file by file level
of this has changed.
And it was last documented a particular time.
Because we have metadata in the files,
I quite like to say, you know,
if the Spanish version has a different number,
we can just say this is a screw,
this is a screw, this is the same screw.
If the Spanish version needs six screws,
and the English version needs five screws,
that is a problem.
Yeah, time for another question,
because we're still, I can see all the cell phones
blurring in the background there, so.
A bit of a follow-up question on what you're showing now.
The mouse-overting doesn't look like it's very printable,
so it's making printable documentation
at all a consideration.
Yeah, so we write it in Markdown.
It makes this, and you can,
because it's all open source,
you can see the big, long discussion
on whether there should be a number of different images
or the scroll over thing.
But the HTML that is rendered here,
can be changed if you say you're in PDF mode.
It will render some different HTML,
and then put it in a PDF.
It's semi-working.
We're still working on that process.
It's something that we don't do too much.
Part of it, there's so many links in it,
and then there's so many extra pages explaining things
that you don't want documentation this thick.
But then sometimes if something is removed,
you want the link to,
so there's a bit of what we do with the text in different places.
At the same time, if you say something is in a particular place
and reference back to it,
we can get the page numbers,
but I think I'm now doing it too often.
It's mostly a list of past page numbers.
So yes, it's on the radar,
and it's not as bad as that,
but getting it to work perfectly with both PDF
and website is ongoing,
but it's definitely on the radar.
Oh, question in the back.
Great.
I was going to have to start telling jokes.
I will help you out.
I was wondering,
could you make a sort of a template
of all of the tools that you made
so that if there's another advanced open hardware project
that they could just replicate all of the tools
because independently,
each of them are open source, I believe.
Yeah.
It would be great to have this infrastructure
for other projects to adopt it.
Yeah.
I mean, I think, especially,
one reason we named the charity,
the humanitarian technology trust,
not the open-flexion foundation,
who really do want to look at what we do well
and explain it and have it work for other projects
and other things with similar goals.
In terms of our tool chain,
I think a lot of it is
works because we know how to make it work.
If we wanted to make it turkey enough that anyone could use it,
I'd pretty much have to start working
on open-flexion and be the tool chain guide.
In fact, a bunch of you met me when we had this idea
for an organization that could be funded
called the Open Tool Chain Foundation
that would be able to work on the tool chain
so people can do hardware.
And it's the thing where I would love to do that
but it's sort of the time.
So there's ideas of talking to different organizations
about how we can really get the tools
needed to do hardware well,
really turn keys so people can do this.
Look who we found!
Hey! Hey!
It's a win!
Alright, thank you, Stewart.