Finding Innovation In Africa — support my IndieGoGo campaign!

My campaign is live! Wonderfully, we raised over $2500 in the first day — a quarter of the way there! There’s still a ways to go, though, and I’d love your help, either by kicking in some cash (and getting a copy of the book in return) or by sharing the love.

Here are a couple of frequently asked questions about the project:

Do you have an actual itinerary?

Aside from a general schedule for flights, not yet. I plan to spend two weeks in and around Lagos and two weeks in and around Nairobi. But that will probably also include short trips to nearby cities like Accra, Ghana, which is only about 350 miles from Lagos, and I’ve committed to making a trip to Kilimanjaro, which is 150 miles south of Nairobi.

Once the trip is funded, I’ll be nailing down more specific plans. I already have some contacts in each city I’m reaching out to, and I’ll set up meetings with them.

I don’t have any idea what hotels I’ll be staying in or anything like that. When I travel, I tend to find the least expensive places I can reasonably stay in. In this case, the only things I really need are a door that locks, a private restroom, and air conditioning (not out of luxury, but to keep out mosquitos that carry malaria).

I also believe in serendipity — often I find the most interesting things just wandering around or by chance encounters.

Aren’t you promoting what Evgeny Morozov calls “solutionism” with this project? Are you saying that all Africans need is technology to prosper?

No, and no. I don’t believe technology is a panacea for every problem, and certainly not for the problems Africa faces. My sense is that Africa’s problems are fractally complex at every societal level, just like anywhere else — economic, cultural, social, and of course a big heaping dose of post-colonialist nightmares.

That said, I think some of the serious problems facing sub-Saharan Africa are problems that can be solved — or at least alleviated — with technological and engineering solutions. I’m just not sure which ones, which is why I’m making the trip.

More to the point, though, I’m not necessarily looking for “answers” to big, intractable problems. I’m just really interested in what people are making there, from a nerd’s perspective. Hopefully I’ll be able to maybe put some of the pieces together as I go.

Where did you come up with the $10000 figure? Do you have a budget?

Yep! I have a rough budget based on Internet research — checking travel advice sites and such. It looks something like this:

  • Airfare: $2500 (including taxes, airport fees, etc)
  • Hotels: $50/night x 30 = $1500
  • Food: $30/day x 30 = $900
  • Vaccinations: $1000
  • Transportation (buses between cities, taxis, etc.) $1000

Those are estimates, rounded up for safety’s sake, but that brings us to right around $7000. The other $3K is for anything else — bribes, unforeseen stuff — and to pay my bills at home while I’m gone.

$10K sounds like a lot, but for a month overseas it’s actually kind of low. And if anything serious happens — like I get hurt or really sick — I might be in trouble. But, hey, c’est la vie.

So what happens when you get back?

I put the book together. I’ll be writing it as I go along — both taking notes and also writing actual prose. I’ll be sending it as I write it to an editor back here in the States, just in case anything happens to me — I want to make sure that, no matter what, my backers get a finished product, even if something goes pear-shaped. When I get back to Vegas, I’ll be working with my editor to assemble the final book, as well as designing the deluxe edition — in addition to being a writer, I’m a pretty decent graphic designer as well. When it’s done — I’m estimating the end of January, 2014 — I’ll be sending it out.

Will there be a print version?

There will definitely be a print version for backers who selected one as their perk — it’ll be printed on demand for them. Will there be a mass market edition? That remains to be seen. I’d love to get a publisher who’d like to make that happen.

Isn’t this a bit dangerous? Aren’t you worried about it?

That’s a complicated question. The answer is: no, I’m not, but not because I don’t think there’s an element of danger. My experience traveling is that most places that aren’t active war zones are pretty much like any other places: as long as you don’t act like an asshole, you’re usually fine. That was my experience in Juarez, and I suspect it’ll hold true in Lagos and Nairobi as well.

But there are risks, and I’d be an idiot if I wasn’t aware of them. There are anti-American Islamic groups in both cities. Both cities have terrible poverty, and the street crime that inevitably follows. Also, I’m a 6’3″ burly white man. I don’t blend well in Africa.

There’s also the fact that I’m trying to put together one side trip that, if I can arrange it, will be ludicrously dangerous, which is why I’m not divulging it publicly yet — I don’t want to broadcast what I’m doing.

The thing is: I don’t really much care about my personal safety, to be honest. I’m more interested in telling the story I want to tell. I’m not reckless, but I’m not overly cautious, either, and if shit goes down, shit goes down. That’s why I’ll be transmitting my writing and notes daily.

Don’t get me wrong: I’m not looking for trouble. I’d like to avoid it if I can. But I need to be exposed to do this the way I want to do it, which is why I won’t have a driver, a guide or security of any kind (other than myself).

Will you bring me something back from Africa?

Not to be a jerk, but: probably not. Remember, I’m going to be moving around a lot, and carrying at least two bags (one for clothes, one for gear). I’ll probably take another small bag folded up in my clothes bag for souvenirs, but I can’t promise anybody anything.

I could probably bring you back malaria, though, if you asked nicely.

Africa Book – Crowdfunding

So I’m finally in a position where I can make the trip to Africa I’ve been wanting to make for most of my life, to write a book about technology in sub-Saharan Africa — the technology industry, but also how technology is evolving there and how Western governments and companies can help Africa develop its own technology ecosystem.

My loose plan is to orbit around two cities: Lagos, Nigeria and Nairobi, Kenya. Both are relative hubs of technology in SSA, but culturally and economically they are very different. Ideally, I would travel to rural areas near these cities as well, to see how technology could be introduced to make life easier for rural Africans.

My goal is to ask for USD$10,000. That might seem like a lot, but it’s a realistic number based on my financial calculations. Airfare from Las Vegas to Africa, even economy class, is very expensive, as are the necessary travel immunizations. I also need to be able to pay my bills while I’m gone, which are modest, and be able to afford to take time to compile and put the book together post-trip.

I’ve compiled an initial list of flex goals and perks below.

Flex Goals

  • $12K — I will purchase a DSLR to do better photos (assuming nobody will let me borrow one).
  • $15K — I will expand the trip to include Ghana and possibly Senegal.
  • $20K — I will take a professional photographer with me.
  • $25K — I will take a camera crew with me and film a documentary.

Perks

  • $5 – Thanks in the book.
  • $10 – Digital copy of the book (ePub, lit, pdf) + thanks.
  • $20 – Limited edition digital copy with scanned notes, pics, etc. + thanks.
  • $100 – Signed print-on-demand copy of the book + limited edition digital + thanks.
  • $1000 – I will deliver a talk or consult with your organization or with you, either via phone/Skype, or in person (travel expenses to be paid by you) + limited edition digital + thanks.

My time limit for this is two months, which will give me enough time to prepare for the trip.

So what do you think?

Righteous Kill

Like most Americans, I’ve been thinking a lot about guns these past few months, since Aurora and Sandy Hook. And like most Americans, I’ve come to a series of conclusions and convictions about the gun control debate; a position I find morally and ethically solid.

And I’ll tell you about it. But first I want to tell you about my own personal culture of violence. Maybe just to get it off my chest, but maybe also to explain why I feel the way I do.

———-

The first time anybody pointed a gun at me, I was fourteen or fifteen, I guess. I lived with my mom and my stepdad in a trailer park a few miles outside of Hamilton, Montana. We were poor, then: poor enough we didn’t have a telephone, poor enough that our primary source of heat was a pot-bellied wood stove that sat on a porcelain riser in the middle of our trailer’s living room, for which I split endless cords of wood in the side yard with a hand-held hatchet. It was grueling, tiring work, and I avoided it when I could.

Mom and Dad were out that night, though I can’t remember where or why. What I do remember is the sharp, rattling banging on the door of our trailer — a door made of thin, crenellated sheet metal with cardboard inside.

I peeked through the narrow window of the door and saw, outside, a group of boys. I knew them all, knew they hated me in the way that small-town bullying assholes hate anybody weird or different. A couple of them hated my mother and I, because of a dispute with their mother.

There were, I think, four of them. Maybe five. And two of them held guns. I didn’t know anything about guns, but these were semi-automatic handguns, not revolvers. They were grinning at me like feral dogs.

One of them held his pistol up. “Come out, faggot,” he said. “Come out, bitch.” The others took up the chant — come out, motherfucker, come out, faggot — as they waited, patiently, for me to open the door.

I remember the fear so clearly: that hideous rising sensation in your upper chest and your throat, like somebody blew up a helium balloon inside you that’s trying to take off. I had no idea what to do. My parents were gone, we didn’t have a phone. I couldn’t call the cops, and even if I could, they were miles away, in town. Screaming wouldn’t help — in that trailer park, screams weren’t especially unusual. I was at a loss.

To this day, I still don’t know why I walked across the tiny living room of the trailer and picked up the wood-chopping hatchet. I took it back to the window, showed it to the boys through that thin strip of safety glass…and slammed it, as hard as I could, into the door, as if I was going to hack through it and go after them. I think I was screaming, at the top of my lungs. I remember baring my teeth at them, through the door, and if anybody was feral that night it might have been me.

“Alright,” I said. “Here I come.”

They looked confused, uneasy. Then they began to back away. They jumped in their car and drove away. I was left still standing behind the door, which now bore a bright shiny wound in its ugly brown facade. That’s how I know they use cardboard to fill out trailer doors, you see.

I caught hell when my parents came home. I couldn’t seem to make them understand my fear. All they knew was that I’d trashed the house. I don’t know if they believed my story or not.

Nor do I know, even now, if the guns those boys had were “real” guns or pellet guns…or if they actually would’ve shot or killed me. Maybe they just wanted to scare me. Maybe they would’ve stood around me in a circle and beaten me, as they did before and after that night, or just pistol-whipped me. I don’t know. But I do know that was the night I learned a secret that kept me alive and free of permanent physical (if not emotional or psychological) damage throughout my turbulent, violent adolescence.

If you can’t talk or fight your way out of a situation, go crazy. It’ll usually scare ’em so bad they run away.

———-

Based on their rhetoric, I suspect that most gun advocates have the same fantasy running through their heads when they start talking about why they need a gun for home defense. It’s the one where they awake in the middle of the night from a deep slumber at a gentle, unexplained noise from downstairs — a door whispering open, perhaps, or a window sliding up.

They reach into their bedside drawer and pull out their Glock or Colt or whatever their weapon of choice is. They slide out of bed, Honey Bunny still blissfully unaware and sleeping by their side, and through the bedroom door and silently down the stairs, like Jason Bourne, until they reach the ground floor. They peer cautiously around the corner. There’s the perp, his hands deep into the wife’s jewelry case.

