Hi folks, I want some serious dev. answers to this question, however I
also feel that it is of interest to the wider Croquet userbase as well, so I am submitting it to both lists... --- I have been thinking about writing some sort of driver to enable Croquet to control a RepRap - http://reprap.org - or similar open source 3d printing technology. The approach that I was thinking would be sensible was to firstly porting the RepRap control software to squeak (it is currently written in java) in a form that could be used by non-Croquet systems, such as the OLPC platform (I assume that the OLPC box is not going to be powerful enough to run Croquet properly, please tell me if I am wrong in this assumption). Next a Croquet application would be created that sends 3d data to be printed to this generic squeak control software and gets data back from it on things like the proposed route of the print head, errors due to non-printable geometry (sealed hollow objects, for instance) and how the print is progressing. Also, the Croquet application should have a couple of main ways of using it. In the first, the print is automated (possibly with a few options for things like alternate internal structure strategies) and is left mostly up to the discretion of the control software. In the second, the control software reports back it's proposed tool route to the Croquet application in the form of a 3d path, which can then be manually tweaked in Croquet by more advanced users who want that level of control. By creating this software, users would be able to directly print any object they have access to or have created, which would extend the concepts of object creation, visualisation and sharing out of the virtual realm and into the physical. What do people think of this idea and can they see any major problems with the approach I am suggesting, or ways of doing it that might be better? Cheers, David. |
Love it.
>What do people think of this idea > |
In reply to this post by deadgenome -.,.-*`*-.,.-*`*-
On Feb 21, 2008, at 2:32 PM, deadgenome -.,.-*`*-.,.-*`*- wrote: > Hi folks, I want some serious dev. answers to this question, however I > also feel that it is of interest to the wider Croquet userbase as > well, so I am submitting it to both lists... > --- > I have been thinking about writing some sort of driver to enable > Croquet to control a RepRap - http://reprap.org - or similar open > source 3d printing technology. > > The approach that I was thinking would be sensible was to firstly > porting the RepRap control software to squeak (it is currently written > in java) in a form that could be used by non-Croquet systems, such as > the OLPC platform (I assume that the OLPC box is not going to be > powerful enough to run Croquet properly, please tell me if I am wrong > in this assumption). That's mostly correct, since the OLPC doesn't have hardware 3d support. There's nothing preventing a 2D version of Croquet that would run on OLPC, but I'm not aware of any current effort in this direction (I believe that there was an experiment along these lines, known as "TinLizzie"). > > > Next a Croquet application would be created that sends 3d data to be > printed to this generic squeak control software and gets data back > from it on things like the proposed route of the print head, errors > due to non-printable geometry (sealed hollow objects, for instance) > and how the print is progressing. > > Also, the Croquet application should have a couple of main ways of > using it. In the first, the print is automated (possibly with a few > options for things like alternate internal structure strategies) and > is left mostly up to the discretion of the control software. In the > second, the control software reports back it's proposed tool route to > the Croquet application in the form of a 3d path, which can then be > manually tweaked in Croquet by more advanced users who want that level > of control. > > By creating this software, users would be able to directly print any > object they have access to or have created, which would extend the > concepts of object creation, visualisation and sharing out of the > virtual realm and into the physical. > > What do people think of this idea and can they see any major problems > with the approach I am suggesting, or ways of doing it that might be > better? Your approach sounds fine, but you might be able to do something simpler in the short-term that achieves almost as much (actually, just as much). Croquet doesn't currently have a shape-modeling application that can be modified to design objects to be printed by the RepRap, so you would be limited to printing externally-designed objects. Your more advanced use-case (where a Croquet application reacts to feedback provided by the control software) can't be achieved without some sort of CAD program running in Croquet. Until this changes, it seems simpler to invoke existing RepRap software from within Squeak rather than to port it to Squeak. Can the RepRap software be run as a command-line application? Can it be controlled via a socket interface? Either of these options will let you get something running much more quickly (and a socket interface could even support the more advanced interface). Cheers, Josh > > > Cheers, David. |
Free forum by Nabble | Edit this page |