WaterColorBot and Snap!
This is my informal rundown of how to get started using the WaterColor Blocks extension with Snap! and your WaterColorBot plotter. I’ve had a WaterColorBot on hand since the first Kickstarter, and this is the way I most commonly use the WCB with elementary and middle school students. There are ways to generate more impressive output – complex vector art in Inkscape or detailed images rendered with StippleGen, but nothing touches WCBlocks as a learning tool.
First, you need to have something installed on your computer that will pass commands to the WaterColorBot. I still use RoboPaint, but I think you could also use @techninja42 ‘s CNC Server on its own. Using RoboPaint, you can open the program and then use the RoboPaint settings menu to home the brush and calibrate the height of your pen. Once that’s done, leave RoboPaint at the home screen. You don’t need to do anything in the RoboPaint program, just have it open to pass commands to the WCBot.
There’s a bunch of stuff to download in the WCBlocks github, but there’s nothing required for Snap! except a single project file (saved as .xml) that contains the actual Blocks. The other stuff in the WCBlocks download is either examples (interesting, but not required) or stuff for offline Scratch. I havent checked in the last few months, but IIRC offline Scratch fails to do the central useful feature of Snap! + WCBlocks – namely have single blocks that move both the WCBot pen and the screen turtle. So, basically, don’t use the Scratch version.
To use Snap! with the WCBot, you need to open Snap! and then import a project that contains the WCBlocks. Any of the example files in the WCBlocks download will work. I’ve recently been using this file with kids, which has all of the WCBlocks along with the examples I discuss in this post. When I’m working with kids, I often send a custom project file that adds extra blocks or scripts. We’ll pass quietly by this point, but it’s the door to my rabbit hole obsession.
Project files often don’t have scripts on the stage, so it can be tricky to tell if the import worked. Check Motion, Pen, Control and Sensing to make sure all the WCBlocks show up.
Again, the awesome part of WCBlocks is that all of these blocks control BOTH the screen turtle (default arrow in Snap!) and the pen carriage on the WCBot. When drawings on the screen exceed the size of the paper, the pen will lift, the carriage will move to follow the screen turtle, lowering to resume drawing when the carriage comes back within the boundaries.
Caveat: This assumes that the WCBot was reset properly to the top left corner before drawing. If the WCBot isn’t calibrated properly, the carriage will slam against the edges. There are no limit switches on the WCBot.
So, sure, a basic square.
Since the actual draw loop is exactly the same as a standard Scratch/Snap/Logo square, let’s look at how this is different.
WCB Wash Brush runs the brush through all three water trays, swishing at each one. This block will pull the pen from whatever position it’s currently in, and leave it raised above the last water tray.
WCB Get Paint() send the brush to a particular paint tray, lowers it and smushes it around. This is where you’ll notice how much of a difference a few mm of height can make on your brush. :) It leaves the pen raised above the paint tub.
This draws an acceptable monocolor square. With screen LOGOs like Scratch and Snap, a common next step is to introduce more colors into a shape. But since the mechanical components of changing color with the WCBot are non-trivial, there’s some complexity and extra blocks. Notably, we need to keep track of the position & heading of the brush so that we can return to it after the color change.
When I do stuff like this, I use a Snap! specific feature called Script Variables. These aren’t complicated, but they are different from how things work in Scratch. They’re properly local variables, meaning that you can call them into existence with a block and use them in a script, but they don’t persist after the script is finished.
I’m going to use these Script Variables to hold the X position, Y position and direction of the brush while the Wash Bursh and Get Color () blocks do their thing. Then use use the Go To X:() Y:() and Point in Direction() blocks to reposition the brush before we lower it back to the paper.
This is a headache, especially for kids. As a result, I often have the WCBot set up to use a pen for initial LOGO drawings. Pens are great. They have small, consistent line weights. They don’t need to wash or refill ink in the middle of drawings. When you have a class full of projects, run them with pens. Once a drawing works with pens, then consider using the watercolors.
When you’re ready to do that, you may also consider creating a dedicated block that does this whole procedure. In the orange variable tab, you can create your own blocks. This is similar to, but much more powerful, the purple Custom Blocks in Scratch 2.
Here, I’ve taken the complicated stuff (recording position) from the earlier script and bundled into a block I call WCB Wash & Color ()
This takes a single number (color choice) as input, and then does all the stuff from the program above. As a result, I could rewrite the multicolored square into a much cleaner script.
In my experience, this is the key to using the WCBot and Snap! with elementary age kids. My goal is for them to grapple with the hard fun of LOGO in a physical medium. I do as much as I can to abstract away the complications of the WCBot and let them focus on the programing challenge of designing in LOGO.
This brings us back to the rabbit hole I mentioned at the top of this post. Given the chance, I use Brian Silverman & Artemis Papert’s fantastic TurtleArt when doing screen Logo. It’s beautiful, powerful, focused and elegant. I realize that I have another post lurking on why I prefer Turtle Art to Scratch and Snap for screen LOGO, so I’ll leave my endorsement as it stands.
One of the awesome features is that TurtleArt includes an Arc block as a primitive. There have been deep arguments about what commands should be included as primitives since the invention of LOGO. While kids can create circles in Snap!/Scratch using small loops (Repeat 360 [FW 1, RT 1]) , it’s difficult to get those to easily mesh with the measurements in the rest of their drawings. The Arc primitive means that students can easily fit a curved roof to a rectangular house by tweaking the radius value, even if they don’t know “radius” as a vocab word. Changing either of the two parameters for the Arc block produce obvious changes in the shape, and those changes are predictable. Even though the Repeat loop can produce similar shapes, it asks for a much deeper understanding about how the circle is created. I think students build towards more interesting designs faster using the Arc block, so I tried to recreate it in Snap for the WCBot. One version is included in the sample program as WCB Arc.
The problem isn’t that this is complicated. The problem is that it still doesn’t work well on paper.
Both this version and the alternate which scales the Turn parameter rather than the Step, run into trouble sending tiny values to the CNC Server. I found that small steps work better than small turns, but there’s still a mismatch between what appears on the screen and what the WCBot draws.
I don’t know if there’s a clean solution to these problems. When the WCBot programs render vector art (SVG files) into motor commands, they are able to operate on entire figures and compute the whole motion to draw an arbitrary circle. The way the Snap! interface works, it’s sending individual commands in a long sequence. Complex curves require some of those commands to be for very tiny motions that seem to fall below the WCBot’s thresholds.