Back to Resources

Conjuring the Microship Design


© 2004 by Steven K. Roberts
Nomadic Research Labs


How do you go about inventing a geek escape pod? This article takes us from hand-waving to the specific design goals that underlie the Microship project.
 early Microship imaginings


Any technology distinguishable from magic is insufficiently advanced.
            -- Benford’s Corollary to Clarke’s Third Law


NOTE:  This article covers a lot of territory, as it must in order to combine everything from philosophy to power management into something tangible enough to take to the shop.  There are numerous references to other material herein; all open in new windows so you can take a side trip without losing the thread.


We now have the amusing task before us of inventing the ultimate toy, secure in the knowledge that a full panoply of resources will be somehow brought to bear on making this dream come true if only we want it badly enough (obsession is powerful stuff).  Of all the phases of a project, this is the most liberating: we don’t yet have to be concerned with complexity, reality, cost, or any of those other irritations that have been known to take the sparkle out of engineering.

All we have to do is fantasize about what it is we most want, then gradually convert that into something that can be loosely defined as a specification.  The transition between the two is not quite as onerous as it might seem:  all it takes is a few broad scenarios to sharpen the focus, a bit of use-case and constraint analysis to fold in a soupcon of reality, sober introspection to weed out irrelevancies, and careful refinement based on the real operational requirements so we can start mapping the whole vaporous construct onto the first of many TO-DO lists. 

Welcome to the wall-staring phase of our total-immersion case study in gonzo engineering.  By the time we’re through with this we will have gained five pounds from physical inactivity, and the project will be impacting every aspect of our lives from the romantic to the pecuniary.

Daydream Believer

Between 1983 and 1991, I pedaled 17,000 miles around the US on three successive versions of a bicycle that satisfied my technophilic yet restless nature, fulfilled ever more outlandish design specifications, and opened doors by sparking intrigue wherever I went.  And while I no longer feel the need to huff my aging body and delicate gizmology (or is it the other way around?) along glass-strewn highways, poised at any moment to make a sacrificial dive into the ditch if that sphincter looming in the rear-view mirror doesn’t get the hell over within the next 5 seconds, there was much about that 8-year epoch that has stayed with me and defined my panoply of lusts—more so than, say, my preceding internment in Midwestern suburbia (although <cough> I must admit that I recently installed a dishwasher, and love it).

Microship fantasy scenarios range from the technical to the intimate, but it’s important to expose them to scrutiny for the rest of the design process to make any sense. Let’s indulge in eight daydreams…

1.  The Escape Pod

This is an obvious extrapolation from the bike, but with vastly more geek appeal and an extra degree of freedom (roads are one-dimensional; water surfaces two).  I just wanna go play, but since I’m not independently wealthy, doing so involves a complex blend of amusement, cash-flow generation, built-in learning curves, and enough geek chic to ensure the involvement of the kinds of people I find interesting.  Those sound like vague requirements, but  they actually shape the result quite a bit.

Fundamentally, this has to be a small boat, well below yacht-scale but bigger than a kayak.  I envision a sort of personal magic carpet, light on her feet, well connected to the Internet, alive with sensors and displays… a sweet little craft that can handle thin water and sneak into tiny places, yet be welcome in a marina, cozily snuggled up to the big boys and evoking kidlike grins on the faces of rich yachties.  She’ll be quiet—with pedal and solar power instead of a noisy gas engine, and of course able to sail.  And she must be lovely, with graceful lines that appeal to nautical sensibilities, tight electronic integration that maketh fellow techies to drool, and an overall sense of balance and grace that sets the eyes of lovely women a-sparkle and enchants the media.  In short, this little boatlet will be a sexy thang, fast on the water, practical enough to handle touring abuse, yet densely packed with serious technology.

And what a toy she’ll be!  I’ll be free to go anywhere within reason (not ocean crossings or rapids, of course, but that still leaves more coastal and inland waterways than I could cover in a lifetime).  I want to travel without a support crew following me around, so she must be launchable and retrievable without help, able to accommodate sleeping aboard when necessary, and roomy enough to haul all my gear. 

Oh yeah, haulouts.  I guess this boat will also need deployable landing gear.  OK, so now I’m imagining a pretty little amphibian pedal/solar/sail micro-trimaran that can fold up for road mode and be dragged a few miles behind my harnessed body, just big enough to support years of open-ended wandering with frequent re-supply stops.  Phew.  Do those curves even cross? 

Let’s be optimistic and assume they do, for one never gets anywhere without audacity.

2.  The Traveling Circuits

I don’t know about you, but life’s social aspects tend to occupy a lot of my attention and friends are important to me.  How should this scale?  In the simplest scenario, I would build one boat and take off on a quest for love and adventure, probing towns and beaches in search of sporadic bliss.  But the downside of this approach, as I learned during the year and a half of my solo 10,000-mile Computing Across America jaunt in 1983-85, is that a succession of beginnings and endings, however titillating, becomes a somewhat hollow lifestyle after a few months—one that is not only intellectually unsatisfying but increasingly difficult to pull off as I age (and as social norms migrate ever further from those halcyon years of the carefree sixties).  My second bike adventure (Miles with Maggie) thus included a full-time partner and was a completely different experience:  fewer giddy peaks of head-over-heels discovery but greater richness and satisfaction.

Back and forth, back and forth.  Should I go alone, or with a mate?  Freedom versus security; gain versus bandwidth.  Aww, do I have to decide?

Contemplating something so absurd as a wheeled, folding trimaran that I can drag down the road forces me to accept serious space constraints.  This suggests an integrated system comprised of a traveling couple and two boats, each specialized to some subset of expedition functionality:  networking and geek toys on one, perhaps, with lifestyle support and cooking on the other.  But relationships are volatile, lives and hardware fragile.  Designing in interdependency seems like a bad idea, for a failed relationship could leave us both stranded in our separate ways.

Besides, what if we end up with three people, or ten… or a number that varies from week to week?  The project should scale linearly, with each boat capable of self-sufficiency but enjoying a synergistic relationship with others if a technomadic flotilla is born.  A pair of boats, supporting a stable couple, is merely one possible case.

The flotilla idea leads to all sorts of interesting fantasies.  A nomadic community, producing a publication and expedition website, releasing videos, arriving in towns in an atmosphere of celebration, doing interviews, picking up consulting gigs, having jam sessions on sandbars and quaffing homebrew shoal draft… hmm, this could get interesting.  My boat could carry a suite of communication tools ranging from ham radio to satellite phone and opportunistic wireless broadband, the on-board Linux box becoming ISP to the group.  Somebody else could be loaded with MIDI gear, another could carry video production tools, yet another a serious camp kitchen.  And then there’s the medic, the photographer, the fiberglass guru, the fabrics wizard, the sysadmin, the masseuse, the oceanographer, the team of ethnobiologists… everybody linked by wireless networking tools that transparently degrade to slower pipes as inter-node distance increases, letting each of us see the location of the others overlaid on a moving chart display as we slowly meander downriver.   Ooooh, this is sweet (as long as I only have to worry about building one of them).