Hands up, they cry, or I’ll shoot!

And here’s where I think the public version and the private version of that fantasy — the version they’ll admit to, and the real one inside their head — diverge. In the public version, the perp puts his hands up, and Honey Bunny calls the cops while our suburban Jason Bourne keeps his piece carefully aimed at the center of the perp’s mass, and the day is saved by a careful and conscientious gun owner. And, of course, the Second Amendment, God bless it and keep it.

But I believe that, for many of these people, the private fantasy ends differently. It ends with the perp whirling, his own (illegally-obtained) gun in his hand, ready to kill. He’s fast…but our Constitution defender is faster, and before you can say “cold dead hands”, the perp’s brain is spattered all over the Thomas Kinkaide painting Honey Bunny got for Christmas two years ago. Another evildoer sent to Hell. No great loss.

I think that’s the real fantasy…because I’ve had it myself, a time or two. I’m pretty sure it’s damn common, this blood-spattered Walter Mitty alpha male daydream of the righteous kill. It’s kissing cousins with those other popular current reveries: If I’d Been In That Theater, I Woulda Put That Sonofabitch Down and, of course, If Those Teachers Had Had Guns, No Children Woulda Died In Connecticut That Day.

These phantasmagories are, perhaps, the real American Dream.

And dreams are all they are, of course. If you want a nightmare instead, you might try imagining a Colorado theater full of confused, angry people, bombarded by the sound and light show of a Batman movie cranked to full sensory disrupt hanging over them like an Old Testament spectacle, not to mention the screams and panicky jittering of all those folks around them, pulling their trusty handguns and attempting to make the righteous kill, to hit that one “perp”…who, of course, is only one of many people with guns in their hands. In the flashing, strobing darkness.

Christ, they’d still be hosing the ticketholders off the walls.

And that’s still not as bad as the nightmares that plague the sleep of those unfortunate, stupid souls who head downstairs in the small hours of the morning, ready to heroically defend their castle against the junkie or rapist who’s intruded into the sanctity of their home…only to find themselves staring at the son or daughter who decided that was the night to sneak out to go smoke cigarettes and drink cheap beer with their friends, lying on the linoleum, making a noise like a hooked fish as their lungs fill up with blood, thanks to the .357 round that’s suddenly turned their chest cavity into an object lesson in fluid dynamics and entropy. In those nightmares, our Jason Bourne is kneeling next to their dying child, shouting Baby? Oh my God baby I’m so sorry somebody call 911!as their offspring bleeds out and becomes nothing more than a carefully-dusted photograph on the mantelpiece.

Over and over again. Forever.

———-

I know about fear. I know about the terror of the sound in the night, the monster in human form showing up at your door with a weapon of personal destruction. I’m almost thirty-five years old and I still automatically look for the nearest exit in any room I enter. I still walk down the street with a mental model in my head of every pedestrian who is nearby, where the dark corners are that an attacker might spring from. When I hear a car engine suddenly rev up nearby, I automatically tense up, just in case it’s the same sonsofbitches who roared past me in their big fruity Chevy pickup that soft spring night when I was sixteen and pegged me in the back of the head with an unopened can of Rolling Rock, knocking me semi-unconscious into a ditch, where I lay until I came to my senses.

And I understand rage. I understand righteous indignation, wanting to bring the holy fire down on the heads of the cruel and the evil and the stupid. I understand the unspoken hope that some stupid bastard is dumb enough to actually break into your house…because then, as Rorschach says in Watchmen, you’re not trapped in there with them; now, they’re trapped in there with you. I understand wanting a reason to hurt the ones you’re afraid of.

———-

One day, this kid Nick tells me he and his friends are going to beat the shit out of me before school the next morning. I don’t mean the kind of ass-beating you see in movies about how high school sucks: I’m talking about an American History X-style stomping, the kind where somebody can end up in the hospital, or dead. (The kind that a similar set of ignorant trash gave my acquaintance Matthew Shepherd a couple of years after he got out of high school, in fact.) I had no reason to doubt him. He wasn’t the first to make such a threat, or carry it out. I had my nose broken for the first time a few months before those boys showed up at my door; a few months later, another similar set of boys kicked me until they broke a rib.

So I went home that night, and I looked through my library, this being before Internet access was especially common, until I found a book that gave a description of how to make napalm out of Ivory soap and gasoline. I decided this was my only answer. My parents didn’t seem to much give a shit, and most of the authority figures in my life seemed to despise me as much as the other kids did. So I was going to light this motherfucker Nick up like the goddamn Tet Offensive.

Thank God I didn’t have access to a double boiler, or gasoline, for that matter. Instead, I mixed a bunch of isopropyl alcohol into liquid dish soap, poured it into a Tupperware container, and shoved it in my backpack. I couldn’t find a lid for the Tupperware, so I wrapped it in Saran Wrap.

The next morning, I got to school a half-hour early with my package of death, and decided to pour a little of it on the sidewalk and test it — kind of a trial run. And of course, it did nothing at all — the alcohol had either evaporated out of the container, or my mixture was wrong. Not that it would’ve done much in either case anyway.

My one moment of Columbine-style mayhem was over before it began. Instead, when Nick showed up, he called me a faggot and punched me hard in the face once, and I fell over and cried like a sissy, and everybody laughed, and he went on his way, his adolescent ego maintained and my own kicked down another flight of stairs.

It terrifies me, in retrospect, to think what would’ve happened if I hadn’t been such a retard — if I’d melted Nick’s face off his skull. He was a brutish, vicious little asshole, but he didn’t deserve that. Nothing righteous about that little bit of wetwork.

But it doesn’t terrify me nearly as much as the thought of what would’ve happened if my dad had owned a gun.

Two of my friends, those first couple of years of high school, got their hands on a gun. Both of them used those guns on themselves, though from all accounts they might’ve done better to start with other members of their households. But they didn’t. Both of them went out into the Montana wilderness and put those guns in their mouths, and ended everything they might ever have been. The second one, my friend Sarah, went into the woods in November; they didn’t find her until the snow began to thaw in February, and by then there wasn’t enough left to fill a bucket. Her casket was closed at the funeral.

And I might’ve joined them, in my misery and terror, if there hadn’t always been a little titanium core of self-preservation at the center of my wobbling teenage self. Or I might’ve showed up in my high school one day with the intention of, as Stephen King once put it, “getting it on”.

When Columbine happened I was twenty-one years old, still young enough that those wounds were still bleeding…and my first thought, when I heard what Eric Harris and Dylan Klebold did, was empathy; not with the murdered, but the murderers. I knew — or thought I knew — how it came to that, how the hurt and the hate builds up. I remember that high school feels like a life stretch in a big house where the guards don’t pay attention and the other prisoners all want to fuck you up until you go crazy. I got it.

I was wrong, of course. Klebold and Harris weren’t purveyors of the righteous kill, either, any more than I would’ve been with my little Fauxlatov cocktail. They were victims, but as the main character in my favorite high school movie said: aren’t we all? They were just animals, as dumb and mean as the animals who wounded them. Animals, the way James Holmes is and Adam Lanza was an animal.

But unlike real animals, they had their guns. Lots and lots of guns.

———-

America does have a culture of violence, make no mistake about it. But that culture is not embodied in violent video games and movies and comic books, or any of the other culprits that gun advocates like to trot out whenever some waterhead goes over the high side and starts mass murdering people.

The violence in America is embedded at the very heart of our culture, in those core values that nationalistic jerkoffs love to trot out at every opportunity: our rugged individualism, our can-do spirit, our supposed toughness. (I say “supposed” because it’s hard to regard people as tough when they’re so terrified of every shadow that they feel the need to carry military-grade munitions to protect themselves. That, speaking for myself, is the definition of craven and chickenshit. But I digress.) America’s motto might as well be Fuck You, I Got Mine. America isn’t about intellectual freedom, it’s about property rights and the ability to defend the same from anyone who encroaches upon them. What’s mine is mine, and if you try to take it, I’ll kill you: that‘s the American way.

That’s where our love of guns comes from. Guns are a marvelous tool for defending our property from those who might like to take or damage it. It’s hard to imagine that conservative Second Amendment advocates really give much of a shit about totalitarian encroachment upon freedom; after all, they’re the ones who cheer the War on Drugs and the War on Terror, who have nothing to say as our lawmakers sidestep not only the letter but the spirit of the Constitution and allow indefinite detainment without trial and assassination of American citizens. Their fear is not about the erosion of basic human freedom; they don’t care about free speech, due process. They care about anything that threatens their right to own the things they own and to keep them, without question. That’s why those self-same defenders of the Constitution mostly stood by idly while George W. Bush used 9/11 as an excuse to wipe his ass with that sainted document…but squawk like ugly, hysterical hens when Barack Obama tries to figure out ways to ensure that all Americans have access to basic healthcare. Because that’s taking money out of their pockets, and putting it into the pockets of all those freeloading immigrants, yadda yadda yadda. And money trumps freedom, every time.

The problem is not that Americans have guns. The problem is that Americans, by and large, cannot be trusted with guns: not to carry, and maybe not to own.

There’s another fantasy that the NRA and their groupies like to trot out: the Law-Abiding Gun Owner. These people are the last line of defense against the Bad Guys, in this line of thinking — a different breed, one feels. But that’s bullshit. James Holmes was a law-abiding gun owner right up until he walked into that theater in Colorado. Adam Lanza’s mom was a law-abiding gun owner, but that didn’t stop her psychotic son from taking her guns, killing her with them, and then playing Call Of Duty in the local elementary school. Everyone’s a Law-Abiding Gun Owner, right until they become a Bad Guy. And it’s nearly impossible to tell who’s going to take off their white hat and put on the black one, or when. In the wake of Aurora and Sandy Hook, a lot of people called for better mental health access in America; and while that’s fine, and I agree with them, the reality is that people like Holmes and Lanza don’t go looking for help very often, because as far as they’re concerned, they don’t need help. They’re the heroes in their own stories; it’s everyone else that’s insane and malign. It’s everyone else who needs to be dealt with.

But those are crazy people, goes the response. Evil people. Not good people. Maybe, but you know what? Difficult as it might be to institute a moratorium on the public and private sale of assault weapons, it’s still a helluva lot easier to implement than a moratorium on crazy, or evil, or just being a stupid thoughtless tiny-dicked jerk-off who carries a piece because it makes you feel like more of a man.

You can’t ban crazy. But you can make it harder for crazy to go crazy in such a very wholesale way.

Also, let’s clear something up right now: the Constitution of the United States does not confer upon you, the American citizen, the right to own a semi-automatic weapon. It says this, and only this:

A well regulated militia being necessary to the security of a free state, the right of the people to keep and bear arms shall not be infringed.

 If you define “arm” as a synonym for “weapon” with no qualification, well, homie, sorry to disappoint you, but that particular right was infringed upon a long goddamn time ago. If you don’t believe me, walk down Main Street of your town with a broadsword strapped to your back. Unlike a pistol, you can’t get a permit to carry a sword, concealed or otherwise. (This despite a fairly conspicuous lack of mass decapitations, or innocent children getting killed accidentally during a slash-by.) Your right to keep and bear that particular sort of arm was infringed upon, in most American jurisdictions, in the nineteenth century.

On the other end of the spectrum, there’s nuclear bombs. A nuclear bomb is an “arm”, by anyone’s definition, and frankly, if your concern is a sinister (i.e. liberal) government instituting a totalitarian overthrow of the country, I’m pretty sure a nuke is a better deterrent against the unholy might of the United States military than your trusty Colt .45. But even the most rabid NRA activist wouldn’t argue that you ought to be able to own a nuke, or mount an antitank missile launcher on the roof of your pickup truck. Hell, very few people would say that it’s reasonable for you to be able to carry a grenade launcher or a Vulcan minigun…and yet these are, by definition, “arms”.

So we all agree there are some weapons that nobody needs to have. Why not put assault weapons in that category? They’re useless for home defense, unless you’re getting home invaded by the fucking Predator. Ditto game hunting, unless you just really want to skip the whole pesky step of turning your elk meat into jerky. It’s really fun to go and shoot them at a range, but so what? It’s fun to go fishing with dynamite, too. The fun factor is outweighed by the risk to society at large.

And I’m going to say this right now: if you can’t adequately defend your home with a shotgun or a low-capacity handgun, if you seriously believe need an AK-47 with a 30-round clip, you’re a stupid, dangerous asshole, period, and I’ll be happy to tell you that to your face. I hope you don’t have kids, partially because they’ll be in your line of fire, and partially because I simply hope you’re not in the breeding pool. Let’s leave the continuation of our species to people worthy of that task, okay?

Me? I keep a machete leaning against the wall next to my bed, as my absolute last line of home defense. My first line, mind you, is the set of bars on my windows and doors, which are far more effective than any gun could ever be. My second line of defense is that ‘Emergency Call’ button on my cell phone.

As much as I enjoy my own little preemptory revenge fantasies where I’m Liam Neeson in Taken, with that much-vaunted “particular set of skills”, the reality is that I don’t actually want to kill anybody, not even some idiot who’s desperate enough to try and break into my house to take what I have.

———-

I’ll tell you one more story, before I’m done.

Back in Hamilton, back in the day, there used to be a little rec center, in a big cavernous building that used to be a supermarket. I have no idea if it’s still there or not; I’ve never returned to that place since I left, and I’m grateful for that fact. But when I was in high school it was there, and we used to go down there and dance to the grunge music that was popular in those dim dead days, and stand outside smoking and drinking filched booze mixed heavily with soda and trying to look cool.

One night, in some fit of melodramatic teenage angst, I wandered away from the rec center and out past the lights of the parking lot, into the empty field next door. There was probably a girl, or the lack of one, involved. You know how it is.

I was too busy brooding to pay attention, until I heard the rustling of feet in the grass. I looked up and saw them: another group of boys (and one big hulking slab of a girl, not coincidentally the sister of one of the boys who’d shown up at my door that night with guns). They’d seen me drifting away; they followed me.

The leader was this kid named Sam, as I remember. He wasn’t big, but he was mean and stupid, in that sort of snarling juvenile delinquent kind of way. At the end of that school year, when he was seventeen or eighteen, he dropped out to go drive big rigs with his old man, full-time, and I never saw him again. But he was there that night, grinning at me. I don’t remember exactly why he hated me. Did I smart off to him? Make him feel stupid, as payback for him making me feel terrified?

Does it even matter?

They surrounded me. There was the usual talk. Hey, faggot. You think you’re funny now, faggot, you fuckin queer cocksucking fucking bitch? For a man who’s never touched another man’s penis in my life, I’ve gotten gay-bashed more times than I’d care to count. I don’t know if they actually thought I was gay, but again: does it even matter?

Then they started spitting. All of them. Big, gooey loogies, on my face, my neck, the back of my head, my clothes. Laughing as they did. All of them but Sam. He just stood there, two feet away from me, grinning his sick grin.

Whatcha gonna do, faggot? You wanna go? Come on, faggot.

And I had a moment of absolute clarity. Everything went cold and clear. This was years before The Matrix, but my world went into bullet time.

I saw that I could reach up, grab Sam by either side of his head, and break his neck. I could do it before he could react, before any of them could react. I knew I had the physical strength to do it: I had already nearly reached my full height of six foot three then, and I could pick up a washing machine from a dead lift and put it on the back of a pickup truck. I was bullied not because I was weak, but because I was slow, and couldn’t really fight very well.

But I didn’t need to fight Sam. I could just put my hands out and kill him, in an instant.

I could feel my hands twitching, eager to end all of this in that one instant.

You probably think I was wrong, or that I was fantasizing. But I’ve thought about this a lot over the last twenty years, and I remain as convinced now as I was that night that I was absolutely correct in my assessment of the situation. At that moment, though I was the one surrounded by jeering enemies, their phlegm dripping off my nose, I owned Sam’s life. It was mine to end, if I wanted.

My hands went up…and then down again. I didn’t kill Sam. I just stood there, trembling with fury and fear and misery, my tears mingling with the spit on my face. I don’t remember how it ended. I think maybe one of my friends happened to see what was happening and came up, shouting at them to leave me alone. Maybe Sam belted me one, or knocked me down, or just called me a faggot again and walked away. I have no memory of that.

Just Sam’s face. Just his grin in the dark of that field, and the knowledge that I had the power of life and death in my crude boy’s hands.

———-

“It’s a helluva thing, killin’ a man,” says Clint Eastwood in the sublime Western film Unforgiven. “Take away all he’s got, and all he’s ever gonna have.” I don’t think most Americans really understand that. We don’t understand that there’s no such thing as a righteous kill, not really: just murder, and you’re on one side of it or the other. We love our guns because we don’t really understand what they do. They don’t solve the problem. They just make new ones.

Did Nick, he of the napalm science experiment, deserve to die? Did Sam? Of course not. They were vicious boys, and I still cannot bring myself to forgive them or wish them well, though I am satisfied with the knowledge that both of them probably ended up with precisely the sort of lives they deserved. But they didn’t deserve death.

Nor did I deserve to kill them. Even if I’d been justified in doing it, even if I’d somehow managed to avoid prison or long-term confinement in a mental hospital, I still would have had to live with the ache and knowledge of what I’d done for the rest of my life. The fear and the horror they and all the others like them inflicted upon me, for all the years I was forcibly detained in the Guantanamo Bay we laughingly refer to as the American educational system, is nothing compared to that.

At the heart of America’s rage is fear, as it was at the heart of mine. We have our guns because we’re afraid of being hurt, of losing what we have — our lives, our loved ones, the things we’ve accumulated that form the mosaic of our lives. And like all frightened things, we act savagely. Back a dog into a corner and see what he does in his fear. We do no different.

And that’s why I don’t think we can be fully trusted with guns, ever; why other countries have as many guns but less deaths, less mayhem. The worst of us are the ones who want to share their pain and rage and confusion with others, the Eric Harrises and Dylan Klebolds and Adam Lanzas and James Holmeses. But even the best of us are dangerous in their terror.

There’s an old saying: no man who actually wants to be President is suitable for the job. Likewise,  I don’t think that anybody who really wants a gun should be entrusted with one. I know this might offend my friends and acquaintances who are gun advocates, but I don’t trust anybody with a gun. Because I don’t trust that any individual has the skill and the wisdom to decide who deserves to live or die, and to carry out that decision. I certainly don’t.

Would a ban on assault weapons end murder? No. But it would make it harder. And anything that makes it harder for people to kill each other is probably a good thing, in my book. But maybe our real task is simply to help people learn not to live in fear: to be careful, but not paranoid, and not so eager to see violence done. Maybe then we can be trusted with the power of life and death.

But until then, I will keep advocating to keep that power out of all of our hands…and thankful that, upon those awful occasions when it was in mine, that I was at least smart enough not to wield it.

If the tech industry worked like the music industry, continued.

“Hey, it’s my rock star devs! How’s it going, guys?”

“It sucks. We busted our ass for months building this thing, and we can’t make enough money to pay rent. We’re all living in the same house.”

“That sucks, but look: you’ll make your money on the next app. That’s how it works. Aren’t the t-shirt sales paying rent?”

“Are you kidding me?”

“Hey, that’s the New Media model. It’ll all work out somehow. So what can I do for you?”

“It’s about this web app aggregation thing, that lets people pay one fee and use any web app they want…what’s it called, I forget….”

“Yeah, I know what you mean. We signed a deal with them a few months ago. What about ’em?”

“It sucks! We were getting $2.50 per unique user account creation, but now nobody wants to even sign up directly! They’re using this aggregator, and we’re getting three-hundredths of a cent when a new user uses the app!”

“Yeah, they’ve got really good lawyers, kid–“

“And that’s not the worst part! When we complain about it, everybody on Twitter says we’re fucking greedy assholes, and we ought to be giving the app away for free and making money off t-shirt sales? I mean, do any of these idiots actually know how shitty that money is?”

“Look, you’ve just got to accept it. This is New Media. If you complain, you’re part of the Old Way and you’re atavistic dinosaurs.”

“Man, all we wanted to do was write software and get paid to make it. This is just…I don’t know….”

“Look, this industry is always a gamble, right? You knew that.”

“But our app is popular! People are using it ten thousand times a day, using the aggregator!”

“So what are you complaining about?”

“We’re making thirty goddamn dollars a day!”

“Hey, sorry kid, that’s how things work in this brave new world. Look: why don’t you go get a day job? Maybe work at Starbucks.”

“Why not? I’d make more fucking money!”

“Do it. Of course, remember, you’re contractually obligated to deliver two more web apps in the next two years, and you still need to pay off that advance based on your royalties–“

“Thirty dollars a day, you mean.”

“Right, whatever. So you’re not gonna get much sleep. But hey, you young people don’t sleep much anyway, right?”

“Wait, but aren’t you still getting paid four times as much as we are by the aggregator?”

“Hey, look, sorry, kid, I got to take this other meeting right now…but let’s get drinks this weekend, yeah?”

If the tech industry worked like the music industry

“Hi! You’re a venture capitalist. We’re a tech startup. We have a web app we want to sell to people.”

“Great! So here’s how this works: we’re going to give you a chunk of money. You’re going to use this to build your web app. It’s called an ‘advance’. We’re also going to give you 12% of the revenue from your app…but only after you’ve paid back the advance in full. That’s 12% amongst your entire team, by the way. You sort out who gets how much.”

“Um…what?”

“Yeah. The way you’ll make your money is by going out and showing people your app, so they’ll buy t-shirts with your app’s name on it, because they love it! Which we’ll also take a chunk of — we call it a ‘360 deal’.”

“I don’t–“

“Also, you’re going to sign a contract with us that any other web apps you make will be our property, though we’ll be able to renegotiate your percentage at will, of course. And if we don’t like your next web app, you’re fired on the spot…but we’ll keep collecting the revenue from the web apps you’ve created that we own, and we’ll send you your royalties on it, of course…just make sure we always have a current address for you.”

“Well, I’m not–“

“Also, we don’t like the actual way your web app works, even though we want to sign a contract with you based upon how it works. We want it to be a social network instead of a content management system, because our surveys show that social networks make more money.”

“But that’s not what we do.”

“Who gives a shit what you do? You think you know better than we do, just because your first web app got funded by complete strangers on Kickstarter? We’re the professionals here. Also, when you talk to Wired: you’re 24, not 34, and unmarried.”

“Are you kidding? I have a wife and two kids!”

“Yeah, but we find that Wired readers are more likely to sign up for a web app if they’re sexually attracted to the founders and believe they’re available. It’s all about the fantasy, kid. You do blow?”

“What? Of course not!”

“Oh, you’ll be fine, then.”

“Look, why are we getting 12% of the income, when we’re the ones doing all the work?”

“Well, a third of it goes to Amazon for web hosting and delivery–“

“You’re fucking kidding me!”

“Hey, don’t blame me, blame the market. And we take the other 55% for our initial investment, and for marketing you.”

“But we’re essentially paying for the development costs out of our own paychecks, right? And you’re treating that as an investment, so even if our web app tanks, we still owe you that money, but you can write it off as a tax loss, right?”

“Well, yeah. Look, that’s how this business works. Don’t be naive. You want this deal or not? You wanna stand on the same TED stage as Mark Zuckerberg? Come on, kid, this is the big time. Shit or get off the pot.”

A real-world example of BAP robot architecture

You’ll have to excuse me — I’ve got the flu today, and I might not be entirely coherent. But here’s a concrete example of my BAP robotic framework. This is a simple robot with two motors (one on each side) and a GPS unit.

robot layout

The first thing we notice is that each of the motors is controlled by an H-bridge, which consists of four switches that allow current to flow in either direction through the motor itself — or through a relay switch which turns on the motor, if the motor is high-voltage. (For our purposes, we’ll assume it is, as a 5V robot is small and boring).

The H-bridge controls the relay, which controls current coming from a power supply to the motor. So with our system, we can turn each motor forward or backward. We can’t control speed — the motor is either on or off — but that might be enough for our purposes.

We’re using OSC, so let’s call our robot robot1. The robot has two top-level endpoints, sensors and motors. These are arbitrarily named, and in point of fact we don’t even need them — we can assign top-level endpoints to every component in the robot. But let’s leave it like this, as it’s nice and tidy.

We see that the motors endpoint has two sub-endpoints, leftMotor and rightMotor. Our behavior system sends commands to these motors by issuing methods to the endpoint, like so:

 

  • robot1/motors/leftMotor/goForward
  • robot1/motors/leftMotor/goBackward
  • robot1/motors/leftMotor/stop

 

 

These three commands are all we can really do with these motors…but as we’ll see, they can be used to instantiate a pretty sophisticated set of behaviors.

Our autonomic layer “knows” what these commands mean and how to actually make them happen. For example, pseudocode for our goForward function might look like this:

function goForward(){
    setSwitch(0).HIGH;
    setSwitch(1).HIGH;
    setSwitch(2).LOW;
    setSwitch(3).LOW;
}
The setSwitch commands simply turn the switches on the H-bridge connected to the relay connected to leftMotor to send current in a direction that rotates the motor counterclockwise (which, since it’s on the left side, turns it “forward”). The goBackward function might turn switchs 2 and 3 to high and switches 0 and 1 to low; and the stop command might simply set all of them to low, or disconnect them. (We can get more funky by having the stop command reverse polarity for 10 milliseconds before disconnecting, which would work like an engine brake.)

Now, we’ve also got a sensor: namely the GPS unit on top of the robot. This provides two endpoints in our current scheme, lat and lng, though it could also provide a single endpoint which when queried returns a formatted string from the GPS like “-37.3457532,30.12930495” that our behavioral layer can decipher.

We’d query it by issuing a command like this (again, this is pseudocode):

var robotLat = osc.retrieve(/robot1/sensors/gps/lat); var robotLng = osc.retrieve(/robot1/sensors/gps/lng);

Pretty straightforward, right? This way, our software can figure out where the robot is at any given time.

Now, you’re maybe asking yourself: how does our software connect to the robot? How does the GPS data get translated and piped out to our endpoints? For that matter, how are our motors connected to the power supply? Does our control circuitry hook into the same power supply?

The answer is simple: who gives a shit? Really? The whole point of this is abstraction. The hardware engineer sorts out the physical layer, the firmware geek sorts out the autonomic layer, the programmer works out the behavioral level. None of them give a shit about any of the other layers, except insofar as their bit needs to hook into the other guy’s bit.

The autonomic engineer spends months designing a really efficient cellular modem that receives commands from the Internet and turns them into hardware-specific commands. The design is brilliant. Other engineers buy him endless rounds at conventions for being a badass.

And the programmer neither knows nor cares about any of this, because all that matters is that the system responds to commands. Period.

Look, do you know anything about Javascript? Javascript lets you make web pages interactive. (Yes, it can do much more, blah blah Node.js blah blah blah. <i>Shut up.</i> Pay attention.) One of the things you can interact with using Javascript is the mouse — you can get the mouse’s X and Y position relative to the screen or even the DOM object you’re attaching the code to.

Doing this requires the browser to be able to retrieve relatively low-level data about the mouse’s current status. In return, it does this by accessing the operating system’s mouse driver, which uses a standard set of protocols to interface with the mouse’s hardware, which might be optical or mechanical or a touchpad or motion sensors in the air.

But as far as the Web developer is concerned, who gives a shit how all of that works? So long as window.mouseX and window.mouseY are accurate, the rest of the process of turning physical movements into Cartesian coordinates is pretty much irrelevant.

Same thing here. There might be a more efficient way of controlling the motor than with an H-bridge and a relay switch, but as long as the motor can take in our three commands and turn them into motion, who gives a shit?

We have everything we need now to begin building complex logic into our robot. Let’s use an example of a behavior I mentioned in a previous post: let’s make our robot come and find us.

We have a GPS, so the robot knows where it is; and we have motors. What we don’t have is a digital compass to help our robot orient itself…but we can still pull this off, with some code like so (again, this is pseudocode):

var myLat = 36.1515;
var myLng = -115.2048;

var robotLat = osc.retrieve(robot1/sensors/gps/lat); var robotLng = osc.retrieve(robot1/sensors/gps/lng);

if(robotLat != myLat && robotLng != myLng){

oldLat = robotLat;
oldLng = robotLng;

osc.transmit(/robot1/motors/leftMotor/goForward);
osc.transmit(/robot1/motors/rightMotor/goForward);
wait(10000); // this is milliseconds

robotLat = osc.retrieve(robot1/sensors/gps/lat);
robotLng = osc.retrieve(robot1/sensors/gps/lng);

if(difference(robotLat, myLng) &gt; difference(oldLng)){
    osc.transmit(/robot1/motors/leftMotor/stop);
    osc.transmit(/robot1/motors/rightMotor/stop);
    osc.transmit(/robot1/motors/leftMotor/goBackwards);
    osc.transmit(/robot1/motors/rightMotor/goBackwards);
    }

// and so on

}

What this code does is make the robot “try” different directions by moving in a direction for ten seconds and seeing if that decreases the distance between its location and my location. Once it finds a direction that does so, it goes in that direction until its coordinates match my coordinates.

What if we want to make it more complex, “smarter”? We can add in a digital compass, which returns either a value in degrees (0-360) or as a mapped range (0-1, where 1 can be mapped to 360 degrees). Then our robot knows where it is and where it’s pointed. It doesn’t need to orient itself before it starts to move.

Our behavioral software can connect to Google Maps and get a series of directions, following roads, between the robot and us. We can then direct the robot using these directions, simply by issuing commands to our two motors. It doesn’t matter that our robot doesn’t know anything about Maps, or that Maps doesn’t have robot navigation built in. Our behavioral layer handles that for us.

Is this complex? Sure it is. So it’s a good thing we’re not trying to do this with instructions hardwired into our robot. All the complexity of translating road directions into commands to turn motors for certain time periods, in certain directions, is offloaded to our behavioral layer, which can be on-board the robot or — more likely — connected over a network.

Of course, our robot still has to avoid cars as it trundles along public roads, and maybe it has to worry about recharging itself. But all we have to do is add more sensors — touch sensors, range sensors, a battery level sensor. We can download the low-level stuff directly to the robot so there’s no network latency between a command being issued and being carried out. For example, we can tell the robot “if something triggers your range sensor, move away from it until it’s not there anymore, then recalculate your travel direction”. Or “if your battery gets below 25%, here’s the GPS coordinates of a filling station where a nice person can charge you again. Go there instead of your initial location.” Once the battery level is 100%, we simply resume our initial set of commands to reduce distance between the robot and us.

Simple, right? Well, not simple, not trivial, but not so complex we can’t make it happen.

And here’s the great part: we can have our robot perform this behavior until we get bored, and then we can totally reconfigure it. We can build a ground-based version of John Robb’s DroneNet.

Imagine Buffy was at Angel’s house last night, and left her keys there. So we give our robot two GPS coordinates, and we add a lockbox with a combination to the top of it. We tell it to go from its current location to the first GPS coordinate, which is Angel’s moody pad. Angel puts Buffy’s keys in the lockbox, locks it, and hits a “Deliver” button on his iPhone. Our software receives that button press, and tells the robot to go to the second GPS coordinate — Buffy’s house — using all of these sophisticated behaviors we’ve made as reusable software objects. It makes the delivery, Buffy uses the combination her iPhone told her, unlocks the box, gets her keys, hits “Received” on her iPhone, and the robot returns to its home, waiting for its next customer.

Same robot, massively different functionality. As long as our robot’s motors and sensors and interface — its physical and autonomic layers — are in working order, we can keep coming up with cool ways to use it. We can add sensors to it as necessary. We can also reconfigure its hardware so that it moves in more optimized ways — we can make it a flying drone instead of a rolling drone, for example. But we can still use our GPS “find me” behavior, almost independent of how the robot moves from point A to point B. It will require some reconfiguration, but if we’ve made it modular enough in the first place, that might not be such a big deal to accomplish.

We can even allow third-party developers and behavioral networks to access our robot, maybe using something like oAuth. Instead of writing our own behaviors, we entrust our robot to Google’s behaviors, because their programmers are smarter than us and they also have a vast network of supercomputers to process our robot’s sensorial data and connect it to all the other robots in Google’s network. Our robot isn’t very smart on its own, but when connected to a behavioral network, it’s much smarter…and when its behavior is synced with a lot of other robots, all gathering information and doing things, it’s scary smart.

Refining the ideas.

I’ve been thinking about my little scheme, and I’ve talked to a couple of people who know far more about electronics than I do. I’m a software person, essentially, and so I think in those terms.

Basically, one of the problems people have had with my idea is that every actuator requires different circuitry, because each one has different power requirements, etc. So one motor might need one set of resistors and capacitors to function correctly, but another one has a totally different set.

Which is fine, I totally get that. But that’s all part of the physical level of my architecture. It doesn’t matter how power gets to the motor, so long as it can be regulated by a low-voltage control circuit (i.e. my autonomic level).

According to my lazy Googling and some Twitter conversations, there are only really a very few ways for a low-voltage system to control a high-voltage actuator(s). Relay switches, transistors, MOSFETs, right? As long as my autonomic layer has interfaces for all of the usual methods, it doesn’t matter what’s on the other end of that interface.

For example: imagine I have a 50V electric motor in my system. It’s turned on by a reed switch, which is 5V, attached to my control board by a standard connector. If I swap out the 50V for a 75V, it doesn’t matter to my control circuit at all, because it’s just triggering that reed switch. So long as the reed can handle a 75V load, it’s all fine. It doesn’t matter how the 50V and the 75V each get power from their power supply — whether they’re just connected directly or have more sophisticated management subsystems — so long as they can be controlled by a binary EM switch or a system for varying power input.

Think of it like so:

bap

Each of those physical subsystems (the green and red boxes) can be as complex or as simple as you like, so long as they can be interfaced with my low-voltage autonomic board.

So the real project here — the actual tasks I need to accomplish, as opposed to all my blue-sky philosophical bullshit — is this:

  1. Create a standardized way of interfacing the behavioral and autonomic layers. My guess is that this will mean making a way of sending and receiving OSC messages between the two.
  2. Create a set of methods for abstracting those messages within the autonomic layer and turning them into actual hardware control signals.
  3. Design a standard for normalizing hardware interface and control. I don’t think this has to be physical, necessarily, but more like a generalized way of driving different sorts of actuators and reading digital/analog input.

I think the easiest way to begin this is to write the code for the Arduino, because it’s the cheapest and most widely used hardware prototyping hardware around. So my initial concrete goal:

  1. Write (or find) an OSC receiver for Arduino;
  2. Create a set of initial abstractions for components (brushed motors, stepper motors, servos, and analog and digital sensors) that can be mapped to OSC endpoints and methods;
  3. Create a machine-readable way of describing those components to the hardware, that can be uploaded to firmware depending upon configuration.

Once I can get a proof-of-concept working for Arduino, I’ll open-source it to anybody who wants to port it to any other control system.

So, not a heavy amount of work or anything. 😉

Behavioral, autonomic, mechanical compared to Marr’s tri-level hypothesis

As I mentioned in my last post, my model for cybernetic systems bears a lot of resemblance to David Marr’s tri-level hypothesis, which he defines as computationalalgorithmic and implementational. I’ll quote from the site linked above:

The computational level is a description of what information processing problem is being solved by the system. The algorithmic level is a description of what steps are being carried out to solve the problem. The implementational level is a description of the physical characteristics of the information processing system. There is a one-to-many mapping from the computational level to the algorithmic level,and a one-to-many mapping from the algorithmic level to the implementational level. In other words, there is one computational description of a particular information processing problem, many different algorithms for solving that problem, and many different ways in which a particular algorithm can be physically implemented.

While this is conceptually similar to my idea, Marr is working in purely conceptual space here (though his model can be applied to physical systems as well). My taxonomy is closer to the way an animal works: a cognitive system, a mechanical system, and an autonomic system for carrying messages between the two. Of course, in animals (at least in humans), this is a strictly hierarchal system: the cognitive system can’t directly access the mechanical system, or else you could “think” electrical impulses directly to your muscles, for example! But in a technological system, there’s no reason you couldn’t theoretically directly bypass the autonomic layer entirely, though you wouldn’t want to very often, for the same reason you usually don’t let desktop software directly control the read/write heads on your hard drive.

I see no reason why the majority of low-level sensors and actuators can’t be abstracted and made object-oriented. For example, think of object classes in programming. You might have a class called Vehicle, with a set of methods and properties, and a subclass of Vehicle called Bicycle, with overriding methods and properties. Couldn’t you do the same thing with hardware control, starting with two classes: Sensor and Actuator? Then you could build sub-classes. A range finder, for example:

class rangeFinder extends Sensor{

public var min = 0; // the minimum value the range finder will send
public var max = 10000; // the maximum value, which is actually expressed in milliseconds of latency

public function latencyToCentimeters{

return this.latency * 0.5000 // Or whatever the equation is for converting milliseconds to distance 

    }

}

For example. Then you could declare something like this:
var rangeThingie = new rangeFinder(01);
Which would tell your software that there’s an object of class Sensor, subclass rangeFinder, at input port 01. (You wouldn’t need to specify input vs output, as that’s handled by our Sensor object code.)

