Add interface for Scratch extension

[oskay]

Not sure if this is the right place (or way) to suggest this.

With a few modifications to cncserver, it might be possible to write an extension for the Scratch programming language ( http://scratch.mit.edu ), that could interface to cncserver. This could give the ability to drive the WaterColorBot or EggBot directly from within Scratch, which is a popular graphical programming language that features LOGO-like turtle graphics. (It could be a magnificent addition!)

Scratch extensions are documented here: http://wiki.scratch.mit.edu/wiki/Scratch_Extension_Protocol_(2.0) http://wiki.scratch.mit.edu/w/images/ExtensionsDoc.HTTP-9-11.pdf

The extension interface is quite primitive, and (if I understand correctly) allows Scratch to communicate via HTTP GET requests only. It also requires that a "crossdomain.xml" file be returned upon request.

It may (A) be reasonable to add a few equivalent "non-restful" command aliases to the cncserver API, to enable interfaces like Scratch or requests from a web browser address bar to drive the robot. (Personal opinion: that would be really neat.)

Or perhaps (B) it may be better to add those as a separate helper application, or to add those functions within RoboPaint, which then sends the properly formatted command to cncserver.

Note added: A good example of a Scratch extension and interface can be found here: https://github.com/damellis/A4S

[oskay]

Also, interesting new interface for direct javascript extensions; much more elegant: http://llk.github.io/scratch-extension-docs/

[techninja]

If we went with the JS route as well, would we want "wait" blocks? Or immediate run blocks?

[oskay]

I would be happy with a direct translation of our existing Scratch interface, at least for a solid "1.0" -- it's interesting to think about adding the wait functions, but of much lower importance than just getting up and running. Also, I don't have access to the Scratch developer UI, or I would have tried this already.

[techninja]

On a whim in the airport to Rome pulling an all-nighter, I went ahead and rewrote the URL parser and structure to work without slashes (which was definitely the problem it seems!). It's ugly, and doesn't match the docs, but it should now work. Lemme know if you find any bugs while you recreate those scratch examples in watercolorblocks ;)

[oskay]

Possible bug: It appears that the manual-zeroing part of the unlock motor command (pen.off) is not working correctly. The motors do indeed turn off, but it does not act as though the internal position variables are being reset to the parked position. So, when you begin moving again, it doesn't move from the parked position, but from the last-known physical position.

[oskay]

Also, the order of the poll items has changed. In scratch & snap, it's relatively easy to extract the nth data element, but much harder to parse the array for the "x" variable.

[oskay]

A hack: Changed the poll data to give the most important elements in a fixed order. It's not the same order as it was previously, but does at least fix: x,y,z, and distancecounter. It would be nice to have all of the elements in a defined order, documented in the API. https://github.com/techninja/cncserver/commit/440e22aacc03d3e73a8de41a7801ee262568584d

Doubtless, this will be followed by someone else's whitespace cleanup commit. :stuck_out_tongue_winking_eye:

[techninja]

Yes, it's true the pen data output was a bit of a hack anyways, should really have been its own formatter as you've done there with a standard output. Will possibly tweak it soon (with documentation).

[oskay]

I imagine that this is not how you would write it, but it did allow me to get the WaterColorBlocks back up and working well (for Snap! at least, with the exception of the zeroing issue).

[techninja]

Turns out the pen.off problem is far worse than expected: The entire idea of Zeroing in a world ruled by streams and buffers doesn't actually APPLY. Yea, so.. reworking that now. :open_mouth:

[techninja]

Ok, fixed. We just needed to act as if "The hand of Glob" came in and changed the actualPen object.. as it's meant to be immutable until an actual movement command is sent.

Do we want this to reset the turtle pointer as well? I've assumed not.

[oskay]

I think that this should not affect turtle position, just physical location of the carriage.

On Nov 5, 2014, at 11:36 PM, James T notifications@github.com wrote:

Ok, fixed. We just needed to act as if "The hand of Glob" came in and changed the actualPen object.. as it's meant to be immutable until an actual movement command is sent.

Do we want this to reset the turtle pointer as well? I've assumed not.

— Reply to this email directly or view it on GitHub.

[techninja]

Then done. As a Test I wrote a very quick squiggle, then with the power of loops, turned it into something fun and crazy. The power of this is surprising for physical doodling, and I suspect a very good idea to implement soon is an embedded Snap/scratch mode inside RP :)

[oskay]

Awesome.

I'm not sure if an embedded scratch mode is a good idea... just yet. That ecosystem is evolving very rapidly, and there is something to be said for letting people develop in their own "IDE." That said, we might think about importing scratch files, for examples.

[techninja]

After some testing, it appears the largest issue with using the WaterColorBot with paints on scratch, is there is no CNCServer support for "reinking". This is entirely controlled inside of RoboPaint, and RP does not interact with the scratch API at all.

The silly thing is we have this base, paint specific wiggle function, and yet no refill :/

The problem has always been defining refill in a meaningful way. I suspect what should be done is simply extend the scratch additions here to manage re-inking in some default yet manageable way to allow for pen drawing as well :/

Opened #56

[oskay]

I would like to suggest that issue #50 is fully implemented as of this point, and that future discussion should not be added here, but started as new issues. (Do we need a "general discussion" issue?)

[techninja]

Probably. I only used this one as a bounce for the other issue. As of Now I'm locking this issue as done & dusted, and any further discussion/bug reports belong in other issues :cake: