At IDC 2012 in June, Arnan Sipitakiat and Nusarin Nusen discussed how they are using Robo-Blocks—a turtle robot and “tangible Turtle Blocks”—to teach problem solving and debugging skills to 5- through 12-year-olds.

One of the things I learned from their presentation was that children had difficulty reasoning about relative angles. The Robo-Blocks robot does not have any distance feedback on its motors, so “the result of a program will change depending on the roughness of the surface and the battery level of the robot.” They worked around this issue by developing a protractor tool to guide the children's reasoning about the relationship between the (arbitrary) numbers entered and the amount the robot turned, but some kids still had difficulty. The researchers “often had to insist on trying the protractor” and “some children preferred to keep increasing the turn amount even if a small decrease would have fixed the problem” resulting in programs that had the robot making multiple complete rotations before setting off in the correct direction. The kids were also dissatisfied with polygon-drawing tasks (“turtle geometry”) because the inaccuracies of open-loop control of the robot means that the polygons often didn't close completely, and “[t]his small error turned out to be unacceptable to children.”

So I designed the XOrduino turtle robot from the start to have distance sensors so that it can do accurate turns with closed-loop control. Here's a little video showing how they work in the current (A1.5 / B1) revision of the board:

Some bonus pictures of the speed sensor on the workbench:

The robot on the workbench with probes.