So that’s the software abstraction layer…but the hardware still needs to be controlled somehow, right? That’s where your programmable autonomic firmware comes in. When you hook up your range finder, you specify the voltage and amperage that it requires, and upload those values to your firmware. (As I mentioned in the last post, this could even be handled by QR or barcodes on the sensor itself; you scan it with your computer’s webcam, and it connects to an open database, which returns machine-readable information:

[type : "range_sensor",
manufacturer: "Acme, Inc.",
specs: {
    voltage: "5",
    amps: ".5"
    min_operational_temperature: "-50",
    max_operational_temperature: "150"
}]
That would be in JSON format, obviously. So your autonomic firmware programmer receives this data and “knows” how to interface with this sensor at a mechanical level. Same with any other component: you could send the proper PWM to control a stepper motor (if I understand how stepper motors work, which is not at all certain) or know the maximum amperage you could run through a speaker, or what-have-you.

At that point, it’s simply a matter of plugging all your components into your autonomic board, giving it specs for each component (by downloading or manually entering them and then uploading that info to the firmware on it), along with any reusable functions you’ve defined (like “turnLeft” or “rotateElbow” for robots, as an example) and hooking up your cognitive or behavioral subsystem, which issues commands to the autonomic system.

How? Probably using something like the Open Sound Control protocol, which defines a very simple addressing scheme for accessing and sending values to subcomponents. So your software could do something like this:

var rangeVal = osc.retrieve("/robot1/sensors/rangeThingy/");

if(rangeVal > 0.5){ osc.transmit("/robot1/stepperMotors/leftElbow/rotate", "45"); }

Which would be translated by the autonomic layer into actual electrical signals. Of course, you could also chain together these specific commands into higher level functions within your behavioral code, or even in your firmware (provided it had enough memory onboard, which is why you might want to use something like an SD card for storing this stuff).

How would that code get from the behavioral level to the autonomic level? Doesn’t matter. I mean, it matters, but it could be any number of ways:

  1. The behavioral system is handled by a small computer like a Raspberry PI, physically on-board the device;
  2. The behavioral system is an actual programmed processor, also on the device;
  3. The behavioral system is on a very powerful computer, connected to the device by WiFi or cellular radio, or USB if distance isn’t an issue.

As long as your behavioral level is connected to your autonomic level somehow, the specifics don’t matter.

So what happens when that connection is severed? If you’re smart, you’ve built fall-back low-level behavior and uploaded it to your autonomic system’s storage. Building a drone plane? If it loses its connectivity to the complex control system on the other end of its radio connection, have it continue towards LKG (last known good) destination coordinates, relying on its on-board GPS. Or if that’s too risky (say, if you’re worried about it running into mountains), have it fly in a circle until it reestablishes connection, or have it try to land without damaging itself. Whatever. It’s up to you to figure out the specific fall-back behavior.

Roboticists are thinking “Yes, but my machine is much more efficient than this. I don’t care about standardization!” Yes, your machine might be better and more efficient. But it’s also a standalone device. Think of old synthesizers, in the pre-MIDI days; they’re hardwired, stuck doing the one thing you made them do. They can’t be easily upgraded by the end consumer, they can’t be modularized. Your Yamaha DX-7, which was super-badass when you bought it in 1985, is now a curiosity. It’s not as good as other, newer digital synths. Nobody wants it…especially when they can replicate its sounds exactly with software now!

Same thing if you’re building a welding robot (to use an example from a buddy of mine). Your welding robot has all the articulation and parts to weld, but it’s not very smart. But if it’s interoperable, connective, you don’t have to worry about building the logic on-board! Your robot is an avatar for an intelligence that exists separately of the hardware. As people figure out how to make better welding robot routines and procedures, your robot can be updated! It can be made smart! And eventually, when people have figured out better hardware, it can be repurposed to do something else…in the same way that I can use a goofy early 90s hardware synthesizer as an excellent MIDI controller for my newer, better synth software.

I realize that a lot of people who work in this side of technology don’t think that way, but that’s their problem, not mine. I want to figure out a way to make a standard, universal way of connecting hardware to software, one that focuses on simplicity and reproducibility and communication ability over efficiency. I’m repulsed by proprietary systems, and if your business model is based on building things that can’t be upgraded but only replaced — not because they have to be, but because that’s where you’ve decided your revenue stream comes from — then man, fuck you and your awful business model. Sooner or later, people are going to get sick of your shit and find another vendor…especially when there are cheaper and more flexible alternatives.

(Okay, Ellis, breathe. No need to get shouty. Low blood sugar. Go eat something.)

Behavioral, autonomic, mechanical: a model for building badass robots

[Update: since I started writing this, a Twitter friend helpfully pointed me at Marr’s levels of analysis, which upon quick study appears to be pretty much identical to this idea, so I’ll be framing this in his terminology at some point.]

This rides on the tail of the previous post. I’m just trying to get this sorted, so bear with me.

A cybernetic system consists of inputs, outputs, and logic to connect them via feedback — if this, then that. This is true for Web servers and 747 autopilots alike.

It occurs to me that you can broadly organize a cybernetic system into three levels of interaction: behavioral, autonomic and mechanical. So let’s look at these in reverse order, from the bottom up.

  1. Mechanical: this is the lowest level, below which it’s impossible to alter component behavior without external intervention. Think of, for example, a motor. A motor turns, in one direction or another. You can’t make it do anything else without actually going in and fucking with its physical properties. Same with a photovoltaic sensor, or a human muscle, which can only contract when sent an electric/chemical signal.
  2. Autonomic: This is the next level up, in which you can connect up inputs and outputs to perform basic logic without need for complex modeling. Imagine a robot with a touch sensor and a motor. You can program the robot to reverse the direction of the motor when the touch sensor is triggered. Or in a biological model, think of your heartbeat. It requires no thought, no interaction: it just beats. You can also think of the BIOS of a computer: it handles the simple, low-level switching of signals between a CPU, RAM, a hard drive, etc.
  3. Behavioral: This is when you hook a bunch of inputs and outputs together and create complex behavior based on their interaction. In computers, this would be the software level of things.

To give a concrete example of this, think of a Belkin WeMo switch. This is a networked-enabled power switch. It has a simple WiFi receiver in it and a relay that can turn power on and off to an electrical socket.

The mechanical level of the WeMo is the power socket switch itself. It does one thing: flip a relay. It doesn’t “know” anything else at all, doesn’t do anything else.

But the WiFi adds the autonomic level: there’s basic logic in the WeMo that when it receives a specific signal over WiFi, it flips that relay. That’s all it does (aside from the ability to connect to a WiFi network in the first place). Slightly more complex than the switch itself, but still not complex at all.

But then there’s the behavioral level of the system. Belkin makes a mobile app for your phone that lets you turn on the switch from wherever you are. In this case, the behavioral level is provided by your own brain: you can turn the light on or off based on a complex system of feedback inside your skull, which takes a various set of inputs, conditions and variables to decide “Do I want this light on or off?” It might be overcast outside, or it might be nighttime, and you might want to turn it on; it might be daylight, and you want to turn it off, or it might be dark but you’re not home and don’t want to waste electricity. Whatever.

But here’s where it gets interesting: you can use IFTTT to create a “channel” for your WeMo, which can be connected up to any other IFTTT channel, allowing for complex interaction without human intervention. For example, I have the WeMo in my living room set to turn on and off based upon Yahoo Weather’s API; it turns off when the API says the sun has risen, and turns on when it says the sun has set.

This is different than a light controlled by a photovoltaic switch, which is an example of autonomic behavior. The PV switch doesn’t “know” if the sun has gone down, or if someone is standing in front of it, casting a shadow; all it knows is that its sensor has been blocked, which turns off the light. While this is somewhat useful, it’s not nearly as useful as a system with a behavioral level.

Make sense?

Okay, so let’s get back to robots, which was what I was going on about in the last post. A robot is a cybernetic system, and so it has these three potential levels: behavioral, autonomic and mechanical. In the case of a robot, it looks like this:

1) Mechanical: motors, sensors. A Roomba, to use the example from the last post, has three motors (left wheel, right wheel, vacuum) and a set of touch sensors. All these can do is either receive or send electrical current: when a touch sensor is touched, it sends an electrical signal (or stops sending it, whatever, doesn’t matter). A motor receives current in one direction, it turns one way; send it the other direction, it turns the other way.

2) Autonomic: In our Roomba, this is the hardware logic (probably in a microprocessor) that figures out what to do with the change in current from the touch sensor, and how much current to send to each motor. For example, if the motor is a 100 amp motor and you send 1000 amps through it, you can literally melt it, so make sure it only gets 100 amps no matter what. Very straightforward.

3) Behavioral: in our Roomba, this is deceptively simple: roll around a room randomly until you’ve covered all of it, and then stop. In actuality, this requires a pretty serious amount of computation, based upon interaction with the autonomous level: a sensor has been tripped, a motor has been turned on. I don’t know the precise behavioral modeling in a Roomba, but I suspect it’s conceptually similar to something like Craig Reynold’s boids algorithm: move around until you hit a barrier, figure out where that barrier is (based upon something like number of revolutions of the motor), move away from it until you hit another one, etc.

In a Roomba — and indeed, in most robots — the autonomic and behavioral levels are hard-coded and stored within the robot itself. A Roomba can’t follow any instructions, save the ones that are hardcoded into the firmware in its processor.

Fine. But what if we thought about this in another way?

Let’s remove the Roomba’s behavioral subsystem entirely. Let’s replace it with a black box that takes wireless signals from a WiFi or cellular network; doesn’t matter which. This black box receives these signals and converts them to signals the autonomic subsystem can understand: turn this motor this fast for this long, turn that motor off. And let’s even add some simple autonomic functions: if no signals have been received for X milliseconds, switch to standby mode.

Our Roomba is suddenly much more interesting. Let’s imagine a Roomba “channel” on IFTTT. If I send a Tweet to an account I’ve set up for my Roomba, I can turn it on and off remotely. Cool, but not that cool, right?

But what if we add the following behavior: let’s make our Roomba play Marco Polo. Let’s give it a basic GPS unit, so it can tell us where it is. Then let’s give it the following instructions:

1) Here’s a set of GPS coordinates, defined by two values. Compare them to your own GPS coordinates.

2) Roll around for a minute in different directions, until you can figure out which direction decreases the difference between these two coordinate points.

3) Roll in that direction.

4) When you encounter an obstacle, try rolling away from it, generally in the direction you know will decrease the difference between your coordinate and your target coordinate. If you have to roll in another direction, fine, but keep bumping into things until you’ve found a route that decreases the difference rather than increasing it.

This is a very simple and relatively easy set of instructions to implement. And when we do so, we’ve got a Roomba that will come and find us, bouncing around by trial and error until it does so. It might take thirty seconds, it might take hours, but the Roomba will eventually find us.

Now, if we equip the Roomba with more complex sensors like a range finder or a Leap Motion, this all becomes much more efficient: the Roomba can “scan” the room and determine the quickest, least obstacle-filled path. In fact, the Roomba itself, the hardware, doesn’t have to do this at all: it can send the data from its sensors over its wireless connection to a much more complicated computer which can calculate all of this stuff for it, much faster, and issue commands to it.

But what happens if that network connection breaks down? In this case, we can give the Roomba a very simple autonomic routine to follow: if there’s no instructions coming, either stop and wait until a connection is reestablished, or resort to the initial behavior: bump around trying to reduce the difference between your own GPS coordinate and the one you’ve got stored in your memory. Once a connection is reestablished, start listening to it instead.

If this sounds dumb, well, imagine this: you’re in an unfamiliar city. You’re relying on your car’s GPS to navigate from your hotel to your meeting. When you’re halfway there, your GPS stops working (for whatever reason). You know your meeting is at 270 34th Street, and you know that you’re at 1800 57th Street. (The numbered streets in this imaginary city run east-west.) So you know you need to go east for fifteen blocks or so, and north for twenty-three blocks. So you turn left and go north on Oak Street, but Oak Street deadends at 45th Street. So you turn right onto 45th until you find Elm Street, the next north-south street, and you turn left and continue to 34th Street, where you turn right and keep going until you reach the 200 block.

Do you see where I’m going with this? You’re doing exactly what our imaginary Roomba is doing: you’re “bumping” into obstacles while reducing the difference between your Cartesian coordinate and the coordinate of your destination. The difference is that you’re not literally bumping into things (at least hopefully), but if our Roomba has sophisticated enough range finders and such, neither is it.

But this is even more interesting, because we can break your behavior down into the same three levels.

  1. Behavioral: I want to go to 270 W. 34st Street. My brain is converting this idea into a set of complex behaviors that mainly involve turning a wheel with my arms and pushing pedals with my feet. And hopefully also paying attention to the environment around me.
  2. Autonomic: I think “I need to turn left”, and my brain automatically converts this to a series of actions: rotate my arms at such an angle, move my knee up and down at a certain speed and pressure. As Julian Jaynes points out in The Origin Of Consciousness In The Breakdown Of The Bicameral Mind, these are not conscious actions. If you actually sat down and thought about every physical action you needed to do to drive a car, you couldn’t get more than a block.
  3. Mechanical: Your limbic system sends electricity to your muscles, which do things.

Your muscles don’t need to “know” where you’re going, why you’re going there, or even how to drive a car. Your higher mental functions (I need to turn left, ooh, there’s a Starbucks, I could use some coffee, shit, I’m already late though) don’t deal with applying signals to your muscles. The autonomic systems are the go-between.

But then, something happens: a dumbass in an SUV whips out in front of you. At that point, your behavioral system suspends and your autonomic system kicks in: hit the brakes! You don’t have to consciously think about it, and if you did, you’d be dead. It just sort of happens. (There are actually lots of these direct-action triggers wired into human mental systems. Flinching is another example. It is almost impossible not to flinch if something comes into your vision from the periphery unexpectedly, moving very fast.)

So let’s turn this into a brilliant architecture for robotics. (He said, modestly and not confusingly at all.)

Our architecture consists of our three levels: behavioral, autonomic and mechanical. However, because we’re building modular robots and not monolithic people, what each of these actually means can be swapped out and changed. Again, let’s look at this from the bottom up.

1) Mechanical. This can be pretty much any set of sensors and actuators: a potentiometer, a button, a touch sensor, a photovoltaic sensor. Doesn’t matter. To an electron, a motor and a speaker look exactly the same. You can actually simply imagine this as a whole bunch of Molex connectors on a circuitboard with a basic BIOS built-in. What we hook into them is kind of irrelevant, as our autonomic system will handle this.

