Off the BEAM

My niece really liked the robot.  She wanted the robot after the show was closed.  Unfortunately the company has decided to hang on to it for a while.

So my first thought was; "Build her one."

But then the next thought, a much better one, was "Build one with her."

Which led to some rather complicated thinking about what that means.  The easy trap is to do everything yourself, but let the kid paint it.  An alternate route to a similar affect is to buy or make a kit and have the child assemble it according to instructions.

I find that belittling, not challenging.  Not fun, either.  But, really, the part that fascinates me -- as past entries in this blog should show -- is the developmental process.  The intersection between design aesthetics and the impositions of the production process.

So I'm leaning towards a thought like, "Work through the design and production process of a robot with her."  Which is to say; let her take an active role in deciding what kind of robot to build, and how it is to be built.

The big question in my mind right now is how much to attempt to teach or otherwise explore the methods of problem-solving themselves.  How much to go into project planning, milestones, iterative problem-solving, and so forth.

And last night I worked a lecture on 21st Century Learning and it largely touched on those same questions.  To wit, "How does one teach problem-solving?"  With an emphasis on play, failure, group dynamics, and other explorative, iterative, creative methods. 




To delve into my own primitive (but oft-used and comfortable) tool kit, the leading question is one of what level to bring her into the parameterization. 

It has been at the root of my own suite of problem-solving tools that problems are best solved at the appropriate level.  Okay; this is getting too theoretical and I need to explain with a concrete example.

Back when we had a lot more renters at our multi-use space, I'd have someone ask me for a stapler.  This would be the approximate dialog;

"Do you guys have a stapler we could use?"

"Yes.  What do you need it for?"

"To put in staples."

"What are you stapling?"

"We need a stapler to put up our scenery."

"What kind of scenery and where is it getting stapled?"

"It is for our set.  If you don't have a stapler we might be able to find one at the offices."

"We have a stapler.  I'd just like to know what kind of material, and where it is going."

"It's this stuff," they point at some heavy velor drapes.  "They're for our set."

"Okay.  You don't want a stapler.  First, staples won't hold that weight.  Second, we don't allow you to staple stuff to our walls.  We have pipes and drape clamps.  I'll help you hang those drapes up with those."

So, the problem appeared to be a lack of a stapler, and the client attempted to solve the problem on that basis.  The actual problem was hanging the drapes.  A stapler was part of a proposed solution.  When you moved out of the smaller box of "we need a stapler" to the surrounding box of "this drape needs to go up," there were better solutions in the larger box.

Around that box is another even bigger box containing the "What do we actually need for our set?" which might contain the information that, say, that the drapes aren't actually needed at all!

Associated with this is one of my truisms; "If you can state the problem completely and concisely, you will often find you just stated the solution."




So the container of "Make her a robot" is the one that contains questions about what kind of a robot, what kinds of tools, what kinds of production methods, budget, etc.  The container of the container of "Make her a robot" is the one that asks what the purpose of the project is -- the balance between play, pedagogy, and gift.  And somewhere in that box and the super-box around it are questions about my role as uncle and whether she or I can spare the time to do something together, with all of our other life demands.

Well.

Assuming I'm going to involve her at the level of the container that contains the parameterization of "Make a robot with her," the first questions to put before her are design goal and selected production method.

Taking the last first, in a rough sense this splits into choosing a kit, or choosing automated production methods, choosing that I do the heavy lifting (as far as fabbing), or -- and here the two goals truly entangle -- choosing a design goal that is appropriate for her to be largely involved in the fabbing.

On the over-arching pedagogical goals, each production method carries the potential for learn-able skills. 

I happen to believe strongly -- if I was a teacher in any sort of design or industry I would apply this in my instruction -- that manual skills are foundation skills.  That knowing how to solder, how to cut and shape metal, how to sculpt with the hands, how to paint with a brush all give you a mental framework by which the more modern, more automated methods (such as 3d printing) can be better understood.  That this sort of gut-level, intimate familiarity with the strength and ductility of metal you get from carving into it with a hand file (and similar properties of other processes) allows you to better intuit what is happening at the cutting head of a CNC turret lathe.