It looks as if we should design the Microship to work alone, yet support the addition of networked sister ships.

3.  Year-Round Field Day

A divergence occurred in the 1980s.  The economics of electronic manufacturing took all sorts of things that had formerly invited homebrewing, and turned them into appliances.  It did this to computers, obviously—my 8008 system in the early ‘70s was wirewrapped and hand-coded, but I can’t even imagine building a serious computer from scratch these days.  Why deal with transmission line effects and fine-pitch packaging, when it costs less than the price of the chips to buy a commodity gigahertz PC, reformat the hard drive, and slurp in a free OS?

It’s the same with amateur radio.  Gone are the days of point-to-point wiring of fat axial-lead components and ceramic octal sockets… almost every ham I know uses commercial equipment with features and performance that would have been unimaginable even a decade ago.  This leads some old-timers to mutter that real ham radio is dead, that today’s “appliance operators” not only can’t send a lick o’ Morse code, but wouldn’t even know which end of a soldering iron to grab.

Well, there’s more to it.  Ham radio is in a situation perfectly analogous to computing:  we can take advantage of fancy integration to move our technopassions from toroid-winding and chassis-punching into new arenas.
 
Fortunately, there’s no shortage of opportunity.  On my bike adventure, I quickly discovered the value of having 2-meter FM to link me to local amateur radio communities while passing through; touching the handlebar push-to-talk switch and identifying myself as “bicycle mobile” was a great way to get conversations started.  Before long, this evolved beyond chatting on repeaters:  while pedaling down the East Coast in 1987, I would transmit automatic text beacons via 1200-baud packet radio, stopping to have coffee or stay in the guest rooms of hams who lodged invitations in my on-board BBS as I rolled along.  In ‘89, I fell in love with the OSCAR-13 satellite, and managed a contact with a chap in Tasmania while schlepping a huge array of crossed-yagis clamped to the bike’s antenna mast… utterly impractical, of course, but a cool hack.  I engaged in the spectrum-inefficient practice of live chat with distant packeteers via chained digipeaters and wormholes, typing ASCII on my handlebar chord keyboard.  And naturally I carried a regular HF ham rig and a folding dipole antenna, ragchewing from campsites, back yards, and occasionally even while mobile.

The Microship project is luring us into ever more intriguing territory.  We’ll certainly want to send continuous GPS-derived beacons through a network called APRS, keeping our location and basic telemetry always visible on an Internet-accessible map server.  We can also use ham radio to extend the “shipnet” with long-range alternatives when the zippy commercial wireless LAN runs out of steam, in the process giving us a “back door” into the network that lets me reboot the machine or set security with touch-tone commands from a walkie-talkie.  And there’s something delightfully anarchistic about slipping quietly through the night while engaging in solar-powered communication that has no respect for national borders, corporate backbones, draconian rights management, or power grids.

This stuff is just intrinsically cool, and many of my Microship daydreams incorporate quirky communications beyond those that have become commonplace:  chatting with someone a thousand miles away via low-earth-orbit satellite, taking advantage of DSP “processing gain” to extract clear text from noise, browsing our day’s breadcrumb trail on the web, watching live video from each others’ boats or backpacks…
 
This is what ham radio has been about since its inception.  Let’s make the Microship a communications playground, striving for DC-to-daylight capability in as many modes as possible and making everything remote controllable.

4.  Corporate Urinalysis

At some point during the media-intensive BEHEMOTH era, when it seemed that every few days I was doing yet another magazine interview or TV show, I began to realize that I was missing an excellent opportunity to piggyback real content onto what was essentially a nouveau-tech human-interest feature story. I was turning people on to new ways of thinking about emerging technologies, but rarely did I actually discuss issues.  Although I’m not interested in becoming a mouthpiece for any particular group and assiduously avoid identification with “–isms,” it did begin to seem as if I should be sharing a few insights beyond “this is a really cool bike.”

As the Microship project began to take shape in my imagination, I found myself becoming more and more intrigued by data collection—not just internal systems diagnostics and navigation essentials, but water quality and other environmental observations.  With a database-centric infrastructure and good telemetry tools, this system could become a roving probe, streaming location- and time-stamped observations from a suite of sensors.  The on-board console display could present sets of “soft instruments,” each clickable to show a history plot over any specified time range, synchronized with data from other sensors to allow correlations.  The same information (presumably with lower sample rate, given the thin pipe between the boonies in the wild and those at home) could appear on our project website.

As I began exploring this idea, it became clear that this could scale up to something interesting if we do it right.  Responding to one of my project status postings, Seth Ceteras coined a term to describe this concept:  “I imagine your boat floating serenely down a lazy river,” he wrote, “and in addition to the usual physical wake in the water, there is a data wake, a web-accessible data stream flowing back through all the time-spaces the boat had just, and indeed ever, inhabited.”  I snagged the datawake.com domain name, and decided to open the entire architecture, allowing others to contribute to a server-resident repository of environmental observations.  Our lead software guru, Ned Konz, added the notion of tagging data streams with trust values based on the imprimatur of the scientific community, calibration standards, and longevity of the source. We’re even toying with the idea of inducing other sailors to add telemetry boxes linked to our network, offering remote tracking and security features in return.

See how easily this stuff gets out of hand?  It’s a case of creeping featuritis before the project even gets off the ground:  we start with the practical need to monitor solar peak-power tracker performance so Tim Nolan can tweak his algorithm, and end up trying to change the world.

Well, whether or not the latter happens, we are integrating data collection tools into the Microships, and have fantasies of kicking polluter-butt by using our inevitable media presence to decry disturbing anomalies in collected data.  “You let your kids swim in this?” I’d ask, wrinkling my brow at the camera in a weathered squint of professional consternation while gesturing vaguely at the water behind me.  “When we passed that mill about 6 miles upriver, the pH and dissolved oxygen went all to hell, and my underwater camera confirmed a die-off of aquatic grasses downstream of the mixing zone around their outflow pipe.  The data and images are all on this CD.  Seeya!”

There’s no guaranteee that corporate urinalysis piggybacked on the media buzz of the expedition will be enough to galvanize local groups into following up.  But it will be fun, and that’s the bottom line.  This is but one example of how the Microship should become the infrastructure for a variety of secondary projects, underscoring the need to design the on-board systems with as much generality and flexibility as possible.

5.  Sensory Enhancement

There is a lot we can do with data-collection tools besides sniffing the air for alpha particles while drifting past the Hanford nuclear reservation.  Virtually every aspect of this adventure can benefit from a rich array of sensors and a way to manage the resulting flood of information.

Since we’re in blue-sky mode, let’s imagine some of the things we might want to do that involve our yet-undefined suite of sensory inputs.  We’ll assume that we can easily switch among an arbitrary number of audio, video, analog, digital, and serial data streams—and have a way to generate scripts that route channels to client software, conjure live display widgets, stuff readings into a database, or pipe anything via wireless LAN to a remote laptop.  Donning the brainstorm hat, we find no shortage of ideas:

With all that in mind, it looks like we want to approach this design with an eye toward making every subsystem and component “verbose” and networked into the system as a whole… though we should state up front that some survival-critical components (like navigation lights) need to be able to stand alone.

6.  Entertainment

Yes, yes, this whole thing is entertaining, but here I’m referring to music, video, and other palliatives of the psyche.  With all the cameras and microphones (including a hydrophone), we’ll certainly have the opportunity to produce amusing documentaries of this adventure, and maybe someone will even come along who’s an expert in that area and become the fleet videographer.

But I’m also a consumer of electronic amusements, and the Microship system will obviously include an MP3 server.  I chuckle with embarrassment at how close I came a few years ago to buying a Sony 150-CD jukebox, honestly intending to hack its user interface and integrate it into Hogfish.  Fortunately, I work slowly, and had not yet gotten to this by the time the concept had become a quaint anachronism.

Of course, there’s no particular reason to constrain the entertainment audio to the waterproof speakers in the cockpit, not with an audio crossbar to play with (I’m not skipping ahead, honest—I first did this for the bike and it’s always been a known component in the Microship system, even when I thought I would be paddling a kayak).  One of the dozens of audio devices we’ll need is a synthesized low-power FM transmitter, turning the boat into a radio station serving the flotilla, as well as the personal walkman radios when lounging around in camp.  We should be able to control the MP3 player from a distance via palmtop or walkie-talkie… including selection, via the crossbar network, of other audio sources besides music.  Here’s yet another component of the security system:  I could be sitting in a café, listening to live goings-on around the boat on a discrete little radio, only dragging out the laptop and logging into the webcam if there’s reason to worry.

We also need to incorporate music-generation tools.  I play the flute, and acquired a Korg X5DR synthesizer to use as an accompanist—my Mac laying down a blues track via MIDI while I jam away.  This will migrate to the boat (reduced, like everything else, to a naked circuit board hanging off power/serial/audio channels), and I have fantasies of nomadic pals who collectively form a band.  No idea if we’ll ever actually do that, but we shouldn’t unnecessarily limit our options at design time, should we? 

The point here is that a complex system like this can be viewed as a critical mass of computer-controlled functionality, to which new features can be trivially added.  Flexibility is the driving idea behind the emerging Microship architecture, and we must remember that at every stage lest we paint ourselves into a corner.

7.  The Work Environment

Alas I’m not wealthy... and thus must accept the annoying truth that I have to do something for a living.  Given my nature and reluctance to wake up early to commute, employment doesn’t seem to be an option, so over the years I’ve managed to survive on a random mix of freelance writing, speaking, luck, trade work, nickel generators, and occasional project spinoffs.  But writing is my primary career—it says so on my tax return, so it must be true.

It became clear during my bicycle travels that without the ability to write while riding I was basically on a long vacation—one I couldn’t afford.  This led to the handlebar chord keyboards for which Winnebiko II and BEHEMOTH became somewhat infamous.  After all, I didn’t have much choice:  on a bicycle, the position of my hands was predetermined and not particularly optional.  (True confessions:  when considering  a kayak as the Microship project, I, um, briefly sorta thought about putting a chord keyboard on the paddle with a wireless link to the boat.)

Fortunately, a trimaran isn’t quite as restrictive in the hand-position department, especially if we manage to build an efficient autopilot so I’m not always gripping the rudder controls.  This introduces the possibility of using an industrial sealed QWERTY keyboard that floats around the cockpit, along with a pointing device.  I’m not sure I like this, however: my knees will be bouncing up and down when I’m pedaling, close-quarters river navigation doesn’t lend itself well to autopilot control for more than a few minutes at a time, and the cockpit environment is so tiny that any loose object is going to be an endless nuisance. 

Maybe we should have one of these for use at the dock, but include a chording system in or near the rudder controls so I can type while underway.  It’s also worth keeping speech input in mind—after a decade of “Real Soon Now” promises, it’s getting moderately realistic, although I have no experience using it as a writing tool.  And various manufacturers are releasing alternative gestural input devices that may lend themselves to comfortable text entry.  We won’t worry about the details just yet, only observing at this daydream stage that it is absolutely essential to solve this problem… and, while we’re at it, the problem of coming up with a display that won’t wash out in daylight.

8.  The Expedition

Finally, while fantasizing about what we want here, we really should discuss the expedition itself. This part requires brutal honesty, for it’s the easiest place to screw up—we need to test the emerging design specification against real scenarios.  Thinking, for example, that a kayak is suitable for ocean crossings might satisfy a deep macho craving, but in practice, it’s tantamount to suicide (although it has been successfully done).

“There’s glory in using inappropriate tools. 
You can tell you’re pushing a new frontier
when all available tools are inappropriate.”
—David Berkstresser

In the early days of this project, I should have realized that both the Fulmar and Hogfish were impractical in their separate ways, given the loosely stated goals and constraints of this project.  But I had not yet gone through the process of laying out a clear wish list and mapping it onto a design spec as we are doing here; nor had I spent enough Time On Water to accurately predict the impact of a gonad-crushing centerboard trunk when exhaustion makes sleep necessary and there’s no place to beach the boat.  The engineering lesson here is that an accurate model of the application is at least as critical as a solid understanding of the design itself.

We’ve already established that ocean crossings are out, as is skull-crushing wilderness whitewater.  What should we design the Microship to do?

Given the constraints of a teensy boatlet and my own preferences, the operating environment can be loosely defined as “coastal and inland waterways.”  This allows for epic journeys without having to prepare for long periods without re-supply, since we can count on some measure of marina support along with the ability to beach and slog inland for food.  Also, the postulated amphibian capabilities give us a level of flexibility almost unheard-of in the nautical community:  the opportunity to bail (in the non-bilgewater sense) when conditions are just too ridiculous to contemplate riding it out.  I don’t want to be waiting in line behind people with deep pockets to use the only available hoist when things are getting snotty. I’ll just find a beach or ramp and get the hell out of there, hoofing it to the nearest high ground with a half-ton of boat lashed to my butt.

I never said this would be easy.

So in various ways, the emerging canoe-scale amphibian pedal/solar/sail micro-trimaran design lends itself to protected waters:  rivers, lakes, and the “The Ditch” that provides safe passage along most of the Atlantic and Gulf Coasts.  Quite a bit can be done with this right here in North America, including a possible expedition that covers about 14,000 miles:
  1. Launch in the Springtime near Billings, Montana on the Yellowstone River
  2. Meet the Missouri at Williston, North Dakota
  3. Follow the Missouri nearly 2,000 miles to its confluence with the Mississippi at St. Louis.  “Since you’re following the Lewis & Clark route in reverse,” observed Greg Jacobs, “You should call yourselves Clueless & Lark.”  (From what I’ve read about some parts of this river, this would be accurate.)
  4. Float down the Mississippi to the mouth of the Ohio
  5. Struggle up the Ohio to the Tennessee near Paducah, Kentucky
  6. Cruise the languid Tennessee and Tombigbee Waterway all the way to the Gulf of Mexico at Mobile, Alabama
  7. Turn left along the Intracoastal Waterway (ICW) along the Gulf Coast
  8. Follow the exposed coast of Florida south through Tampa
  9. Sneak through the Everglades Canal, exiting at Flamingo
  10. Putz around Florida Bay, landing in the Keys
  11. Hang around Key West for a while and savor the tropical winter
  12. Head north in the Springtime, up the Atlantic Coast on the ICW
  13. Shortcut up the Hudson River to the Erie Canal at Troy, New York or continue north past Boston, meander along the foggy Maine coast, deploy landing gear and haul the boats 15-20 miles across New Brunswick, careen around the blustery Gaspé Peninsula to the mighty St. Lawrence, fight the current & heavy shipping traffic upriver, then zip down the Champlain Waterway to Troy.  On second thought, yes, shortcut up the Hudson River to the Erie Canal…
  14. Pedal back in time on the Erie Canal across New York State, exiting into Lake Ontario at Rochester
  15. Cross the lake to the Trent-Severn Waterway
  16. Meander through the Great Lakes
  17. Return to the Mississippi via any of three possible paths, depending on season and sanity
  18. Drift down the Mississippi and motor up the Ohio to stop in Louisville (my old hometown), as good a place to stop as any.
 
possible expedition route

One of many possible Microship expedition routes, though we are most likely to first do a trip of more modest scale in the Inside Passage, near our home waters of the Pacific Northwest.


Having said all that, I’ll also tell you that without exception, every prediction I’ve ever made about the course of my wanderings has been proven wrong.  But it should give you a good idea of the intended scale of the expedition and the general class of environments we expect the Microships to handle.  In the meantime, we are undergoing “mini-expeditions” and kayak trips in the Puget Sound region.

It’s clear from all this that certain issues of seaworthiness, equipment packaging, livability, provisioning, communications, security, visibility, and nautical style are implied.  We’ll be sharing both fresh and salt water with freighters, ferries, speedboats, personal watercraft (or PWCs, correctly pronounced “pwicks”), drunken power boaters, yachts, hull-fracturing deadheads (no, not the tie-dyed kind), toxins, gales, dangerously skimpy bikinis, coral reefs, clapotis, williwaws, alligators, and the plague. There will be moments of mind-numbing fear…

“I don’t much care for sailing,” quoth a woman on rec.boats many years ago.  “It’s too much like my wedding night:  90% boredom and 10% pure terror.”

We have to be able to take care of ourselves, and, presumably, have fun—otherwise, what’s the point of all this?  I could go on listing progressively more fanciful requirements, but by now I think we have enough orthogonal views of the project to start turning these daydreams into a realistic design.


Distilling a Spec

We have briefly looked at eight “daydreams” that express, both explicitly and between the lines, what we wish to accomplish.  Our next task is to extract the essence of all this and create a high-level verbal design specification.  To keep things clear, we will do this in two parts:  the substrate (the boat itself along with all nautical and mechanical components), and the systems (everything under the hood, expressed in software, or connected via network).  In some places like propulsion the boundaries get a bit blurry, but I can’t think of a better delineation.

The goal here is not to freeze a complete specification complete with parts lists; it is to establish a clear picture that doesn’t creep with every new idea.  This is essential if the parts are expected to fit together:  I might get the idea up front that a wind generator would be useful, so I acquire one.  A few weeks later, I choose a canoe as the center hull of my sleek little boat, forcing me to admit, with considerable reluctance, that there is no way the wind generator, still in its box on the shelf, will fit.  This is the stage where we resolve such conflicting desires and stabilize an image of the system that is clear enough to persist in our minds as we start wrestling with details, chasing shortcuts, and incorporating the ideas of contributors. 

I can’t stress strongly enough the importance of this step:  without a mental model that is well-described on paper (or its modern, terrifying equivalent:  voluminous hard drives with one-year warranties), we will inevitably end up with feature bloat and a potentially endless cycle of improvements and refinements as available resources continue to evolve.  (I know one small company that has been developing the same product for over 15 years without ever actually releasing anything to the market.  They keep incorporating new materials, new controllers, new software, new requirements from their target industry… it never ends, so they constantly improve and redesign their system.  We gossip about their business as a tax shelter, not a case of true product development—they should have been clipping coupons years ago.)

Casting a design in stone isn’t easy, though.  Mapping our collection of daydreams onto reality calls for accommodating a set of needs so diverse that their mutual conflicts aren’t yet even apparent:  robust power-generation, propulsion devices, reliable embedded-control systems, scalable computing resources with a decent use interface, communications, integrated maintenance tools, some hard-core mechanical engineering including harsh-environment packaging, amphibian capability, and support for the on-board human—not to mention navigation, safety, and nautical gear—all integrated into a canoe-sized package that can sail.  Where do we even begin?

Acknowledging the Inevitable

We might as well deal with the biggest problem up front:  no matter how smart we think we are and how thoroughly we define the system, we cannot possibly anticipate all the clever stuff that we will think of next year.  (If we could, we’d just go ahead and think of it now.)

This is more than just an annoyance; it shapes the design (or it better, if we are to avoid big problems later).  The more longevity is expected of a system, the more it has to be designed from the beginning to accommodate unanticipated change.

I’ve been bitten by this before.  The Winnebiko II (photo) was a lovely machine when it rolled out of the lab in 1987, but within months I was reassigning console switches (rendering their painstakingly handcrafted legends meaningless), scrawling little notes in a binder of tattered documentation, and kluging new additions that required me to remember inconsistent modes and states.  It was a static design, complex and extremely nifty at the moment of completion, but it made no allowance for revisions down the road.

So I paid a lot of attention to this problem when developing BEHEMOTH (photo), using crosspoint switch matrices to allow any audio or serial devices to talk to any other, creating a bank of power-control FETs to support flexible power management, and implementing a very general front end in HyperCard.  The front panel was machined to fit the sexiest LCD of the epoch for use with the DOS box... but just before launch two years later, a state-of-the-art active-matrix color model was donated (along with a card that could let me run the SPARC while mobile).  Did I use it?  Of course not:  my network architecture may have been supremely reconfigurable, but I had forgotten about the raw hardware.  Changing the display would have involved fabrication of a whole new front panel from a blank piece of aluminum, along with months of work re-building what was already quite adequate for a bicycle tour.  The existing LCD was so dim that when I was outdoors, I couldn’t tell whether or not it was turned on... but I hauled it and its associated 286 system around the country anyway, booting it up for the occasional indoor demo.  (Fortunately, the Mac screen was a non-backlit active matrix display that loved direct sunlight and another DOS board stack drove a heads-up display in the helmet, so it’s not like I had a crippling shortage of computing power.  But still, it was kind of a shame.)

In retrospect, the right approach would have been to make a big polycarbonate window in front of the moral equivalent of perfboard, so a weekend with standoffs and creative fascia-trimming would allow a display hardware swap.  Another lesson learned.

A related problem involves lack of experience in the application space, translating into precise but wrong design specifications.  In the Microship project, although we’ve been extremely careful to design in a mind-boggling level of flexibility to accommodate future enhancements, we still get bitten by simple naiveté now and again.  The only way around that problem is to begin a testing program early, even if it involves temporary lash-ups:  features that seem essential in the land of daydreams sometimes turn out to be irrelevant in reality, and vice versa.

So as we proceed, we must remember two things:  always accommodate the unknown, and accept that we never know as much as we think we do about what it’s really like out there. 

The Essential Microship

Let’s start by ignoring the blinky bits, antennas, hydraulics, and all nifty things one can do with wireless networking and a suite of sensors.  Under all the gizmology is the chassis: a homebrew micro-trimaran.

The first question (a very good one, in weary retrospect) is why homebrew?  When approaching a project of this scale, knowing up front that it can gobble years of your life before it starts to become a toy instead of the World’s Largest To-Do List, it is wise to do everything possible to avoid wheel-reinvention—especially in those areas where you are neither an expert nor particularly inclined to become one.  In my case, being a boatbuilder has never been on my list of career goals, and what I really wanted was a suitable off-the-shelf substrate for the fun stuff.  Unfortunately, my definition of “fun stuff” is so bloody convoluted that this turned out to be impossible:  nobody seems to manufacture amphibian pedal/solar/sail micro-trimarans with sealed enclosures for electronics, along with deck fixtures for enough antennas and probes to make the Coast Guard suspicious even before there were terrorists lurking in every shadow.

So after sadly concluding that I couldn’t shortcut the project by buying a Microship case and motherboard, so to speak, I started seriously looking into the requirements.  In keeping with our objective of mapping daydreams onto specs, let’s try to define what we really need here.

The first requirement is a wee trimaran.  Implicit in this whole enterprise is the need for a one-person multihull, as opposed, say, to an overgrown kayak—I want speed, stability, room for solar panels, and the kind of light weight that is hard to achieve with a lead keel.  In this size range (limited by what I can drag out of the water without help), three hulls are better than two for various reasons, so let’s accept that as a given.  You have to make certain initial assumptions based on intuition and feel; after five years of discarding naive notions and spending a lot of time around boats, I had developed a clear sense that this was the right approach.  We can generalize this with the observation that any system design will have a starting point based on what feels “obvious,” and that is of course most likely to be correct if the designer has enough experience to recognize the essentials and reject the absurd.  When I initially made the transition from bicycle to boat, my ideas about marine architecture were laughably simple-minded; only after throwing a lot of time and money in weird directions (otherwise known as fast-tracking a learning curve) did I have enough experience to make sensible choices.  And yes, I know that someday I will wince in embarrassment at that sentence.

But for now, we will accept that it is perfectly rational to contemplate spending a year or more living on a boat small enough to haul around behind my body.

We immediately encounter a few practicalities that are more or less implicit in boatbuilding.  We don’t want this thing to sink if it gets a hole punched in it, so it should have independent flotation compartments.  Trimarans come with two of those for free (the outer hulls), but let’s also split the center hull into three segments:  a big middle one to sit in, and fore and aft compartments for gear stowage.  Bulkheads will isolate the spaces, rather convenient as there are two places on the boat where we want prodigious strength anyway:  where the crossbeams meet the center hull, we have to accommodate the cyclic heeling forces from wind loading.  So we’ll integrate the bulkheads and crossbeam structures, with careful stress distribution into the rest of the hull.

The other high-stress area in a sailboat involves the rigging:  especially with a free-standing mast, the only reasonable choice on something this little, there is some serious bending moment where the “stick” enters the deck.  Let’s tie that into a bulkhead too.

At this point, we almost have a basic trimaran:  some kind of center hull with fore and aft sealed compartments (including gear hatches), two crossbeams tied into bulkheads, a pair of simple outer hulls, and a mast.  How big should it be?  Given that one of our stated goals is to keep it as little as possible, it could be truly tiny… there’s a whole class of 3-meter trimarans that are car-toppable and loads of fun, and something of that size would certainly not be too heavy.  What factors affect this decision?  What about the need to sleep on-board?

Yikes, we just ran into our first real constraint.  I’m a tall guy, and by the time we leave room for the inevitable hardware hung all over the bulkheads, we’re going to need about 8 feet of length in the center hull segment with at least 2 feet of width.  This would provide a coffin-like space in the bilge where I can unroll a camping mattress and sleeping bag.  Other body-related constraints include the need to pedal in a recumbent position, support a control console tall enough for a laptop-scale display, and leave me enough room to move around.

Given that we don’t want to build hulls from scratch unless absolutely necessary, it is tempting at this point to think of commercial products that meet the basic requirements stated so far.  It is always desirable to nail something—anything—this early in the design process:  selecting one core component can eliminate thousands of variables and serve as an anchor for subsequent thinking.  We just have to be sure we don’t choose the wrong thing at this stage, or everything else will become distorted as a result.  Let’s see… a skinny hull long enough to have an 8-foot segment established more or less in the middle, with room left over for some gear hatches.  Sounds like a canoe to me, but we won’t worry about which one just yet.
 
This is rapidly converging on something that can be visualized.  It’s a short leap from what we have already described to a working sailboat:  there has to be a place to attach the mainsheet (the sail control line at the end of the boom), it needs a rudder, and we have to add some kind of daggerboard or leeboard—a retractable blade sticking down at the right location to provide resistance to leeway and let the boat point higher into the wind.  We won’t worry much about fore-aft placement right now, but there is one issue:  leeboards suck, literally, as they hang off the side of the boat and ventilate like crazy (it looks like we won’t have much room for one anyway, with those solar panels in the way).  But the alternative, a daggerboard, is typically right in the middle of the hull.  This could be a bit rough on certain body parts when I’m trying to sleep, although it would provide a nice place to hang pedals.  Maybe we can sneak it off to the side, still below waterline where it won’t suck air, but out of the way of my body.  A question for the marine architecture consultants.

We win a few other features with this emerging design concept.  There’s room for a big cowling that looks like a hooded area in front of the pilot, giving us enough room for all the electronics (especially if it takes a few years to get to that part <sigh>).  There appears to be enough deck space for at least a few antennas, and that huge space between the hulls can support quite a large photovoltaic array—about half a kilowatt, given the rough dimensions we know so far.  We don’t yet know what will be necessary for sail and rudder controls, but those are minor details; the important thing here is that the overall concept satisfies our basic space requirements, lends itself to the refinements necessary to achieve a balanced sailing design, is small enough to let us realistically contemplate singlehanded operation both on- and off-water, and supports the integration of computer and communication systems.  Best of all, at least some of the hard parts—the hulls and, as it turns out, the sailing rig—are available off-the-shelf.

Now we have enough information to build the CAD model (Cardboard-Aided Design):


cardboard Microship model

Original Microship model, built of corrugated cardboard and hot glue.  The solar panels are real.


This is an essential part of the process:  as soon as possible, long before you start calling vendors and making dimensional drawings, cobble together something that lets you carry your fantasies to the next level.  In my case, it was hugely inspiring to graduate from abstract wall-staring daydreams to sitting in my actual-size toy boat, growling a piratical "yarrhhhh" whilst imagining adventures and ham radio, romances and riverside camping, navigation and nomadic publishing.  It was also a reminder that the accommodations would be on the scale of bicycle touring, not yachting, so I immediately started putting accumulated big-boat stuff up for sale and testing the limits of West Marine’s merchandise return policy.

It turns out, by the way, that fitting this thing to my body is a complex problem… there are all sorts of conflicting requirements that end up balancing to a fraction of an inch.  The pedaling envelope is defined by things I don’t have much control over, so I take that as a given.  Between the zone of spinning feet and a windshield tall enough to provide an adequate view of the world, we have the only available console space… translating into a mere 9 inches of display height.  The top of my head is at a level defined by the distance between my butt and the bilge as well as the angle of my upper body; these are constrained by issues of comfort and cranking efficiency.  But that net height determines the location of the arch behind the seat and the foot of the sail.  It took a lot of fiddling with phone books and mockup pedal assemblies to find the correct balance, for in addition to basic accommodation of my gangly frame, the cockpit design has to provide good all-around visibility, a path to shore, ventilation, hydration, comfortable controls, and access to all essential gear.  Resolving all this is a usability nightmare.

But notice how far we have come with a little hot glue and cardboard.  Let’s see what else has to be considered at the mechanical substrate level before we can turn out attention to the geeky bits.

If you’ve ever sailed, you know that doing so without auxiliary propulsion can be, um, interesting:  it’s not uncommon to end up dead in the water, waiting for a puff of wind.  People usually add gasoline or diesel engines, but we’re not keen on further polluting the waterways, carrying smelly fuels, or listening all day to the racket of internal combustion.  We thus want the Microship to carry two independent subsystems for auxiliary propulsion—a pedal drive unit and an electric thruster.

Early on, I had the luxury of factoring in another existing component:  the Spinfin drive unit by Bob Stuart.  This will mount just outside the hull with its input shaft on the same axis as the pedals, and deploy when needed via some kind of lever.  But when my stores of converted carbohydrates are depleted—or when the solar array is putting out a lot more than we need to run computers and keep the batteries topped off—there should be a more relaxing option.  Let’s postulate an electric thruster that can be deployed as well, letting me putter along more or less forever as long as the sun is shining. 

Without a doubt, however, the most complex mechanical problem is that nasty amphibian requirement we stated back at the beginning—the need to haul out without invoking a tow vehicle and transport the boat at least a few miles behind my own straining body.  In principle, this doesn’t sound too bad, just some deployable wheels and a way to fold up the crossbeams and retract the mast.  But when we think it through, the constraints start to pile up:  geometry and tracking issues, sufficient wheel retraction to clear the water or some kind of space-hogging stowage, response to a hard landing, ability to deploy from the cockpit, castering when in reverse… all compounded by the pervasive corrosive environment, development cost, and operational complexity.  This is a perfect example of that naiveté problem I mentioned:  the first-pass approximation is fairly straightforward and easy to sketch, and landing gear are critical to the success of the mission, so we adopt a sort of blind faith in them and oversimplify the design in our imagination.  It’s irritating to see how hard this might be, so let’s just ignore the problems, try not to think about the fact that most boats don’t have wheels (probably for a good reason), and optimistically press on. 


Microship forward landing gear assembly

Sneak Preview:  Microship landing gear.  If we had only known how hard this would be...


If this sounds like the equivalent of deus ex machina, remember that a gonzo engineering project requires what we might call enlightened chutzpah.  You have to balance the weight of your experience and research against a fervent belief in your ability to overcome limitations (which is, after all, the definition of hacking).  If intuition tells us that something is possible even though we can’t draw it yet, then let’s have a little faith in our hacker natures and believe that even if we run into dead ends, somehow it will get done.  In the landing gear case, I sketched at least a dozen alternative designs, none of which were right.  But collectively, they illuminated a sort of behavioral space that looked big enough to contain a workable solution, so I blithely moved on to component acquisition.

See why gonzo engineering makes managers nervous?

Practicality Filters

A clear image of the physical substrate is now emerging, and we might be tempted to freeze the spec at this point and begin the entertaining process of acquiring parts.  But there is one more step that needs to be taken before uncorking buckets of epoxy and slapping on fixtures.

We need to recognize and document a set of practicalities, including constraints and specific operational requirements, that will act as a filter for the myriad design decisions to come.  In a tightly integrated system, everything affects everything else, and—to use an absurdly obvious example—we might be tempted to carry enough fresh water for a week at sea only to discover later that the tankage eliminates any possibility of sleeping on board.  But there’s a fix:  as new ideas arise, you simply expose them to the multi-stage Practicality Filter.  If they pass all the way through without breaking any functionality or violating constraints, then they are valid candidates for inclusion in the system.
You can view this process as another step in the mapping of daydreams to reality.  What we’re really doing here is reducing the our vaporous fantasy to a set of rules and clear objectives.  This is something we will want to do at various levels of magnification with every aspect of the system design; it’s reasonable to have multiple sets of filters in a layered system like this, but be careful to avoid the pointed index syndrome that occurs when gray areas between domains allow sloppy design. This occurs when those in different departments point their index fingers at each other in the attempt to redirect blame for mistakes (a well-recognized result of hardware and software being treated as separate realities).  Solo hackers aren’t immune to this, so don’t get smug:  if you find yourself doing a lot of TBDWL items (To Be Dealt With Later), you might be creating an inter-domain practicality-filter gaposis in which hugely evil snafus can lurk until emerging to bite you on the ass just when you think you’re finished.

So let’s lay out a collection of factoids affecting this design, and refer back to them whenever feature creep or newly announced gizmology tempt us to modify the design.


That should do it.  We now have a reasonably clear image of the nautical substrate, along with a suite of simple tests to perform whenever we’re tempted to make changes.  It’s time to move on to system design.
 

early visualization of Microship design

Artist’s conception of the Microship, reflecting early brainstorming.  (Natasha Clarke drawing)

Under the Hood

If flexibility is indeed a major design objective, as we claimed somewhere back there, then this is where we can have some fun—system designs are more tweakable than structures of fiberglass and machined aluminum.  It shouldn’t be too hard to make every interconnection software-mediated, allowing all sorts of amusing configurations.  But before thinking about how, we really need to consider what.  Implicit in this whole project has been the need for an integrated system with graphic user interface and rich datacomm tools.  But what on earth for?  What requirements should our design attempt to address?

Basic seamanship dictates that all boats have a basic set of communication, navigation, and power resources:  at a minimum, we must be able to hail the Coast Guard or other boats on Marine VHF, get a weather report, find our way to the next waypoint in the fog, and keep the navlights aglow while sneaking across shipping lanes in the dark with our tails between our legs.  But this is a Microship, and we’re geeks, so we need more.

Power Management

This is a fundamental area, so let’s start here.  How bad could it be?  A battery, solar- and shore-power charge sources, and some kind of status display… it doesn’t sound too complicated.  Well, between the desire to optimize performance and our relentless thirst for information, it quickly gets out of hand.