2) Autonomic. this is a combination of hardware and updatable firmware. Think of a reprogrammable microprocessor, perhaps with a small bit of RAM or SSD storage attached to it. The hardware simply interprets signals from the behavioral level and sends them to our mechanical level; the firmware handles the specific details. So let’s imagine we’ve plugged two motors into our circuitboard and a heat sensor. We then tell the firmware how much voltage to send to the motors, and what range of voltage we expect from the heat sensor. It then normalizes these values by mapping them to a floating point number between 0 and 1. (This is just an example of how you could do this.)

So let’s say our heat sensor sends temperature in degrees Celsius, with a maximum of 200 and a minimum of -50. Our autonomic system converts that to a 0-1 range, where 0 is -50 and 200 is 1. Therefore, if the temperature is 125 degrees Celsius, it sends a value of 0.5. Make sense?

Same with the motors. If the motor’s maximum RPM is 2500 (and minimum is obviously zero), if we send a message like “rotateMotor(0.5)” to our autonomic level, it “knows” to send the amount of current that will turn the motor at 1250 RPM. (This can get a bit more complicated, but for our purposes, this is a basic example.)

The point is, the actual physical operating ranges of our components don’t matter at all; that’s easily mappable to standardized value ranges by our autonomic system.

We can program the firmware based upon the mechanical stuff we have connected, so we can swap our components out at any time. We can also create simple programmable autonomic “behaviors”, which are preprogrammed instruction sets. One might be: if the heat sensor (which we’ve mounted at the front of our robot) gets above 0.5, turn both motors counterclockwise at amount 1 until the sensor’s value goes down to .25. This means that when our robot senses temperatures at 125º C or higher, it will run away until the temperature goes down to 62.5º C. This allows us to not worry about basic things like self-preservation. We can even make this behavior slightly more complex: for example, we can use motors that can send back the amount of torque to the autonomic level. If the torque is too high, the motor stops doing what it’s doing.

We can also create simple shortcuts, like “turn left” or “go forward by 500 feet”. These shortcuts can be translated by the autonomic level into hardware specific commands. For example, if we know our motor turns at 2500 RPM and we know that 5 revolutions will move it one foot, when our autonomic system receives the command “go forward by 500 feet”, it translates that into the command “turn on for 60000 milliseconds, or one minute”, which is sent to the motor.

In other words, the autonomic level acts like our limbic system, freeing our robot’s “higher brain” from having to worry about any of the tedious hardware interfacing shit.

And again, this doesn’t have to be oriented towards robotics. We can make an autonomic level that sends electricity through a speaker at a certain frequency when a certain button is pushed, which becomes a very simple musical synthesizer. It’s all just input and output. Just current.

If we’ve done our job correctly, we can now move on to the behavioral level of our device.

