I
wrote a couple of weeks ago about programming for MOSS. We had just gotten an explosion of attention from
our launch on Kickstarter, and the alpha-geek, early-adopter community started asking about programming. I didn’t have a good answer, but since then, we’ve had some time to decide what we’ll build first. We just announced two programming tools as stretch goals for the campaign.
MOSS Flash. At a base level, we want our hacker friends to have full capability to reprogram, repurpose, and remix MOSS to accomplish whatever they want. The first thing we’re going to build is MOSS Flash, and it’s a desktop application that lets you reprogram the microcontroller inside any MOSS Bluetooth or MOSS Brain module in C. We’re not going to build an IDE yet, you can use whatever editor and file management tools you like, but you’ll be able to start with a few sample programs, modify them or write new ones, and just drag the files onto the super-simple MOSS Flash window to compile and reprogram a connected MOSS module via Bluetooth. We’ll probably build this in
Node.js and much of the code is already written for our own use at modbot testing and debugging new MOSS programs. The code for basic functionality won’t be the hard part in building MOSS Flash, though. Documentation and designing the tutorials and materials that support open-ended programming will be hard, and building tools to help with debugging (regular C compiler output is often not particularly helpful) will be hard.
MOSS Scratch. With low-level access for the die hard programmers covered by MOSS Flash, we also want to create a second way to program MOSS robots, something higher-level that can serve as an entry point for young inventors or for those who don’t get off on semicolons. We picked
Scratch, and we’ve already started working on a MOSS Scratch extension that will provide MOSS blocks that you can integrate with the normal Scratch blocks and a custom online compiler that will customize a Scratch script to run natively on the micro inside of a MOSS module. The mechanism for adding extensions to Scratch is in beta right now but it looks really promising and the Scratch team has expressed enthusiasm and support for the integration with MOSS. I think the progression of creating on-screen animations and then behaviors for a physical robot could be a pretty effective learning tool, and honestly, my mind is a little blown right now thinking of the cyclical nature of progress what with Grey Walter’s turtles, then Logo, then Scratch, and now back to robots.
Want to program your MOSS robots? Me too. We have some work to do building and testing these development tools, but we also have a pretty amazing engineering team. If the Kickstarter campaign hits the $564k mark, we’ll plan to have both of these tools ready in June 2014 and ideally we’ll put up a beta of MOSS Flash right around when we ship the first MOSS kits.
Console replaces the Blockly and C programming apps and lets you do both at the same time. It also lets you Personality Swap your Cubelets to change their behavior with pre-written programs. Most exciting for me, though, is the new Data Logger interface. Connect a Sense Cubelet or three and watch their block values change over time. Add an Inverse and watch the complementary graphs. See if your kid can make a sawtooth waveform with a distance sensor. Track temperature or light data and export it to a CSV or a Google Sheet. Experiment!
I’m at home this afternoon and I noticed that although the sun is streaming in a couple of south-facing windows, our little cactus was in the shade between the windows, a temporary dark spot as the sun tracks across the sky. I thought maybe I’d build a little self-driving car for the cactus. You know, like Uber for plants!
Cacti like to be in the sun, so I figured I’d start with a Drive Cubelet as the base and a couple of light sensors so that the robot knows where to go. But before I put a plant on top of anything, I knew I’d want to ease the back-and-forth motion of the robot so that it didn’t come to a jarring stop when it found light and bounce the plant right off. I thought it’d be elegant for the robot to slow its velocity along something like a sine wave. Sin() is a bit heavy for a microcontroller, so I found a web site that generated lookup values for a sine wave and tried pasting a few of those data values into a Blockly program (sine-down.cubelet) that sine-waves down from 127 (half speed) every few seconds. Then I found the magic of Console. I switched quickly back over to Data Logger to verify that my code was working and saw these little approximated sine waves.
Then I flashed the code into a Drive Cubelet and saw this:
Looking good. Next I attached a couple of light sensors and tried programming the Drive Cubelet as sort of a lopsided state machine. If a light sensor has light, then drive toward it for a half second, slow down, and begin again. It worked! The little platform is successfully moving the cactus to the brightest sunshine. It’d be fun to add a couple of distance sensors to make sure that the plant car doesn’t bump into anything or fall down the stairs, and maybe some down-low glow, but I’m pretty happy with this for now.
Where were we, anyway? Right, Console! Console is a huge upgrade to the high-ceiling Cubelets experience. I was just doing distributed robot programming using multiple languages and leveraging inter-robot messaging schemes. And it’s for kids! It’s super cool to be able to sketch out a program in Blockly and then pop into C to understand the exact code that got created. There are lots of ways to look at the same algorithm, and lots of ways to understand things. Give Console a try and let us know what you build.