Take the solar array, for example.  Since this is intended to be one of the three primary motive forces (in addition to pedals and the sail), it’s rather large for a boat of this size—on the order of two ping-pong tables, filling the spaces between the hulls.  But if we were to keep things simple by just wiring them all in parallel and connecting them to the battery via a charge controller, we would have a major problem as partial shading (a common condition) more or less takes down the whole array.  So we want to break it up into channels, and for various reasons, eight 60-watt modules is a handy configuration.  But before we shove this into the battery or thruster, we have the opportunity to do something clever:  subject each channel to a peak-power tracking algorithm.  Photovoltaic outputs have a huge nonlinearity, and if we monitor the product of voltage and current, we can dynamically tweak all the PWM (pulse-width modulation) controllers to optimize power output and yield a “gain” of 15-20%.

Collectively, the trackers can keep an eye on the battery level and other system loads to act cooperatively as a charge-manager, but now we have another temptation.  The biggest single electrical load in the system is the electric thruster, and because of the stated requirement that we keep the boat as light as possible, there’s not a large battery bank (just a single Group 27 marine 12-volt lead-acid, roughly 100 amp-hours, though we certainly hope improvements in battery technology let us upgrade soon).  If we’re careless and/or lazy, it would be easy to kill this lone battery with just 2-3 hours of electric cruising.  Why not use another microcontroller to monitor the system loads and other data, automatically tweaking the power to the thruster in cruise mode so that it tracks maximum available surplus solar power without impacting the battery?  Of course, we need a full-power oh-shit! mode as well, invoked via an easy-to-find switch during moments of terror:  when on a collision course with a freighter, the future status of a battery is not particularly interesting.

Already we’re up to a few microprocessors, depending on how the peak-power tracker is partitioned, but there’s more.  We’d certainly like to know what all this stuff is up to, as it’s a critical subsystem, so let’s add a little micro that collects data from the other guys and manages a dedicated power LCD while passing a serial telemetry stream to our console system.  At the user interface level, both locally and via wireless LAN on a remote laptop or other boat, this can be displayed in all sorts of creative ways—including a live map of the power subsystem, graphic battery level and projections to empty or full, and presentation of 8-channel historical solar data to let us assess cell degradation or recurring shading patterns.  Since all this will be databased and transmitted via our various wireless network pipes to the home-base server, our development team can assess algorithm performance and upload patches as necessary.  Besides, anomalous array shading or unexpected power sinks might be interesting from a security perspective.

See how quickly this gets out of hand… and how easily we can add features if we assume the presence of a lot of silicon and some communications infrastructure?

Security

One of my recurring nightmares during two decades of hauling complex and expensive gadgetry around (and frequently leaving it unattended while engaged in other activities) involves the havoc that could be wreaked by those of ill intent.  Theft of hardware, mean-spirited vandalism, random tampering, black-hat probes of my network via 802.11, and even innocent poking in the wrong place by dim-witted tourists—all represent significant potential loss.  There are even a few things, having nothing to do with ne’er-do-wells, that could ruin my day:  a leak flooding the hull, some kind of error latching on major loads and killing the battery, the boat dragging anchor and drifting into a rocky surf zone… hell, it’s scary out there!

An important category of applications thus involves keeping an eye on every observable phenomenon and responding in various ways to sensor inputs.  This must accommodate a lot of variations, many of which cannot be anticipated, so some kind of editor will be necessary to create those security macros mentioned earlier.  These can be expressed as a matrix, with inputs on the rows and actions on the columns… their intersections checked or not as appropriate.  Or perhaps they should be scripted, or drawn with an editor that lets me create instances of objects representing events and point them at actions.  Whatever the implementation, this is a critical part of the system, covering autonomous responses, communication with my backpack or the other boats in the flotilla, and even a sort of “five-alarm fire” in which calls for help are sent on all available channels to emergency services.  We could even post a HELP message along with my GPS coordinates to the nomadness mailing list and drive thousands of people around the world mad with worry.

As with the power system, this involves a lot of layers:  sensors of various sorts (some of which may be associated with embedded micros), serial streams from other devices, automatic switching of power to communication tools, routing of audio to various places (a voice alert transmitted to me by ham radio, or a warning spoken via the on-board stereo speakers), antenna tuning or selection, and possibly even direct intervention in operation of the boat through thruster or autopilot controls.  If every resource has hooks, then it is up to software how to make the whole system dance.

Sensor Sweeps

As I mentioned back in the daydreams, I’ve grown intrigued with corporate urinalysis, and the Microship(s) will carry at least a basic suite of environmental sensors (there’s a list coming up).  In addition, we want to look at all relevant meteorological conditions including wind and lightning, as well as information useful for navigation.  The security system calls for a lot of state sensors, and while we’re doing that we might as well monitor various system temperatures, enclosure integrity, and so on.  What do we actually want to do with all this stuff?

At the Microship application level, it can be used in a variety of ways.  Some channels lend themselves to live instrument displays, with virtual meters or other indicators on the console showing real-time information. These could be clickable to show history, or allow selection of multiple channels for simultaneous display on the same timebase.  Somewhere in there, we need a central database that is continuously being updated with time-stamped values at suitable intervals, allowing retrospective analysis of any situation (text annotations and video frame-grabs could even be included in this archive to provide more contextual information).  We’re presumably limited to a thin pipe back to the home-base server, so a scheduler will take a snapshot of current data at prescribed intervals and transmit it for public scrutiny and archiving.

The Shipnet

All this talk of sensors and telemetry starts to become even more intriguing if we distribute it across (n) instances of technomadic boatlets, traveling as a flotilla.  This will call for some clever network infrastructure, possibly in three layers to accommodate variations in inter-node range.

First, high-speed wireless LAN.  This falls apart outside a thousand feet or so unless one uses beam antennas, and that’s a bit tricky on small boats (do-able, I know, but we have enough projects on our plate without computer-controlled steerable platforms that always try to look at each other… although we could re-purpose the video turret).  I expect this to be most useful for local laptop-boat file sharing, mail fetching, and other typical LAN applications.

Second, lower speed wireless modems.  These are available in various flavors with ranges of many miles, ad-hoc mesh network architecture with IP tunneling, and speeds of 1MB/sec or less.  Given that most routine traffic within the flotilla would be telemetry, text messaging, location tracking, and status information, blazing speed is not a huge issue—this would be the default pipe for most activity.

Third, slow packet radio, using ham radios, 1200-baud terminal node controllers, and APRS trackers.  This stuff is robust and draws almost no power, and can piggyback on the local amateur infrastructure for virtually unlimited range extension.  Although TCP/IP has been layered atop this, I see it as an infrequently used “back door” into the network that allows remote low-level diagnostics and control.

Within the flotilla, there is another class of communication requirements.  We’ll naturally want to chat with each other, and rather than depend on voice-over-IP we might just use familiar and reliable radio transceivers.  It’s also likely that live video will need to be piped around, and depending on quality needs this could be either layered on IP (webcams) or handled the old-fashioned way with analog transmitters and receivers.

Grand Central Station