So I am biased towards an excuse to learn how to bend metal, solder, write in C, paint, etc.  But I also need to consider that some of these carry a potential for injury.  Kids are very focused, and mentally tend to be better at working safe (or so says a previous lecture I attended).  But there is a limit to the hand-eye coordination, and worse, there are two protective skills adults generally have learned.

These two skills are how to anticipate and work around your own tunnel vision -- how to predict that when you are getting frustrated trying to yank a just-desoldered component, you are liable to forget the hot soldering iron is right by your arm.  And how to make a positive choice towards risk or even towards injury when necessary to avoid a greater injury; how to make this split-second value judgments that allow you to move quickly.

I've been training a young sound person who has not yet picked up the latter.  On one show we worked, a sound effect started playing when it shouldn't have.  It took him several seconds to find the right button to turn it off.  My approach is to hit ALL the buttons.  Because it doesn't matter if you de-selected the window, changed the cue name, lost your place, even crashed the program; because all of those are recoverable conditions.  If you have several minutes before the next sound cue, do what it takes to stop the problem as quickly as possible...then go back and clean up.

Anyhow.

This being the future, and of course since high tech is always sexy, it also makes too much sense to consider introducing her to skills of programming, 3d modeling and printing, and other fab services; Ponoko for instance.  These are skills she can directly apply towards a variety of projects in the future.  Not only are various fabbing services becoming increasingly available to everyone, her other uncle already owns an eight-foot ShopBot!




As an aside; one of the enduring strengths of the modern Make movement, and the hacker-dom that came before it, and the Hams and Heathkit crew before that, is a form of domestication and colonization of what can otherwise be an alien world; the technology that surrounds us.

This isn't just high-tech, of course.  Even the process of cooking or clothing making can be a dread mystery, leading to a modern person having no more idea how a cookie or a dress is made than a dog understands how food gets into those metal cans.

And of course not being able to do them.  So all of these Maker movements are about unpacking the black box of consumer culture and saying "A dress is really just fabric and stitches assembled to a pattern."  And giving the confidence -- not always the ability, the important part is the willingness to try -- to do these things oneself.

Which frees you from being a passive consumer.  When you can look at an artifact and say "This one is built shoddy -- I know why they cut corners here, but I could build a better one," then you have more ability to pull aside the curtains of advertising claims and marketing hype.  And make better choices for yourself.

And you gain the belief that you can understand.  That whatever it is, that you can apply your own intellectual tools and your own experiments and experiences and learn more than is passively accessible on the surface.  And that you don't have to accept either the products or the answers you are given; given sufficient desire or need, you can make your own.

Deep philosophy for building a robot with a kid, eh?




So if you are thinking about learning about the black boxes of the current world, there are several artifacts of our present technology that are both mysterious and ubiquitous.   The LED is a minor example.  The microprocessor a major one.  More and more radio is around us; WiFi, RFID tags, the cellular network.  Sensors are becoming more common as well, from IR proximity to capacitance touch sensors to facial recognition software.  There are reams of scannable information just drifting out there, from RSS feeds to time signal to of course the GPS being beamed to most locations with a view of the sky.

These are all excellent black boxes a robot project is a good excuse to unpack a little.  There's also the more general conceptions of energy and materials; working on something like a robot gives you a better intuition of cost and density of energy in various forms, for instance.  Especially a solar-powered robot, where you can make a direct and intimate connection between sunlight and the amount of movement a robot can generate from the time it spends basking in it.

Of course, as a theater person I also have tremendous interest in traditional crafts skills.  Viewed as an art project, a robot could involve sculpting, casting, welding, sheet metal, cutting, vacuuforming, casting, and so forth.   The imagination is the only limit...add basic sewing skills and make yourself a Tribble for a housing.  Now what can you stick inside a featureless ball of fur that will interact in a meaningful way with the outside world?

And this mention of crafts segues to the BEAM Robotics movement.  One of the keystones of BEAM, as well as a basic part of theatrical crafts and Making in general, is the skill of using found objects.  Of how to recover what was junk, re-build it, re-purpose it.  Engineering, too, is a discipline where you take pre-tested modules and re-apply them for a new task.  Engineers don't go around re-inventing wheels -- not unless the wheel isn't optimal enough for the current problem!




