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

[techninja]

Oh yea, totally. That interface certainly smells of early XMLRPC/Flash interfaces, but hey, why not. It's certainly worth it. Probably open it up as an interface entirely separate from the versioned REST api, maybe something like /scratch or perhaps /simpleapi ? I'll look into it, awesome suggestion :)

[oskay]

Sweet! Yes, it's "primitive" in a sense, but it's also accessible. ;)

I'd suggest versioning it like "/s1", so that it could have parallel versions with the "/v1" that we already use. This could be really awesome.

[techninja]

Just got back from a quick attempt, and I've basically fallen flat with a big fat "bleh": Scratch restricts HTTP interaction in some very strange and awkward ways;

• All block GET requests are simply send and forget triggers, and each response is completely ignored.
• Any data that is intended to be used by scratch (from a trigger or otherwise) is thrown into a single "/poll" page in plaintext, and is queried 30 times a second (gah!)
• Instead of waiting for the request to finish as one would imagine, blocks that must wait to finish (all the ones for the bot) pass an identifier that is pushed to the poll page under _busy.
• You can not use "/" chars in the block names, so a prefix like /s1 is not allowed, nor are multi-use endpoints for blocks.

Regardless of the difficulty, I've fully implemented the very first portions to that spec, and have tested against Scratch 2 offline v404, with some success, except for the fact that apparently all "wait" commands make no requests at all (verified with wireshark), so I'd say this is essentially dead till this gets some kind update. Apparently the actionscript version is live on their github page, so hope is not all lost. FWIW, I'll open up an issue.

The general excuse is that it's a "experimental" feature, though it seems making even the "implemented" feature set stable enough to test is out of the question. Forum posts here, and here, and here for continuation.

Another option that seems possibly in-line with the intent of the ticket, is to use Snap, an HTML5/JS native re-implementation of scratch, which would likely be able to run the CNCServer API directly in a custom block. Of course it's also buggy and quite a bit more complex than Scratch :P

[oskay]

Neat! Can you please upload your Scratch example as well? I wonder if we might be able to do the waiting on the Scratch side, and just communicate "open loop" to the CNC server.

[techninja]

I actually never got scratch working well enough to make it worth it. The procedure for use/testing is as follows:

• Start cncserver with scratchSupport = true either via commandline op or in the config.ini
• Shift click the file menu, then click "Import Experimental Extension" at the bottom of the menu
• Select the cncserver_scratch.s2e from the base folder of cncserver
• The new CNCServer blocks should now be visible in the "More Blocks" scripts tab.
• As a test, current code is set to take any attempt at movement, spit out a debug line for sent arguments (I've never actually seen them from the application yet), then wait for 5 seconds before next block execution via the spec _busy in poll method (tested only in theory, not in practice).

Reading pen values also apparently has some kind of issues, not sure why.

Switching the process blocking "w" commands to async " " commands does technically work, though I've mostly written it off as bad form. Truth to tell cncserver has a full and complete queuing system that could simply take whatever flood of commands are sent from Scratch without waiting, of course scratch would never have a clue about what the bot was doing. Perhaps we'd also need some level of interaction with the buffer, and to properly clear the work queue and park on reset, and maybe even blocks for pausing and clearing the buffer.

What do you think? It's certainly a way forward, even if it's a little questionable. Also, what other block types might you want? Setting speed or other settings perhaps?

[oskay]

Ah -- sorry -- didn't see the .s2e file there.

[oskay]

I think that "open loop" control is the most appropriate approach given the current state of scratch. My guess is that they'll eventually fix up the interface. I'll give it a try, and see what can be done.

[techninja]

Sorry neglected to mention this is in the scratch branch. I'll look into making it open loop and if it's feasible and actually works in scratch I'll wrap it up and commit to master.

[techninja]

Open loop works!
Looking around at how these things are usually applied, I figured to run with the "turtle" method of having a separate pointer that has an angle and gets a distance to walk. This applies well to the loop blocks. I've also implemented a number of different methods of doing the same thing, which allows for ease of use in different situations. Like direct text setting of the tool, or using an integer that allows for a random color to be grabbed.

The extendability of this is huge, at least as far as what can be done on the CNCServer side with the limited trigger data coming from Scratch. I'd like you (or others) to beta-test this a bit, and see if there's any more useful blocks you can think of adding/abstracting. Once I get approval, I'll merge the feature to master and this will be an option to enable in RoboPaint.

My test Scratch program:

• Puts water on the brush
• Gets a random color from the set
• Moves to the top left of the draw area
• Puts the pen down
• Moves/angle adjustments in two loops, draws a sort of backwards "S"
• Parks

Get it here: TestCNCServer.sb2. This project file includes its own copy of the s2e extension definition, you should just be able to open and run it with a copy of the scratch branch of CNC server running (with scratchSupport on).

[oskay]

Looking nice so far! I'm re-installing node right now (long story...) but I do have some first impressions:
(I've edited this several times with additional notes.)

I can see that we need:

• Wash brush
• Motor off
• Some method of previewing what will be drawn, without actually drawing it. Perhaps an "offline" command? "Turn WaterColorBot[On/Off]" with a boolean/menu option?

Likely also want:

• Move to center (best for turtle graphics...).
• To match Scratch's convention of (0,0) being in the middle of the page, it may be better for us to instead define (0,0) as the middle of the paper (for the scratch interface only).
• Move speed (e.g., 1-10?)
• Wait (seconds)

Suggestions:

• Remove "backwards" option from move-- the standard "move" command implies forward; we should follow that example. Backwards can always be done with a 180 degree turn first.
• Make numeric input to angle a numeric input, rather than a pop-up menu, to follow convention of native rotate commands. Default value: rotate 15 degrees?
• It would be nice to have some obvious scaling between the Scratch draw window and the paper, to serve as a guide to the Scratch programmer, on how big of a thing to draw, and where to draw it.
• One method of "limit checking" would be to have the turtle draw the paper's outline in the scratch window.
• A possibly better method would be to use a background on the Scratch program (much like we do in, for example, RoboPaint RT)
• Remove the "Select tool" option. It adds very little, but could create confusion.

Harder, maybe not possible:

• Get (x,y) brush position
• Get color
• Use "right turning arrow" symbol for rotate CW/CCW, like the ones in the "motion" commands do.

Questions:

• Should the tool name be "Brush" not "pen" everywhere? "Pen" is easier to understand, but may lead to confusion. Using the word "Brush" may also help to differentiate the similar "WCB move" commands from the "scratch move" commands.
• Should there be an option to use an actual pen? (A "no water, no paint" mode)? It could be called with a "PenMode(true)" kind of operation.
• Is there a reason to not have this interface enabled by default in RoboPaint? So long as RoboPaint defaults to localhost only, my instinct is that ease of use justifies it.
• We could have a "high level" setup routine... one that washes the brush, and moves to the center, along with a "high level" cleanup routine, that washes the brush and goes home. Would it be better to do this?
• Scratch has some sort of "color" variable. Is there a way to map that to paint color?

Note to self:
node cncserver --botType=watercolorbot --scratchSupport=true

[oskay]

Everything seems to be working except for pen raising and lowering... not sure why.