I keep alluding to audio and video routing and power switching as if it’s no big deal, but this actually represents a key part of the emerging Microship system design.  The general strategy is to allow anything to talk to anything:  if, for example, we sail past a pod of whales (before the Navy’s idiotic Low-Frequency Active Sonar kills them all), snagging hydrophone audio and capturing it to an MP3 file should not involve fiddling with connectors and switches.  The computer’s audio-input jack has an address, as does the hydrophone—a script somewhere makes the connection.  As I mentioned earlier, this bit of magic is handled via a crosspoint switching network (photo).

Like the Shipnet, this is in the infrastructure category—the last thing I want to do at the console level is mouse around a big matrix of audio, video, serial, analog, and power channels anytime I want to use the system.  For the most part, this is behind the scenes, with connection sets established by higher-level applications.  For example, I might tap a couple of buttons on the walkie-talkie keypad while sitting by the campfire, sending a command that induces a synthesized voice rendition of the latest NAVTEX weather beacon to be transmitted back.  On the boat, this would turn on the SSB radio, tune it to the right frequency, pipe the audio to a TNC, route its serial output to a speech synthesizer (either peer-to-peer or via a pile of USB-serial ports on the Big Iron), then connect speech audio to a UHF transceiver’s microphone input while yanking the Push-to-talk line.  It’s a one-button operation at the user level, as it should be.  But we have the same problem here as we do with the security system:  I can’t possibly define all the things I might ever want to do, nor am I likely to actually use all the features that I think are cool today.  So one of the tools we’ll have to build will be an editor for resource configuration, along with a way to dynamically display the current interconnects.

While I’m talking about crossbar-related things, I should mention that many of the connected devices span multiple “domains.”  The MIDI synthesizer looks to the system like a power switch, a serial channel, and a stereo audio source.  The VCR looks like another power switch, a serial channel (talking through an interface widget), and a set of audio/video inputs and outputs.  Even the ham radio that is one of our major telemetry pipes to the outside world is just a black box buried in the console, manipulated entirely by Microship software (with its antenna tuner, yet another microprocessor, responding automatically to match the whip at the stern to our transmit frequency).

It’s up to our code to do something useful with all this.  Most of the hardware jobs will involve interfacing and repackaging of commercial products, moving just about all the interesting design work into the TBDWL category.  Dangerous, eh?

The User Interface

Finally, I should say something about how all this looks to the pilot, sitting in a webbed recumbent seat, pedaling along some serpentine waterway.  At such times, I will not be interested in hacking; I will want to be a user.  I won’t be thinking about what’s under the hood; as with the laptop on which I’m writing, I just want it to work reliably and not be painful to use.

The Microship system will need to provide all the usual desktop applications, let me interact with the embedded tools, communicate transparently with a wireless laptop and other devices, recognize and authenticate remote logins, and do all this without forcing me to the command line.  Given the low probability of completing the software before departure, this is a rather tall order, calling for a development environment that doesn’t paint everything with the brush of complexity (amusing in the lab, but daunting at sea).  As we move into the development phase, I’ll tell you about the rather surprising solution, a bit out of the mainstream, that appears to satisfy all these needs. 

Our goal here has been to lay out some daydreams shaping the project, then do the initial mapping onto a set of design requirements.  We can now turn our attention to these much more tightly targeted objectives without being distracted by vaporous images that have a nasty habit of evolving all by themselves.  This is similar to the most insidious “gotcha” affecting any custom engineering job—the disconnect between the business problem and the technical problem.  The client presents the former, you translate it into the latter, the client signs off on your proposal, and you go to work.  Months later, you have solved the technical problem, but the client’s business problem has continued to evolve.  It starts innocently with the first “oh, by the way…” and then gets worse.

Since we don’t want to do that here, we will try to focus on the spec, not the daydreams.   After all, by the time we’re almost done I may be having fantasies of flying.  If we keep readjusting the design to match, I’ll never get out of the lab.  Sound familiar?

We have one last job to do here: capture what still looks a bit like hand-waving and distill it into a few specifics, now that we have seen how things tie together and gotten a preliminary sense of how the system should feel.

A Trio of Wish Lists

Our intent here is to create a sort of “resource pool” from which we can assemble interesting applications.  Since the fundamental goal of this system architecture is to facilitate a wide variety of interconnections among devices while providing a flavorful front end, we get geometrically expanding functionality as we add hardware objects. Imagine the combinatorial possibilities…

The first list shows devices that are somehow associated with audio, video, or communications—the three categories are so intertwined that it would be hard to sort them into separate groups.  (Note that all this gadgetry would kill the battery in a heartbeat if everything were on all the time.  With very few exceptions, every device is also associated with a power-control channel that lets the Hub turn it on only when needed.)

The second list is for all the sensor and telemetry channels—every piece of observational data, internal and external, that is accessible to our code.  Some channels are “derived,” meaning that they are values generated by software (like the battery’s charge level); others are parts of sentences generated by an embedded controller (like cross-track error from the GPS); still others are just analog values or raw bits.  To keep this list from getting out of hand, we’ll generalize a bit and cluster similar things.

And finally, our third list is at the other end of the abstraction curve:  this one shows some of the “views” that we would like to see on the Microship console (or a remote instance thereof, elsewhere on the network).  This is our first attempt to capture the essence of the user interface, though it is far from complete.


Audio/Video/Comm Devices

 

Sensors and Telemetry Channels

Environmental/Meteorological Group

Navigation and Piloting Data

Security and Status

Internal System Monitoring


User Interface Views

NOTE:  These are in addition to the various “desktop” applications and other OS services.  All of the views listed below live within a single object-oriented bitmap environment.  Categories are arbitrary and included for clarity; eventually these will be in a clear hierarchy, but we need a wish list of user interface tools now to create an “application space” between the front end and all the I/O we have just listed.

Standard Default Displays

Power

Navigation (other than commercial charting software)

Resource Management

Security and Data Collection

Communications

Network


Inhalation

Well, we’ve come rather a long way in this article... from vague sketches of gizmoid nomadic fantasies to something that is starting to look like a reasonably tangible set of design requirements.  We know the boat’s approximate dimensions, as well as the major structural components that will make it address our postulated needs.  We have an idea of what it should feel like from the user-interface perspective, with enough specified devices on the other side of some yet-to-be-invented software package to keep us busy shopping and schmoozing for months.

We are also getting an idea about the amount of processing horsepower that will be necessary—just by making a few lists and sketching application categories, it’s pretty clear that we’re looking at something that can easily support a graphic user interface, a big hard disk, networking, USB, and enough processor speed and RAM to operate with an level of briskness more or less on the scale of familiar desktop computers.  For years, we assumed that there would be some kind of power-hungry “Big Iron” that would be booted only when absolutely necessary, handing off maintenance tasks to something of the embedded class in order to minimize battery drain.  This has always been a rather unpleasant thought, rife with synchronization issues, not to mention representing two complete development projects. 

Fortunately, the industry caught up with the needs of this project, and at this stage in the design it’s pretty clear that we can just drop in any capable laptop of the day, accommodate cooling and the daylight-readable LCD problem, and port code over from a development environment.  This opens up participation to a wide community, lets us take advantage of the best possible tools, and minimizes time spent in learning curves and wheel-reinvention.

It’s just like using a canoe for the center hull… and after all, canoe’s not unix.

Back to Resources