The BEAM Robotics movement holds up as desirable qualities the re-use of techno-scrap, minimalist, function-oriented design, and solar power.  What I see as the major philosophical divide with Make philosophy is that when the Make aesthetic re-purposes existing technology, it does so to make use of the packaged power of internal electronics.  Make likes to hack into things with a fair amount of computational power, figure out what language they speak, and put them to new tasks.


So a Make approach to a robot would tend towards solving things at a software level; of taking large functional blocks like accelerometer chips, plugging them into a CPU that contains internal models (or rather, state variables) representing its environment, and then executes programmed behavior according to those internal states.

A BEAM robot, instead, has no central nervous system at all, and all complex behaviors are emergent from simple rules.  It doesn't model the environment or carry state variables.  It simply reacts directly, sensor-to-motor, to stimuli.

Of course the question above the question is what we mean by robot.  Do we mean to build a remote-controlled device?  Or one that is fully autonomous?  Or one that is a hybrid?

The "robot" I built for "Willy Wonka" had no autonomy at all.  The closest it got to emergent behavior was some randomness in how well it responded to the controls.

The "Square Candies That Look Round" I built for the same show had complete autonomy and were interactive, but they were tightly programmed around a small number of state variables.  Random number generation gave them some "life," but only a small chance of true emergent behavior.

I am fascinated by the possibilities of devices that have a true potential, but I also recognize that the behavior that emerges most of the time is getting stuck in a corner.  Although this is expected and even sometimes interesting to a cyberneticist, I am not sure the best project to go into with a young person is one in which there is a large probability the first thing the newly-completed robot will do is.....sit there doing nothing.

(Which my candies did over a long period of software writing.  Plus they seemed to see ghosts at one point -- turned out the waxed paper hung down just low enough to give false reflections to the IR sensor.)

(There's another interesting bit about the Square Candies That Look Round.  Most of the people that came up to them proceeded to engage in primitive experiment to try to determine the parameters of response.  Which is to say; they'd wave at them to see if the candies "noticed."  Since the state variables were hidden, complex, and ruled by a random number generator in addition to the IR proximity sensor, this proved difficult.  I don't think I ever witnessed someone independently working out the behavior rules for the candies for themselves.)



So where does all this leave me?

Pretty much, where I need to talk to her.  Does she want to do the project?  What kind of time and emotional investment would she be willing to put into it? 

Is her interest more towards aesthetics (aka, what does the shell look like), functionality (as in, towards a robot that can be driven or an arm that can pick stuff up), or cybernetics (as in, autonomy, state models, emergent behavior, interactivity).

And for that matter, what is her internal world model?  How much does she grasp yet of what electronics are capable of, what intelligence may or may not be in simple devices?

Except I guess I do still have a question for me, before the next time I see her.  And that is; is there some kind of trial balloon I can float that is a less-elaborate exploration of one of these processes?  Such as, a simple "robot" that is already partially functional but that she can take and do something with?

I am shying away from the idea of "here's the robot, now paint it how you like it."  Because that is a use of crafts skills that doesn't engage the underlying "robot" in any meaningful way.  You might as well paint a vase.  Same for any other cosmetic -- trivial -- customizing.

Unless of course that is what attracted her to the robot I built.  The shape, the design.  In which case, sculptural methods are the thing we should explore together.  So this is more like a prop-building project than a robot-building project.  And in that case it might be appropriate to say "You build the box, I'll stick the electronics in it."

On the gripping hand, however, maybe those basics of control and interaction and even emergence are what interest her.  In which case, I have to ask if she is ready to be handed a functional chassis of some sort and the tools to work on the software. 

I know her siblings -- both a few years older, both extremely comfortable with mathematics and with logical reasoning -- could handle code if dropped into it.  I do not know if this child is up to being confronted with raw C in its native habitat (or even tame C in the petting zoo of the Arduino IDE).  But something about graphic-oriented beginner languages (like Etoys) bugs me.  Probably they are designed towards learning transferable core concepts of programming.  But despite the uphill battle of dealing with the syntax of a less abstracted language, I think it takes less time to go directly to a fully functional language.

Maybe....and this is getting ever-further afield from any concept one might think of as "robot," the think to try her on is as basic as a blinky and a laptop with a stripped-down, bare bones blink program on it.  And start right there, with the "Hello world" of the embedded computing world; with messing around with variables and simple loops to change the blink.

Hrm.  I do have that Arduino-compatible BlinkM lying around....