Hi everyone, a team from TU Delft (including @jurra) is building an open centrifuge, you can follow in their repo.
They’re currently testing some features and are welcoming any suggests/ideas for this phase. They put up some issues here:
Ideas are most welcome!
At some point I’ve considered the following ideas for a self-balancing centrifuge.
If they turn out to be silly, I apologize 
There are some patents on using fluids instead of solids for self-balancing, but the working principle may not be the same.
I thought that the nice thing about this is that if it was somehow possible to have the tubes spin slightly independently of each other, they might balance each other, without adding extra parts.
A seemingly nice read on centrifuges and stability
https://drive.google.com/file/d/0B5LSKmhBg6HoWVlLa3lQY1YyOGs/view?usp=drivesdk
Gaudilabs made a centrifuge out of old hard-disk drives.
Some rotors just float, by pushing air downwards or by other parts forcing air upwards (air-cushions maybe).
¿Are high speed magnetically accelerated rotors feasible? Like a magnetic stirrer on steroids.
A local centrifuge manufacturer in Argentina wolud have been worth consulting for some insight (or even funding).
http://www.rolcosrl.com/rolco.php?c=cen
Cheers!
Thank you very much @naikymen we will add this as part of the documentation. Would anyone in the GOSH community be interested in helping us document not only the design, but all these knowledge and considerations about centrifuges. I think this is as important as documenting an open hardware design or replication.
@naikymen you bring up something very interesting! I don’t know much about centrifuges, but if stability is an issue, one possibility is to have all sample tubes freely floating in a container of water, and spin the container about its axis. The samples behave as though part of the water, so balance is achieved automatically. If cooling is required, then a water cooling system such as used for computers can be employed. with the ports dipping into the water. But given the substantial “water bath”, it could be that cooling won’t be needed.
A side effect is any number of sample tubes (that fit) can be centrifuged at a time, even 1, without having to consider symmetry or balance.
Thanks,
-harold
These are two interesting ideas! They sound like new experiments to make/test
We also want to document all these ideas in our web doc so that they are captured and taken by someone in the group: https://fosh-following-demand.github.io/Open-source-Centrifuge-for-WetLab/
Hi everyone, we made a chat for the open hardware centrifuge project and documentation so that we can discuss about design issues like these ones and share progress. Feel free to join: https://t.me/joinchat/G3nlmBKMeN71vUJERyfX9g
There are some issues to cover, and discuss still. I wanted to share a simple learning that I got from this first experience of replicating the centrifuge. If someone is going to make a single replication like we did to test and learn, sometimes fixated designs like a specific arduino board and a specific PCB design can become unpractical. What happend to us was that we were hoping to order the polyfuge kit, but it was not available, we run into a lot of troubleshooting issues with the Arduino Nano, therefore we were not able to use the original custom made pcb of this centrifuge model. We had to change boards, and the design documentation was not open to this flexibility, for instance the schematic of the model was not published. This is why different levels of documentation from abstract and general relations between modules and components like an schematic can be very important (Perhaps more important than a PCB layout, as these last ones may vary). Designing so that others can adapt the design is important, and this is why access to the source and core know how is important 
This goes beyond purely publishing CAD/CAM files or code, it is also about the rationale behind the design, the general requirements that are consistent and open to new models with their own specificities.
There are a few projects in the community trying to improve practices based on the same realisations you made!
Luka Mustafa who attended GOSH 2016 made a great case for having “useful source” code/documentation, not only “open source”:
That inspired DocuBricks and its best practice guide (by @Tobey, Luka and others)
https://www.docubricks.com/
https://www.docubricks.com/best-practise-guide.jsp
People like @julianstirling @rbowman are involved in an Open Know-How working group who are drafting a standard that is currently available for comment:
There is one thing to be open source but in need of better documentation for others to build and modify the design (that’s pretty much all projects because it’s really hard!) but if there is no schematic or no editable version of the designs that are essential to the hardware (e.g. only the PCB manufacturing files and STL files are shared), that should be a red flag that it’s not really an open hardware project according to the Open Hardware Definition and you’ll run into problems if you have to customise anything. Look for an alternative or be prepared that you may end up duplicating a lot of work that the original developer chose not to share.
one thing i used to say about centrifuges…
“The most important hardware is the Safety Cover, best out of metal. not the circuit to drive a motor”
you gonna spin stuff around at beri beri high speed… i remember shooting around some eppendorfs that got stuck into the wooden wall… and completely blasted our plastic covers.
good luck,
marc
Cannot agree more with that and it is problem that PolyFuge never fully addressed in their Kickstarter campaign or via questions from at least a couple of people on Facebook.
If anyone has ideas on safety features and how to do things like metal casing well, it looks like team have an issue on this point:
Hi guys I want to share some experience with regard to the replication-redesign-redocumentation of the polyfuge project. It has been good to experience incomplete documentation, lack of clear instructions, etc. I have learned a lot and wanted to share some thoghts for new projects to come.
What I mean by this is that replicators, builders and designers need to understand the general specifications of certain equipment. For instance a centrifuge key specifications involve FCR, Rotor sizes, sample sizes, etc. These specifications are independent of weather we use specific components like arduinos, brushless motors, etc. Documenting these specifications would involve also making general schematics (something similar to pseudo code). The same can happen with the control system and the algorithm. But this could go even further with models and simulations that can be adjusted.
When I started replicating the polyfuge v.1.0 I assumed everything was going to work. We experienced hardware incompatibilities with the Arduino Nano. When I went to find the schematics to go a step back, the schematic was not available. I lost time hacking the circuit and making the schematic. This is pretty obvious, but I learned why schematics are so important. They provide flexibility and freedom to make adaptations to the design. Also a master cad was not available to adjust, editable and user friendly cads can help in redesigning and adapting the official design to your specific context.