Signal from the motor speed sensor. 5ms/div .5v/div. Motor is running at full speed, unloaded. Two dips are seen: the larger is from a piece of white paper glued to the rim of the gear; the smaller is from a spot made with a white paint marker (the paint didn't stick very well). White-out worked much better (as shown in the video above).

I've checked out all of the functionality on the A1.5 board except the step-up voltage regulator now. I'm optimistic the B1 boards (being made now in Taipei) will be clean.

It will be great when we've got lesson plans written up so kids can learn how to control the bot with Turtle Blocks, and play with the different possible behaviors. Instead of just bumping around ("like a Roomba, except it doesn't vaccuum" a friendly 6-year-old beta-tester told me), you can trace patterns you design, or use the Scratch Sensor Board sensors to make the robot "afraid of sound", "attracted to light", or add your own sensors and behaviors.

B1 is "the next run" of boards, already released to the fab house but not yet in hand.

The big feature added to XOrduino after A1 was a motor driver, to allow using the XOrduino as a Turtle robot. The big feature added to XO Stick after A1 was the shield form factor, allowing it to ride piggy back on the XOrduino. This makes it easier to share a single turtle robot with a classroom: there may be only one XOrduino robot base, but each student can have their own low-cost XO Stick "brains". They can take turns snapping their brains on top of the base to drive it.

I haven't finished testing all the functionality of these new boards yet, but it looks like I haven't made any major mistakes! Help still wanted with software, documentation, etc; send email to xorduino@gmail.com if you're interested.

Free things first: I've got parts for 20 copies of the "Mk I"
XOrduino and XO Stick. I'm mailing them out for free (!) in exchange
for your development help. Send me an email at
xorduino@gmail.com describing what you'd like to do with the
XOrduino/XO Stick, and your full mailing address. Best 20 or so get kits.

Here are some of the projects which you might be able to help with:

Assemble an XOrduino / XO stick with an 8-12 year old and document
the process. What parts were tricky to solder? Where did polarity
matter? How much of the function of the different devices did you
find worth explaining? Photos or video of children assembling the device would be great for future publicity, with their permission. (We're not crazy: kids can repair XOs and solder.)

Test different configurations of the boards. What are the
fewest components necessary for a functional XO Stick?
What capacitors are really needed? What's the smallest number of
components needed to get the arduino IDE to talk to the XOrduino?
Then add the components for the Scratch Sensor Board functionality,
and test that with this Arduino sketch (some minor porting required). Try out whatever
Arduino shields/old Arduino code you have lying around, and see if there
are any gotchas there. Document it all, take photos and video, let me know about bugs and pitfalls.

Write some killer education apps! These
boards are meant specifically for teaching kids—take the Turtle Art with Sensors ideas as examples, and write up some
lessons to teach science. Or take inspiration from the old school
"fun with electronics" kits from Radio Shack and recreate some of the
popular standbys: a burglar alarm for kids' tree fort,
a light-sensitive alarm they can hide in their sibling's drawer,
etc. Or a document how to program a robot (more on the robot below) with simple emergent behaviors—avoiding walls, turning toward light, fleeing loud sounds, etc. The Cubelets examples may give you ideas. Take photos and video.

Arduino support for the XO Stick. There are a number of projects
which add support for the ATtiny85 and friends to the Arduino IDE (for example, this one).
Ideally we'd like to make the XO Stick as Arduino-compatible as
possible, so we can reuse the excellent Arduino IDE, etc.
This involves (a) porting an arduino-compatible bootloader (like
usbAspLoader-tiny), as well as (b) porting the Arduino libraries to match the
pinout/peripherals of the ATtiny85 and ATtiny861 (this page is a good start).

Program an XO Stick from an XOrduino and vice versa. Ideally we'd
like to bootstrap the initial chip programming, so that one
programmed XOrduino (or XO Stick) can be used to put the initial
bootloaders on the others. For technical reasons the XO Stick
is probably best as a "clone tool": without interacting with the
USB bus it would just copy its internal memory to another
XO Stick. The XOrduino is a little easier, just a matter of
adapting the existing Arduino sketches and documentation.

Debrick an XO from the XO Stick. The XO Stick can talk to the
EC programming bus to recover a bricked XO; it can probably also
reprogram OpenFirmware. We need to write a bit of code to make it
pain-free and document the process. This would make the XO Stick a useful repair accessory for XO deployments.

Here's the exciting part two: I'm already working on the XOrduino and XO Stick "Mk II". The latest schematics/boards
are in github (xostick, xorduino). The kits I'll be sending out this week correspond to the "A1" tag in those repositories; the "Mk II" revision is on the master
branch.

The XO Stick gets a minor change with big implications: instead of
using a 20-pin header matching the ATtiny861 pinout, I've widened the
board to give the XO Stick a standard Arduino shield connector (and some
prototyping area). This opens the way for a port of the Arduino IDE
(mentioned above), but it also means that the XO Stick can be mounted on top of
an XOrduino. In a cost-conscious classroom environment, this allows a teacher to buy/make one copy of the XOrduino with all of its
fancy peripherals (scratch sensors, robot support) and then give each student a copy of the
cheaper XO Stick. The students share the XOrduino and swap out their XO Stick "brains" on top to control it or use its peripherals. Mating the two
boards also makes it straightforward to program an XO Stick from
an XOrduino, or to use the XO Stick's prototyping area to hack together
a shield for the XOrduino.

The XOrduino gets a more exciting feature (hinted at above) -- enough peripherals to become the XO Turtle Bot! This is a very
low-cost turtle robot based on a Tamiya motor assembly. All of the
extra robot components are optional—you can populate just the parts you want—but a classroom can now make
their XOrduinos (or XO Stick + XOrduino base) into standalone turtle
robots, controlled by Scratch, Turtle Art, or Arduino code. The XO Turtle Bot revision adds a motor driver, two bump switches, a simple 3-cell
power supply, and rotation sensors for the motors to the XOrduino. (Arnan Sipitakiat and Nussarin Nusen in their Robo-Blocks presentation for IDC 2012 explained that children find "turn for two seconds" hard to understand; we include motor sensors so that we can "turn 90 degrees" instead.) And of course because the robot is based on XOrduino, you can add
whatever other sensors you like and write arduino/Scratch/Turtle Blocks code for it.

I'm excited about the potential of low-cost robotics and the Arduino platform for
education. If you are, too, let me send you a kit so you can help
out!

The Literacy
Project is a collaboration between four different groups (as
alluded to by the title of this post): the One Laptop per Child
Foundation (“Nell”), the MIT Media Lab
(“Tinkrbook”), the School of Education, Communication and
Language Sciences at Newcastle University, and the Center for Reading
and Language Research at Tufts University (“Omo”).
The goal is to reach children even further from educational
infrastructure than OLPC has ventured to date. In particular, the
Ethiopia pilots are complete child-led bootstraps, attempting to teach
kids to read English (an official language of Ethiopia) who neither
speak English nor read in any language yet. There are no teachers in the village,
and no literate adults either.

Adapting Nell to this environment has some challenges: how do we
guide students through pedagogic material with stories if they don't
yet understand the language of the stories we want to tell? But the
essential challenge is the same: we have hundreds of apps and videos
on the tablets and need to provide scaffolding and guidance to the
bits most appropriate for each child at any given time, just as Nell seeks to
guide children through the many activities included in Sugar. In the
literacy project there is also a need for automated assessment tools: how can we tell that the project is
working? How can we determine what parts of our content are effective
in their role?

I'll write more about the Literacy Project in the coming weeks.
As we've started to get data back, some of the lessons learned are
familiar: kids do the strangest things! They learn how to do things
we never knew they could do (or meant for them to) and often are
motivated by pleasures which surprise us. For example, one app we
deployed had a sphere which deflated with a sort of farting noise when
the child picked the wrong answer. It turns out that the kids liked making the farting noise
much more than they liked the response to the correct answer! Obvious
in retrospect, but the lesson reminds us why we are pursuing an incremental development and data collection approach. Happily, the hardware itself
has been a success: low hardware failure rates, solar powered charging
is successful (although they prefer to charge the devices during the
middle of the day; we'd expected them to do so overnight from storage batteries charged during the day), and they've
mastered the touch interface very quickly on their own. The pilots
have been running since February, and the kids are still very engaged
with the content. So far, so good!

The board uses mostly through-hole parts, with one exception, and
there are only 20 required components for the basic Arduino
functionality, costing about $5 (from digikey, quantity 100). It is
reasonable for local labor or even older kids to assemble by hand.

It's open hardware: Eagle design files are on github (schematic PDF,
pcb PDF). I expect to have a small number of boards in a few weeks; let
me know if you'd like one in exchange for help with hardware and
software bring-up. Schematic and layout review also appreciated (I did the PCB routing late at night under time pressure leaning heavily on autoroute, it's certainly not the prettiest). And feedback from Arduino and Arduino shield hackers would also be welcome.

If $5 per student is too much money, there's also the XO Stick, my
second board. It's based on the AVR Stick using the ATtiny85 processor and costs only
$1/student. It's not quite as user-friendly as the Arduino-compatible
board, but it can also be used to teach simple lessons in embedded
electronics. For $0.12 more you can populate an ATtiny261A (though a '461 or '861 would be better) and get 13 I/O ports; this variant should be powerful enough to program other XO Sticks and perform XO maintenance tasks (accessing the serial
console, debricking a laptop via SPI flash). The XO Stick is even easier for a
kid to assemble themself: only 8 required components, all through-hole.
(Sadly, my desire to shave every penny off the cost of this design meant that I couldn't use some of the symmetry tricks I invented for a 2012 Mystery Hunt puzzle to make the circuit impossible to assemble incorrectly.)

Same deal as the XOrduino: design files on github (schematic PDF,
pcb PDF); I expect to have a few boards available to people who want to
help make some software for them. Schematic and layout review is also appreciated!

We're hard at work implementing Nell. We could use help in a number of areas: art, animation, story, user interface, javascript hacking, and probably others. For example, at the moment Chris and I are: drawing the characters, drawing user interface concepts, writing silly alphabet stories, animating the silly alphabet stories, doing the CSS/HTML layout to mock up designs, making some of the mock ups into functional demos, implementing HMM-based handwriting recognition in JavaScript, porting pyaiml to JavaScript, implementing an Apple Guide-style contextual help system on top of HTML widgets, and writing a integrated story editor (and stories about the story editor). I'd welcome volunteers for any of these tasks!

This year I was a member of Codex, the writing team for the 2012 Mystery Hunt. I'm going to describe some of the puzzles I wrote for "The Producers" hunt, in release order. BEWARE SPOILERS!

One of the early theme proposals for our hunt was "Alice in Wonderland." Casting about for novel meta ideas, I hit upon the idea of a round with purely numeric answers, 1 through 29,394, which would resolve to words via "looking glass numbers"—that is, numbering all the words in "Through the Looking Glass". It occurred to me that you could make your numbering system self-descriptive if you used certain words; for example, if you wanted to make clear that hyphenated words should be counted as one (instead of two), you could include "great" and "half" on either side of "arm-chair". The numbering of "great" (164) and "half" (166) would make it clear that "arm-chair" should be treated as a single number (165).

This didn't survive as a meta, but it eventually became a puzzle, called 1207 1370 (which translates to "Looking-Glass Words" using its enumeration system). It also served to ensure that teams had a good wordlist by the time they got to the Charles Dodgson meta...

Blinkenlights. A recursive-structured puzzle inspired by (but not reaching the greatness of) Derek Kisman's Maze from Setec's '05 Hunt. If anyone is mourning the lack of Jonathan Coulton-related puzzles from this year's hunt, blame me: I stole the answer PROTECTORS which Andrew Lin had earmarked for a JoCo puzzle. ("Did I say overlords?")

Caterpillars. I like giving physical objects to teams. This was another failed meta—you would have assembled the pieces out of words, then would have to assemble the jigsaw from the word-pieces. The location of the caterpillars' heads in the final assembly would spell out the final meta answer using an overlay. But the puzzle is more fun with tangible pieces, I think.

B.J. Blazkowicz in ‘Wintertime for Hitler’. I was writing the meta for this round and trying to find non-dictionary words. I needed "CAR..." as a prefix to make the chess game work, which suggested CARMACK as an answer, and the puzzle just wrote itself from there. Scott Handelman contributed the title. This puzzle was going to be distributed on 3.5" disks (remember how I said I like giving teams physical objects?), but the last 3.5" floppy disk puzzle was Blue Steel in '06. (Redundant Obsolescence doesn't count, since the 5 1/4" disk was redundant.) The past six years have not been kind to the 3.5" floppy; ultimately we decided we didn't want to deny teams the pleasure of playing the game because they couldn't locate a floppy drive. It's more important that puzzles be fun than hard!

Charles Lutwidge Dodgson meta. I began writing this puzzle immediately after the 2011 hunt, dissatisfied with the mechanism and final clue phrase of that year's Racking Your Brains. I thought I could write a better puzzle using Scrabble Solitaire as a mechanism.

Slightly later it became part of the "Alice in Wonderland" theme proposal, with Jabberwocky words. Then I spent a couple of months away from the hunt, getting married.

Upon returning we badly needed critic metas so I dusted off the puzzle, adding an Alice chess frontend yielding the tile string in order to make it a shell meta. The puzzle can still be solved as pure Scrabble Solitaire (ie, without the given "scores after each play") but it's easier for humans to solve with the frequent checkpoints given. For what it's worth, I constructed the chess game with a reasonably-deep alpha-beta search, so all the moves "make sense" as much as is possible given the constraints of the puzzle. And it ends in a clean checkmate, obviously... I have no idea how BENOISY snuck in there.

Ben Bitdiddle meta. The idea of making an electronic circuit which was impossible to assemble incorrectly had been in my "Mystery Hunt ideas" folder for years. A coworker at OLPC mentioned the odd power-pin configuration of the PIC chips one day, which gave me the "flip" mechanism. Brainstorming with Andrew Lin brought it the rest of the way.

I promise never to abuse an optoisolator in this way again.

(Of course it turned out when constructing this puzzle that Ben Bitdiddle really needed to use the show answers CARPAL and THESOUTH because of their length in morse code, so I ended up having to rewrite parts of Dodgson to make Bitdiddle work. In the rewrite CARPAL became CARMACK... and B.J. Blazkowitcz was born.)

JFK SHAGS A SAD SLIM LASS. One of my earliest puzzle submissions was, "A puzzle contained only in its title." Again, the fabulous Codex editor team turned this into a real puzzle.

Some puzzles I enjoyed editing:

Revisiting History — I commissioned a Doctor Who-themed puzzle for the answer TORCHWOOD (see the final clue phrase for the reason why) and contributed the "location of the word 'who'" mechanism.

Gibberish and More Gibberish. I liked the idea for this puzzle enough that I shoehorned a suitable answer into the Charles Dodgson meta... and then had to do some heavy lifting to get the puzzle finished and into the hunt.

Sounds Good to Me. It was immediately obvious this was a brilliant idea from Seth Schoen. But the twin barriers of toki pona and hiragana threatened to make it unsolvable. I'd like to think I played a role in making this an accessible and solvable puzzle.

And that's it for my puzzles! I also did a heck of a lot of other stuff for the hunt; I hope y'all enjoyed it. (My own favorite part was the wrap-up, since all my responsibilities had been discharged by then. I could just watch Patrick rock my hat and accordion, play along on ukulele, and sing tenor with Francis at the end.)

Here are some banged-together demos of various pieces of
One Laptop per Child's
Project Nell.
The ultimate goal is a Nell demo
for CES
in January 2012, but these bits should be considered as tech demos,
benchmarks, and proofs of concept, not actual pieces of that demo (yet).

Most of these demos require WebGL support. Visit get.webgl.org for information about
enabling WebGL in your browser; there is WebGL support in Chrome,
Firefox, Safari, and Opera—although it often requires enabling
experimental features in the browser preferences.

Tiles. Performance benchmark
for a tile-based home screen. "Apps" are "locations" on your world map,
which you can customize as you like. (Here's an interesting
blog entry discussing
world-creation for kids.) Day/night would ultimately reflect current
time, although they've been greatly sped up in this demo. Lots of
rough edges and missing UI, but all the textured triangles are
present, so it should be an accurate benchmark.
(Drag with left mouse button to rotate, middle mouse button to zoom,
right mouse button to pan.)

Quake on XO-1.75
(video).
Of course we need to actually run WebGL with good performance on XO
hardware. Jon Nettleton has been working hard on our GL drivers,
enabling the GPU on the XO-1.75 hardware for the first time.
This Quake demo shows his progress—don't worry, Quake is not
actually part of the Nell demo! (We have a GPU in the XO-1.5 as
well, which hasn't yet been utilized.)

Codify—not
one of our demos (it's a commercial iPad app) but it demonstrates
the direction we'd like to push Pippy.

Coming soon: TurtleArt and Implode for the web. We've started
converting them to GTK3 in preparation for hoisting them bodily onto
the interwebs. Here's the source
code repository for the TurtleArt port if you'd like to watch or
participate in this hackage. (See repl.it
for one of the more unusual ways to get Python running in the web
context.) The rest of the demo source code is on github (or just "View Source" in your browser).

Between now and January CES, Chris Ball and I will be building Nell for the OLPCXO-3 tablet.
Nell is a name, not an acronym, but if you want to pronounce it as
"Narrative Environment for Learning Learning," I won't stop you.

Nell's development will be demo-oriented—we're going to try to write the most
interesting bits first and learn as we go—so don't be upset if you
don't see support right away for legacy Sugar activities ("Sweet
Nell"), robust sharing support, mesh networking, or whatever
your favorite existing feature is. They'll come, but the new
crazy stuff is what we need to evaluate first.

Here are four of the big ideas behind Nell, along with pointers to some of our sources of inspiration.

Narrative. I probably don't need to restate that Neil
Stephenson's "The Diamond Age" has been hugely influential, and we also owe
a large debt to interactive fiction and the Boston IF group in particular. (Check out
the talks from our
"Narrative
Interfaces day" at OLPC.)
Wide
Ruled (conference
paper) and Mark Riedl
at Georgia Tech have demonstrated interesting approaches to story representation.
I'm also looking forward to the results of the Experimental Game Play
group's September Story
Game competition.

Emotion. The Radiolab podcast "Talking To Machines" crystallized my thinking about emotionally-attractive environments. The discussion with Caleb
Chung, the creator of Furby, is particularly apropos. Caleb's goal is
to make things which kids want to "play with for a long time," and he
contributes his three rules for creating things which "feel alive":
it must (1) feel and show emotions, (2) be aware of itself and its
environment, and (3) have behaviors which change over time. Furby's
pursuit of these goals include expressive eyes and ears, crying when
held upside down, reacting to loud noises, and gradually switching from Furbish
to English for its utterances. A living thing emits a
constant stream of little surprises. Expect to see Nell put the
XO-3's microphone and accelerometer to good use.

Talking and Listening. The "Talking To Machines" podcast also discusses ELIZA and Cleverbot, which
dovetails with my interest in the popular Speak
activity for Sugar and related toys like Talking Tomcat for
mobile phones. The key insight here is that a little bit of "cheap
trick" AI can go a long way toward making a personable and engaging
system. We want Nell to feel like a friend. Recent work by
the Common Sense Computing
Initiative at MIT's Media Lab shows how we can reset this on a sounder
basis and use mostly-unstructured input to allow the system to grow
and learn (creating "behaviors changing over time"). In particular, I'll cite ConceptNet for its
database and practical NLP tools, and inspiration from
"Empathy Buddy," "StoryFighter," and the other projects described in their
Beating
Common Sense paper. It's also worth noting that open source
speech tools are good and getting better (the VoxForge site points to most of them);
also interesting is this technique
for matching a synthesized voice to that of the user.

Collecting, nurturing, and rewarding. Collector games such as Pocket Frogs and
Flower Garden
are sticky activities which
encourage kids to come back to the device and continue working toward a goal over a long period of time.
Memrise
is educational software illustrating this technique: its users tend a garden of flowers by
mastering a set of flash cards. Nell will incorporate the sticky aspects of such games, possibly also integrating the Mozilla Open Badges infrastructure into an achievement/reward system.

I hope this has given you a general sense of the direction of our Nell project. In future
blog posts I'll drill down into implementation details, demonstration storyboards, and other more concrete facets of Nell.