3) Behavioral. The behavioral level, in hardware terms, is a black box: it can either be an onboard CPU (like a Raspberry PI, for example) or a network connection, like in our imaginary Roomba. Doesn’t matter, as far as the rest of the system is concerned, as long as it sends commands that our autonomic system can understand. These can either be higher-level (“turn left”) or lower-level (“turn on motor #3 for eight milliseconds, pause for fifteen milliseconds, then turn on motor #5 for one hundred milliseconds, or until sensor #5 trips, in which case start the whole thing over again”). The logic for our behavioral system can be anything we like, provided we have a complex enough processor onboard or in the cloud. In fact, it doesn’t have to be either/or: we can build a behavioral center with half of its behaviors onboard and half in the cloud, or any variation thereof — like our Roomba, which stumbles around blindly until it’s given commands by the cloud. It depends upon the requirements of the tasks our device is made to carry out.

With a structure like this, we can easily build a simple “brain” for a robot that can essentially be connected to damn near any set of sensors and actuators and perform an infinite number of tasks, so long as the right sensors and actuators are connected to it. Such a robot could be anything from a simple Romotive-style consumer toy to a drone tank in a war zone to a telemedical surgical robot, performing neurosurgery while controlled by a doctor miles away. It doesn’t even have to be a robot, actually: it can be a synthesizer or a video game controller or an interface for driving the drone tank or performing the neurosurgery. I cannot stress this enough: it’s all just electricity, going to and from mechanical bits.

And herein lies the difficult part, which is not technical but organizational: this relies upon software and hardware standards, two things which the engineering industry seems simply incapable of deciding upon until forced at gunpoint. There is no standard way of connecting motors to sensors, no universal format for describing an actuator’s mechanical behavior (voltage, amperage, torque, maximum speed, operational temperature range, etc.). Nor is there any standard API or language protocol that can be implemented between the behavioral and autonomic layers. There are existing analogies in hardware/software interfacing: the first two that pop into mind are the USB Human Interface Device standard and MIDI, the Musical Instrument Digital Interface protocol which allows interoperability between synthesizers. (In point of fact, a number of non-musical devices like 3D motion capture systems incorporate MIDI as their input/output system, which is a square peg banged into a round hole, but which suggests that such a standard is probably about thirty years overdue.)

Think of your computer’s mouse, or your trackpad perhaps if you’re using a laptop. There are a few different methods of building a mouse: mechanical, optical, or in the case of touchpads, capacitive. A mouse can move around, or it can be stationary (as with a trackball). And when I was a kid, a mouse required a software driver that came on a floppy disk when you bought it.

But at some point, somebody realized that the actual mechanics of any given mouse were just completely goddamn irrelevant from a software perspective, because every mouse — no matter how it works — just sends back two bits of information: X and Y position. So the people who make mice figured out a standard, in which a mouse sends that positional coordinate over USB in a standard way, which is called “class compliance”. How it converted motion into that coordinate — whether it used two rollers or a laser — was handled at the autonomic level, by the tiny chip inside the mouse.

So now, when you buy a mouse, you plug it in and it works. Any mouse manufacturer who attempted to build a mouse that wasn’t USB class compliant would very quickly go out of business. It would be pointless. There are lots of wonderful improvements in mouse design, I guess, and probably entire conventions full of engineering nerds who get together and get drunk in hotels and talk animatedly about lasers versus capacitance. But nobody else gives a shit. We’ve sorted the irritating part out.

And yet, the people who make robots are still reinventing the wheel, every single time, despite the fact that no robot is anything more than a collection of sensors and actuators, held together in ways that are really fascinating if you’re a structural engineer and completely irrelevant if you’re just trying to write software that controls robots. It’s all just motors, even if there are lots and lots of them and they’re connected in extremely intricate ways. You’re just sending and receiving current.

Imagine a standardization scheme where you, the aspiring roboticist, could purchase a set of motors and sensors and bring them home. Each one might have a QR code printed on it or an RFID attached to it; you could scan the code, and your computer would retrieve all of the pertinent information about the mechanism. You could then plug it into your autonomic interface, tell your computer which mechanism was at which port, and your computer would then prepare the firmware and dump it into the system. You could then attach a CPU or network interface to the autonomic board, and within minutes your robot would be active and alive, behaving in any fashion you liked.

Commercially-sold robots — with perhaps complex and delicate assemblies that would be difficult for you to make at home — would have pre-existing complex autonomic systems, with software that allowed you to “train” them, or purchase downloadable “personalities”, which would simply be pre-existing behavioral methods. Tinkerers could modify and customize the behavior of their robots using standard APIs, which could even have safety limits set in place so that you couldn’t accidentally short your robot or blow out its motor, unless you were sophisticated enough to bypass the API (and the autonomic system) and control the mechanical bits directly.

If robot manufacturers adopted this model, we would begin to see a true Golden Age of robotics, I think. We would begin to see emergent complexity at a far faster speed than is currently displayed, because anybody could build and train robots, and link them together, and let them not only act but interact, learn from each other, and contribute to and benefit from collective knowledge and action.

Now, if only we could convince engineers to get their shit together.

The world is a robot.

This afternoon, I attended an excellent talk by Ken Goldberg about “cloud robotics” — the idea of building robots that are essentially taught and controlled by the Internet “cloud”. As Ken was talking, I had a moment of pure epiphany about cloud robotics and the “Internet of things“. I realized that the underlying assumptions about how this should all work are completely wrong.

First, a bit of a summary: in the traditional model, a robot is an autonomous (or semi-autonomous) object. Its behavior is pre-programmed into it, and it’s set loose to do whatever it does: build automobile chassis, or roll around your house vacuuming until it’s gotten every bit of the floor. These sorts of robots are extremely limited, because they can only deal with whatever it is they’re programmed to do in the first place. Your Roomba is very good at vacuuming your rug, but if it encounters a Coke can on the rug, it doesn’t know what to do with it — it either ignores it or it runs away in a robot’s version of existential dread.

“Cloud” robotics refers to the idea of robotic systems in which the behavior modeling is offloaded onto the Internet. A perfect example is Google’s self-driving car, which is absolutely incapable of driving itself around the most sedate of suburban neighborhoods without a constant connection to Google’s servers, which are processing the data from the car’s sensors and comparing it to maps and predicated behavior and reporting back to the car, adjusting its actions accordingly. In this sense, the self-driving car isn’t self-driving at all. There is no direct human intervention, but in a very real sense, it’s Google’s servers that are behind the wheel.

There’s a lot of work being done in this area, to make robots smarter and in less need of human intervention. Ken talked about the idea, for example, of a robot that uploads pictures of an unfamiliar item to the cloud, which interprets the picture, deciphers what the object is, and returns instructions to the robot on how to deal with it. If algorithms break down, we can even foresee a future in which robots “call in” to humans, who “tell” the robot how best to proceed.

This is all well and good and presents a rosy future, but the fact is that at the moment this is all a fantasy. Right now, there’s no standard way for robots to communicate with the cloud, and even if there were, there’s no standard way for that communication to be translated into action. Every robot works differently, every robot design is unique; one would have to write an entire software stack to deal with each and every model of robot.

In fact, robots in 2013 are very much like musical synthesizers were, up until the late 1980s. This is a digression, but bear with me.

If I showed up on the doorstep of a forward-thinking musician in 1979 or so and asked them to define a synthesizer, they’d tell me that it was an electronic device that made sounds. Synths were boxes, with a “brain” which took signals from an input controller — usually, but not always, a piano-style keyboard — and turned them into audio signals that were sent to an output (usually a speaker or a mixing board for recording). Though the principles of synthesis were pretty much the same, every synth went about it in a different way: the “brain” of a Moog was totally different from that of a Buchla, for example, and in many cases they even handled the input from their keyboards totally differently. Everyone was, not so much reinventing the wheel, but inventing their own wheel.

It occurred to somebody in the late 1970s that it would be really useful if you could control multiple synths from the same keyboard, or even figure out a way to record a series of notes that could be “played back” on a synth live, to allow much more complicated music than could be performed by a single person with one or even two keyboards. But at the time, there was no real way to accomplish this, due to the sui generis nature of every synth.

A lot of goofy hacks and kludges were invented to solve this problem — including devices that sat atop the keyboards of different synths and physically pressed the notes, using solenoids — until a group of nerds invented something called MIDI, or Musical Instrument Digital Interface, in the early 1980s — a protocol for allowing synthesizers to communicate amongst one another that is still the de facto standard today.

The entire MIDI protocol is too complex to get into here, but the gist of it is that a MIDI-enabled device can send or receive basically three instructions: turn X note on on channel Y at Z volume; turn X note off on channel Y; and send X value on channel Y to controller Z. That, a bunch of wanky technical details aside, is basically it! And while MIDI has its very serious limitations, it’s the basis of at least 50% of the musical sounds you hear every single day — from the ravey keyboard lead in Lady Gaga’s “Bad Romance” to the Hammond organ sound on your favorite indie track to the deep beats on Kanye’s new jam.

Aside from the ability for one synth to talk to another, MIDI allowed something else entirely: the ability to separate the input device from the output device. To our musician in 1979, a “synth” was a monolithic physical object; but in the 1980s, you began to see synth “brains” without keyboards and keyboards without brains that could be connected using standard MIDI protocols (and cables). And as desktop computers became more powerful, a “synthesizer” could just as easily refer to a piece of software, controlled by an inexpensive MIDI keyboard controller that sends MIDI signals over USB, as a big box sitting on your desk. In fact, you don’t even need a human performer at all; one of my hobbies is writing little apps that algorithmically generate MIDI commands and send them to my software synths. (I’ve actually released two of the resulting tracks commercially, and they’ve sold surprisingly well.)

Ask a musician in 2013 what a “synth” is, and they’re not likely to describe a big physical box to you; they’re more likely to tell you it’s an app that runs on their laptop or their iPad.

The monolithic, in other words, has become modular.

By contrast, ask an engineer in 2013 what a “robot” is, and they’ll tell you it’s a machine that can be programmed to carry out physical tasks. A robot looks like Wall-E or Asimo: it’s a thing, a discrete physical object.

But this is both a simplification and an overcomplication. A robot can just as easily be defined as a collection of input and output devices, or, if you prefer, “sensors” and “actuators”, connected by a cybernetic controller. The sensors take in data from the world; the cybernetic controller interprets the data, and makes the output devices do things, upon which the whole cycle begins again, in a feedback loop.

For example: a Roomba is, when you get right down to it, a collection of touch sensors hooked up to three motors (one to turn each of the two wheels, and one to turn the fan that actually vacuums stuff up) via a “brain”. When a given touch sensor sends a strong enough signal (via running into a wall or a cat or an ottoman), the brain makes the wheels change direction or speed; for the most part, the vacuum fan isn’t involved in this process at all, but keeps happily chugging away until the Roomba is turned off.

The value of these sensors and actuators broadly follows Metcalfe’s Law: each by itself is essentially useless, but when connected together — along with something to sort out the data from the sensors and decide what commands to send to the actuators — they become far more valuable than the sum of their parts. They become a “robot”.

But here’s the thing: they’re still just parts. We call them a “robot” when they’re put into a chassis together, but that’s just limited imagination on our part.

Let’s try something else instead. Let’s take all those components out of that little round chassis and reconfigure them entirely. Let’s mount the touch sensors into a console and call them by a slightly different name: “buttons”. (Because that is, in fact, what they are.) Let’s put those motors into the wings of a very light aircraft, to control the flaps and ailerons that adjust the aircraft’s movement in the air. And instead of a hardware chip, let’s give them something more akin to a nervous system, that sends and receives signals — using radio, for example.

When you push the buttons, those signals are sent via radio to the motors, which — when combined together — move the airplane up and down and left to right. What you have now is a radio-controlled plane!

But let’s get more interesting. Let’s add a brain back in, but instead of that stupid simple chip, let’s do what the synth people did, and move it into software. After all, our laptop is a thousand times more powerful than the little microprocessor that used to be our Roomba’s tiny brain, right? And let’s swap out our touch sensors, our buttons, for another sensor: a GPS unit.

Now, we can use the infinite power of our laptop to take the simple signals from the GPS and translate them into simple instructions to our motors, which really can only go on and off. If the X coordinate of the GPS is too low, turn on the tail motor for two seconds (or if it’s a servomotor, by Z degrees). Once the X coordinate is right, turn it the other way.

Let’s make it more interesting. Let’s use Google Maps to get the precise GPS coordinates of an arbitrary address, and send that as a reference point for our two motors. (We’ve taken the fan motor and used it to turn the propeller on our plane, but it’s still stupid and only needs to turn on when we begin and turn off when we’re done.)

Now we can simply type a street address into our interface, sit back, and wait for our Roomba to get there. Only it’s not a Roomba anymore, is it? Is it even a robot at all? It’s the same collection of sensors and actuators (well, almost). It’s doing the same thing — taking input, processing it, and using that processed data to control output.

A “robot” is merely our convenient placeholder for an arbitrary collection of sensors and actuators. There’s a certain amount of anthropomorphism in that: a “robot” is a thing, like a “person”. But the difference is that each of the active parts of a robot — the sensors and actuators — can, in fact, be addressed and controlled individually. If that input and output is coordinated by a subtle and complex system — a “brain” — each simple input and output can become a remarkably advanced robot indeed…the same way a synthesizer becomes much more powerful and versatile and capable of producing amazing things when you stop thinking of it as a piano keyboard with a box attached to it.

But that convenient placeholder — “robot” — has become a trap. Robots in 2013 are like synths in 1975 — each one is sui generis, each manufacturer reinvents the wheel. Every model of robot has a different onboard operating system, a different way of connecting input to output, a different protocol. And yet, how many actual types of actuators even exist? Rotary motors, linear motors, solenoids, pistons…almost every actuator in every robot on Earth is based on a set of mechanical devices which were pretty well understood by the end of the Second World War. And all of them operate by the same rough principle: send X amount of current for Y amount of time. (Or send X amount of current at Y frequency for Z amount of time, if you’re talking about pulse width modulation-based components.)

Inputs? Slightly more complicated, but as we’ve seen with computer peripherals, it’s perfectly possible to standardize even the most complex of inputs, provided we’re willing to offload the processing to software. That’s why there are USB standard protocols for everything from computer mice to webcams to yes, even MIDI devices. Webcams may have different resolutions and color depths, but they’re still just sending an array of pixel data to software.

What if we stopped thinking of and designing robots as monolithic objects, but started thinking of them as useful collections of components? And designed simple protocols for sending and retrieving their sensor and actuator data to their brain or nervous system — protocols that could be standardized and given APIs and made replicable, as well as transmitting unique information about the robot when it connects? (USB-MIDI synths and controllers do this; when you connect one, it sends its model name and manufacturer to the MIDI-handling subsystem of the operating system. If you have a Mac, go to Applications->Utilities->Audio MIDI Setup and plug a cheap USB-MIDI controller in; you’ll see what I mean.)

Imagine a Bluetooth robot that, when paired with a computing device, sends an addressed list of its sensors and actuators to the client software, maybe like this:

  • 0 :: rotary motor :: "leftTread"
    1 :: rotary motor :: "rightTread"
    2 :: servomotor :: "robotArmElbow"

I’m just making that up off the top of my head, but you see what I mean. Or you could provide the developer with a list of endpoints; this is similar to the way that MIDI hardware synths come with manuals that show which controllers handle what, like “CC42: Filter Frequency”. (This lets you, the musician, know that if you assign the knob on your MIDI controller to CC42, when you turn it, it will adjust the filter frequency of your hardware synth.)

This would allow the creation of simple network protocols for interacting with sensors and actuators, in which the business logic is offloaded to the cloud or a controller device. For example, imagine this bit of pseudocode:

while(robot1/pressureSensor < 20){
        robot1/leftTread.rotate(20);
}
It doesn’t matter what the actual value range sent by robot1/pressureSensor is, in this simple example, so long as the cloud “knows” the proper range; it could be 0 to 1 or 0 to 255 or 0 to the distance from the Earth to the moon in micrometers. The same with the tread motor, or the servo, or the solenoid. It doesn’t matter any more than it matters to the HTML renderer in your browser whether you type a two word declaration or a 500 word soliloquy into your Facebook status box; the client-side takes care of all the tricky bits of displaying your text and converting it into POST data and sending the data to be processed on the server-side.

If every actuator/sensor became separately addressable, with all of the coordination between them being handled by higher-level computing devices, the whole notion of the “robot” ceases to exist. It’s just components, some of which are physically joined, some of which are not, connected by routers. A camera on a pole could provide data that tells forklift robots how to coordinate their movement; a light sensor could tell all of the automated blinds on the east side of your house to roll themselves down when the sun rises…while also telling your coffeemaker to power on and start brewing your coffee; if the Weather Channel’s API says it’s going to be cold, your car automatically turns on the window defroster before you get in and turn on the engine.

The whole world, in effect, becomes one giant robot, a billion different actuators driven by a billion different sensors, all linked up and connected by the cloud. Nor do the “actuators” or the sensors need necessarily be physical; again, we’re moving away from the idea of the robot as a device that does physical work. A robot that bangs a drum whenever you send a Tweet to a specific account is still a robot, right?

In fact, a roboticist of 2033 might think of a “robot” as a “set of behaviors that drive physical devices”, rather than as the physical devices themselves. One can even imagine different robotic “social networks”, where you can hook your devices up to a specific cloud that suits your tastes and needs. The military would have their cloud, businesses would have intranet clouds to control their industrial robots; you might connect your “hardware cloud” of sensors and actuators up to a “software cloud” that learns behaviors from your friends and family.

It’s difficult to fully imagine this scenario, of course. And what I’m describing here isn’t easy. It requires a complete rethinking of how we design and envision robots — from monolithic to modular. But this transition is something that every aspect of technology seems to go through at some point, from industrialization to communications to computation, and even, as we’ve seen, music technology. I believe it’s a necessary paradigm shift.

What we’re doing is nothing less than making the world around us come to life, to act and react according to the information we create and share. In order to truly make that happen, we need to teach our devices to share as well.