Open gonzalocasas opened 6 years ago
This is very closely linked to #11 .
g-code
or RAPID
can be considered DSL's as well 🍹 but I think you have a dsl
in mind to generate a nr of targets such as Karel, KRL, RAPID, g-code, APT?
Being able to parse and cross-compile would be interesting.
There's a pretty decent RAPID parser that actually interprets the RAPID
code in python! So that's a start of a fabrication dsl
;)
I think the original intent was to to test-driven development
That RAPID parser is a very interesting project.
This feature is still up for definition and your feedback is more than welcome! The overall idea goes slightly more in the direction of building an internal DSL that allows to model/express the fabrication process with all its nodes, interactions and inter-dependencies. And while some nodes will be targets for vendor-specific code, the focus is on online integration (i.e. drivers), not so much on code generation for offline programming.
As for programming model, something along the lines of the actor model defined using declarative programming might also be a good fit, probably in some combination with finite state machines. But yeah, very much open for discussion :)
the focus is on online integration (i.e. drivers), not so much on code generation for offline programming
interesting, indeed I was thinking more in terms of (high level) code generation
probably in some combination with finite state machines
some associated projects that come to mind are abb_librws
is utilizing a statemachine on the controller to control the routines invoked by the lib.
perhaps abb_libegm
can be thought of as a driver.
Building up on top of #8, explore the possibility of creating a domain-specific language for digital fabrication, heavily leaning towards declarative programming models.
There's an overview of DSL for robotics here, and there's some prior work done on Haskell, including some older papers that should be analyzed.