Croquet/RepRap integration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Croquet/RepRap integration

deadgenome -.,.-*`*-.,.-*`*-
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.
Reply | Threaded
Open this post in threaded view
|

Re: Croquet/RepRap integration

hendikon
Love it.

>What do people think of this idea
>
Reply | Threaded
Open this post in threaded view
|

Re: Croquet/RepRap integration

Joshua Gargus-2
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.