The project was seriously in gear at UCSD, and this page carries the posts during the last month of 1993. They were growing, taking on a life of their own, and finding more and more subscribers… and after March each will be its own post.

Microship Status 12/12/93

In This Issue:

  • Still Alive!
  • General Updates
  • Microship Network Overview

Still Alive!

Hey, I bet you thought I bailed out of this whole project and got a job in industry, huh? I mean, this is the first issue of the status report in almost 2 weeks!

Actually, since about 2/3 of this mailing list consists of UCSD students, I decided to ease up on update volume for awhile. This past week was finals, and the feeling of stress was pervasive on campus. Now it’s vacation, which is really quite awful — the whole place is practically shut down, with such fundamental essentials as cappuccino and pizza increasingly difficult to acquire.

But the Microship project has been churning along despite all this, and here’s a quick update on the news…

General Updates

I’ve spent much of the time since the past update working on the Microship Control System specifications — a document that will hopefully be complete enough by early January that returning students will have a cohesive reference on the overall system design. More on that in the next section.

Lots of news on the sponsor front. Paravant, a maker of military waterproof keyboards, is out of the picture, but I’m now in encouraging negotiation with IEE in Van Nuys (proposal almost done). They have submersible OEM full-travel keyboards for the DOS world, and with the Silicon Valley Bus Company’s “Keystone” product coming, we’ll be able to point one PC keyboard at either Mac or DOS platforms. I’m also looking into making a back-to-back pair of UAR/Ts with different clocks, which should allow the keyboard to connect directly to the FORTH hub’s console port when a minimal terminal is necessary (the local 2-line LCD would be the display). Anyone want to take that on as an exercise in small-scale logic design and packaging?

No-go on the Compaq 486, also, though now that I’ve been configuring the I/O-rich Ampro system it’s not as critical. They’re having economic woes and downsizing. The Ampro is looking great, and should be shipping next week: a 286 Core Module, the FSI board for floppy-IDE-serial interface, an ethernet (thin coax) board, and the LCD driver. I already have a VGA card left over from bike development. During development we’ll hang an IDE hard disk on there, and when it comes to packaging in the ship we’ll change to PCMCIA flash memory and possibly upgrade to 386 if it seems justified.

The display for the Ampro is looking good — I spoke with Sharp and they will be donating an LQ6 color LCD for development, probably to be replaced in a few months with an industrial version of the same product (wider temperature range). This display accepts NTSC video as well as computer-generated display data, so it will be the console video monitor for the on-board cameras.

The spec for the FORTH boards is undergoing continuous evolution, and New Micros is shipping an NMIT-0020 for the Hub system immediately (including a 2-line LCD to go with it). I’ll also need a 20-key keypad for the low-level user interface.

The ailing Mac, damaged mysteriously by the SCSI hard disk, is now back in LA thanks to Dave Yao who dropped it off enroute home for the holidays. Mike Clark will find out what happened to it, and it should be back in a couple of weeks.

Luke Abbott has begun the Microship video project — in the past few days we’ve captured raw footage of Vincent Lui playing Liszt (piano) and Isaac Chu playing Bach (violin), since in the video production we want to show that the project participants are not just interchangeable student-modules. We’ve also started filming meetings, drawings, subassemblies, and anything else relevant — with the intent of turning it all into an ongoing subscription video series on the project that will continue after launch. Luke is becoming enthusiastic about the prospect of building a video production system into a boat, so the flotilla concept is of interest here as well… we had a good talk over sushi last night. Everyone working on the project will be on camera — I really regret NOT doing this during the 3.5-year BEHEMOTH project.

I had a good meeting last week with David Crane, whose company develops and markets a wide range of products for the marine marketplace (nautical computing and communications products). We’re exploring equipment sponsorship and Microship-spinoff ideas… I’ll keep you posted.

Finally, I’m changing living environments tonight, moving in with TJ so we can work around the clock. He’s spending the next week here to get a serious start on the mechanical specs, and we’re meeting with Robb Walker tomorrow.

Microship Network Overview

Most of my keyboard time in the last week has been devoted to writing specs, with the Intro, Hub, Audio Crossbar, and Serial Crossbar sections now complete along with related drawings. The full document is a bit much for inclusion in these reports, but the general introduction is appropriate:

Every system design is a function of its environment. In few places is this more obviously true than in the Microship, and before going into detail about subsystems I need to explain a few things.

First, one of the most frequent questions concerns the number of computers. Look at the MCS overall drawing in the back of this binder, and you’ll see over 20 processors (not including embedded controllers associated with products, which would at least double that number). With robust multitasking systems like the SPARC available, why trouble ourselves with so many machines? There are five good reasons…

Minimizing single-point failure potential: A central computer system that runs everything means that a single equipment failure can shut down the whole ship. Considering that there are survival and safety issues at stake here, this would be unacceptable.

Conserving scarce power resources: Large, fast, capable machines tend to draw a lot of power supply current. When power is precious — as in a solar/battery powered system — it makes more sense to match resources to tasks and only power them when necessary. Monitoring a few security status bits overnight with a heavy-duty system would require a continuous draw of an amp or more — with a little CMOS micro, we can do it for 1% of that, and save the power-hungry machines for navigation, graphics, boat-top publishing, and so on.

Simplicity: At first glance, the MCS looks anything but simple — but consider that each computer on the control network is a small, dedicated machine, operating in a very local region and focused on one or two tasks. Building a multi-tasking real-time system that also incorporates a graphic user interface and file support is non-trivial, and hard to get 100% correct.

Development team management: See above. I’d rather break up a project into 20 groups and give each one their own computer than try to manage 20 groups writing code and competing for hardware resources on the same machine.

Cable reduction: Finally, computers can be cheaper than wire, especially where waterproof connectors and critical packaging are involved. It is MUCH more cost-effective to run a single network and power cable around the ship than to distribute complex, device-specific I/O from a central panel. We’re probably reducing ship-wide cabling by a factor of 10 or more by taking this approach.

Now that that issue is out of the way, I’ll make a few general comments about architecture and then start discussing specifics. As you read this document, it will be helpful to fold out the MCS overall block diagram and keep it in view for reference.

The heart of the system, if there can be said to be one, is not a computer but a network. Actually, there are two of them — the high-speed Ethernet that links the console systems and file server, and the low-speed multidrop network that connects all the microcontrollers. The former has been well-documented elsewhere, and can be compared to a LAN that links all the machines around a building (complete with gateways to the Internet). The latter is where most of the people on this project will spend their time, so let’s look at it more closely.

The protocol I’ve chosen is called Easy-A, defined by New Micros of Dallas, TX. The name is appropriate, since this is about as simple as you can get and still call a linked assemblage of microprocessors a network. Electrically, it’s 4-wire “modified RS-422,” with one pair dedicated to transmission from the hub to all remotes, and the second shared by all remotes for their transmissions to the hub. Only one remote can talk at a time, and the others are simply tri-stated (high-impedance). This completely eliminates the need for collision-detection and the other complexities that add processing overhead (power) to the more familiar networks such as Ethernet.

The hub, of course, decides who gets to talk, and it does so by transmitting a control-A over the net. At this point, all the remotes take notice, and, with bated breath, await the address character to follow. The hub then sends a single-byte select code, and all remotes except the Chosen One leave their transmitters tri-stated, in effect remaining invisible to the network.

The selected unit simply enables its transmitter, and the net effect, so to speak, is a direct connection between the hub and the console port of that processor. There is thus no overhead of any consequence, meaning that the hub can be a dumb terminal with a human at the helm. If you want to connect yourself to device F, for example, just hit control-A, then F. It’s that simple.

One of the implications of this is that individual remotes cannot initiate communication on their own over the network, and are thus incommunicado unless the hub takes the initiative and polls them for activity. If extreme power-saving economy is indicated, we may shut down the hub and allow certain critical remotes to yank a wake-up line if something serious is happening — but the basic approach is to depend on the hub to perform a periodic scan of all connected devices to see if any of them have anything interesting to report.

I mentioned a moment ago that the hub could just as well be a human with a terminal. I should point out that this extends to remote, wireless logins as well, whether via a UHF packet radio link from my backpack or a terminal here on campus, logging into the Microship via Internet and satellite or cellular phone. A key design goal is accessibility of all connected systems, and you may one day find yourself talking to the microprocessor system you designed via a 30,000-mile communication link… which should feel about the same as having it sitting on your desk.

One final point. The processors we are using are New Micros 68HC11s with FORTH in ROM. FORTH is quite unlike the normal assembler- or compiler-based development environment, for when you are talking to the machine you are talking to a compiling interpreter… or maybe an interpreting compiler. Writing programs is a matter of adding “words” to the language, building on the low-level vocabulary that’s already on-chip. Since command-line actions can directly address all the machine’s resources, it is conceivable that some of the “controllers” on the network will not even need to run “programs.” The hub can simply connect, and issue a FORTH command to read or write a port…

With that, let’s move on to the specific definitions of the various systems on the control network. In each case, I will name the machine and its network address, give a text description of its role on the boat, and then summarize the required software functions and hardware interfaces. This document will undergo revisions as the project evolves, and may be considered the complete working specification for the Microship Control System.

Microship Status 12/21/93

In This Issue:

  • MCS Hub Board Alive!
  • San Diego Supercomputer Center
  • Kayak Order, Structure, Thrusters
  • Landing Gear Akas
  • Tadpole On The Net

Miscellaneous Updates

Hello from the eerily silent world of a campus on holiday. The few denizens still slaving away in scattered labs pass on deserted sidewalks, pause, and exchange a few words… “sure is dead around here, huh?” “Yeah… Is anything open over at Price Center?”

I’ve been here all day, every day, and sometimes all night as well. I will be here working on the ship even as families across America are huddled in cozy cocoons of consumerism. It seems so far away, bizarre yet poignant: music in the lab ranges from Vivaldi to Depeche Mode, and, mercifully, I haven’t heard a Christmas melody yet this year (though “Greensleeves” is forever tainted, even while Rampal is playing variations on the traditional theme sandwiched incongruously between Franck and Prokofiev…). But when I glimpse a decorated tree still alight on my 2AM bicycle commute back to condo hell it suddenly seems an echo of childhood, almost confusing…

No matter. The tasks before us continue to occupy center stage, and although I have been slow on updates lately since over half the mailing list is offline for vacation, things have been happening.

MCS Hub Board Alive!

I mentioned in the last update that New Micros was about to ship an NMIT-0020 as the first in our suite of 16 FORTH 68HC11 boards for the control system. It arrived about a week ago, and I spent much of this past weekend packaging it on a development chassis (the lid of an old TNC case) along with a small 5-V power supply and a 2-line LCD behind a sloping lexan panel. About half the job involved the usual screwing around with RS-232 (can you imagine how many man-millennia have been wasted hacking serial ports since the dawn of the computer age?), but now it works with both Mac and DOS machines here. I even hand-entered a page or so of LCD driver routines and had fun sending characters to the screen until a pilot error sent FORTH careening into a stack crash that resulted in amnesia.

NMIS-9003 Real-Time Clock

Enroute now are the 5001 serial board (one serial port, configured with drivers for RS-422 that will host the multidrop network) and the 9003 real-time-clock. This should come close to the complete configuration of the hub, and will give us a FORTH development environment replete with enough I/O and resources to provide the requisite visceral joy of actually seeing a computer DO something. If you’re contemplating getting involved in one of the control system teams, this is your invitation to begin the FORTH learning curve. It’s here, it works, and you can use Mac or DOS to talk to it.

San Diego Supercomputer Center

TJ Tyler and I now have access to SDSC, with accounts on the Cray and SGI machines in progress. The Cray will be used for extensive finite element analysis of hull, frame, landing gear, outrigger, and other structures; the Silicon Graphics systems in the Visualization Lab are already being used for renderings of the ship based upon Robb Walker’s sketches, my comments, pictures of kayaks, and any other input we can provide. My sincere thanks to Len Wanger, Mike Bailey, and Mike Kelley for making this happen and working on these magnificent images! T-shirts soon…

We took a tour there last Friday evening and were, frankly, blown away. This is a remarkable facility, staffed by some equally remarkable people. This will be a powerful tool for helping us design this system, and Robb is eyeing it for its potential in working with more traditional clients (imagine handing a prospective yacht buyer a picture of her yet-imaginary dreamboat floating in some dramatic cove…).

I’m sure we’ll have much more to report here as artists’ renderings and mechanical designs proceed…

Kayak Order, Structure, Thrusters

Well, I did it — I just sent $750 as a 50% deposit on the custom hull and deck order from Current Designs in Sidney, BC, Canada. They’re being very nice to us here, basically charging only for materials. What we should see by the end of January is a pair of flanged hulls with extra-robust layup, a matching pair of flanged decks with hatches but no cockpits or rudders, H-extrusion for the whole lot, four bulkheads, and miscellaneous components. This will give us a good head start on the amas, and our task will be to create smooth cowlings for the pedaling envelope, beefed-up structure and detachable outrigger interface, pedal drive assemblies, and hatch covers that can go away in use yet withstand the stresses of rushing water. Should be amusing.

At the Current Designs shop

I’ve moved the thrusters to the inboard sides of the kayaks, in the form of flip-down leeboard-like assemblies pivoting around the pedaling axis. They will now be direct drive, but linked by a clutch to a motor-generator. In fact, there are three clutches, allowing any of four operating modes (in addition to retracted and passive, of course):

o Direct low-loss mechanical pedal-drive
o Motor drive from solar or ship power bus
o Pedal-charging batteries without involving thruster
o Wind-charging batteries by lowering drive units while under sail

Landing Gear Akas

Speaking of interesting mode changes, I had a thought the other day while working with TJ on the mechanical structure. Since Robb’s initial weight distribution and trailer-mode calculations suggest that we can in fact locate the aft outrigger and landing-gear attachments on the same transverse plane as the aft bulkhead (between cockpit and crew module), the obvious refinement is to use the aka arms as struts. By relocating one pivot point in the Farrier-like folding system (see the cardboard hinged model in my lab), we can detach the kayaks, attach wheels, and swing the arms down to form landing gear. Tongue weight should be about 10% of the 3,000-pound estimated total, and this constraint will provide feedback to the weight analysis currently being undertaken on Excel by Scott Poorman.

Tadpole On The Net

I’m going to ask John Studarus to write something for us detailing this when he gets back from vacation — he’s the unix/net wiz in the group, not me. But the short form is that my Tadpole SPARCbook laptop is now at Scripps, continuously on the Internet. We’ve even taken on the $12/month fee for domain name service at UCSD, so this is official.

The machine is a Gopher server, already accepting dozens of connections a day from all over the world as people snoop around and grab my nomadness reports and GIFs. It’s also set up as a mail host for Microship project newsgroups, and will be the archive site for all these reports. You’ll be hearing a lot more about this once John writes a summary of the available services.

The plan is to integrate this into the ship, linked by ethernet to the Macs and the Ampro PC and acting as file and SMTP server. The “Microship Control System” drawing, available now in hardcopy for anyone interested, shows the overall architecture.

Miscellaneous Updates

Solar Still: Dan Perry has acquired much of the hardware for the folding still project (to make fresh water from seawater). The top and bottom frame is made from teak… and this is a good lesson in another reason, besides rainforest conservation, NOT to use rare tropical hardwoods as building material! A 3/4″ plank, 8″ wide and 4′ long, was $40. Anyway, I’m looking for a volunteer or two with good experience in woodworking and fabrication to work with Dan on this — hopefully someone who has a table or radial arm saw to rip this heirloom into the sizes we need. If you want to help, contact Dan directly. Can’t wait to pour in a bucket of seawater, sit in the sun a while, then drink the results! Sounds like a way to justify a beach day as research…

IEE Keyboards: I think I mentioned that Paravant is out as far as waterproof keyboards are concerned — since then, I’ve found a more robust source with a HUGE product line of keyboards and displays for harsh industrial and military environments. We’ve swapped literature and the vibes are good — I should know in a couple of weeks. In the meantime, I connected them with Silicon Valley Bus Company, whose Keystone product designed by Jay Hamlin accepts DOS keyboard and mouse inputs, producing ADB output for the Macintosh.

Autodesk donation: Thanks again to Autodesk for donating a second copy of AutoCAD Release 12 for Macintosh — this time to Nelson/Marek Yacht Design for use on the Microship project! We’ll use this for the whole system design, as well as input to the visualization software at SDSC.

Autocad Release 12 documenation

Specification document: I’m trying, really I am, to finish the full spec document during the “holidays.” I’ve finished four of the 16 sections in the control part, and haven’t even thought about the high-level applications yet. The intent is to have initial specs ready for all student groups beginning FORTH-based control projects in January. Ready now: Hub, Audio Crossbar, Serial Crossbar, and Video.

Media watch: The Jan/Feb issue of Internet World has a 5-page article by yours truly, with lots of pretty BEHEMOTH photos. The subject is “Technomadness and the Internet,” focusing on the methods of decoupling geographically while maintaining a virtual home online. There’s a small article about this project in the December 3 issue of the local rag ComputorEdge, the next issue of UCSD’s Perspectives will carry a piece on the Microship project on campus, and the whole Microship overview along with control system and rendering artwork will run in the February issue of IEEE Potentials. I also interviewed with Popular Science a week or so ago and am negotiating a French documentary film deal. I need something to keep busy, you know…

Lab quest: Finally, I’m not sure how much good this will do, but I might as well mention it here. By March 11, I have to be out of my current borrowed lab in the Engineering Building, and I’m hoping that the next move will be to a place where we can complete the project without further disruption (a panic last week ensued when we discovered a conflict with a planned course… the professor graciously agreed to share space in another lab, but it’s still only a winter quarter solution). If ANYONE on this list knows of 1,200 or more available square feet on campus with ground-floor access, wide doors, a net connection, clean environment, and reasonable security, please let me know ASAP! Things could get very difficult if we don’t find a place to swarm around the hull and spend a year in system integration…

With that, I wish you all happy holidays — I’m eagerly looking forward to the resumption of campus normalcy, easy access to services, and the energy of many people working together on a thoroughly mad project. Cheers!

Microship Status 12/27/93

In This Issue:

  • Microship Visualization
  • Noise Czar Wanted!
  • Forth Development Environment
  • Excel Projects

Microship Visualization

This evening the Microship suddenly seems more real. Bright yellow gelcoat is being sprayed into kayak molds in British Columbia, Mark Reynolds of Sobstad Sails faxed an innovative sail design with carbon-fiber unstayed wing masts, Robb Walker was here this evening with a blueprint sketch of the boat, and Len Wanger from SDSC brought over three JPEG images in exchange for pizza. On the Mac IIFX (back here and happy, thanks to Mike Clark) we can now gaze in wonder at something that is approaching a real image of the ship! Over the next few days, this will be refined, tweaked, and detailed, whereupon we will have hardcopy to distribute to the press and to sponsors. Hey, it might even be time for the Microship T-shirt, rev 1…

I can’t tell you how exciting it is to see the dreams of the past two years begin to take visible shape. While we’re still far from something that sails, these images reflect hundreds of hours of brainstorming — insights collected from engineers, vagabonds, sailors, kayakers, ship designers, composites experts, and even a few smart people who are into everything…

Noise Czar Wanted!

Deep in the bowels of the system, far below all this visualization and ship design, microprocessors are forming alliances. I had a reminder last night of just now non-trivial this is — I took a first pass at building a packet-radio-linked front end to the FORTH control system. I hacked BEHEMOTH’s packet station to be on permanently and linked to an old Yaesu 290 2-meter multimode transceiver, then fired up my “fannypacket” station consisting of an HP-95 palmtop, PacComm Handi-Packet TNC, and Icom dual-band handheld transceiver. They connected, sort of, once I set the bike’s transmit delay to match the older radio, but the noise level in this lab is intense. With three Macs, 2 PCs, and a couple of 68HC11s all wailing away, I had S9 noise on the HT, and retries were legion.

Please note, all you who will be involved in control systems! Micros are broadband transmitters, and there will be enough of them on the boat to seriously hose any and all radio communications unless we start from the beginning with a noise reduction program in force (something I ignored on the bike until too late). I would like to build an ongoing student project around this: if you are an EE with interests in digital, analog, and RF… and if you want to be a well-paid hero in industry… you could gain some valuable background by becoming our resident noise expert. It doesn’t sound glamorous, but if you can lick RFI problems, you’ll be in demand forever. Trust me, I’ve been there, and whole companies have gone belly-up due to their inability to meet FCC emission specs on an otherwise wonderful new product.

If you want to become the noise czar, see me, and we’ll talk to faculty about making it official. I have a few industry noise experts I can steer you to for background, and you can then establish standards and techniques that will guide the fabrication, packaging, and cabling efforts of everyone else.

Anyway, once the packet link works, I should be able to control the MCS hub processor from anywhere within a couple of miles, hacking FORTH, reading I/O, writing to the LCD, and prowling the multidrop network while swilling a cuppa on some sunny collegiate lawn. Ain’t technology wonderful?

Forth Development Environment

Speaking of FORTH, there has been a bit of progress. I’m no wiz at the language, though I have a little experience, so I’m finding my way around by tinkering. We’ll all be sharing a learning curve on this one…

It’s interesting stuff, FORTH. The language comes with about 300 words in ROM, and programming is a matter of adding new ones, each defined in terms of the old. All parameters and calculations take place on a stack (HP calculator users have a head start here), and new words simply extend the vocabulary. There’s no “program” in the traditional sense of jumping around and calling subroutines. For example, if you want to create a table of squares from 1 to 10, you could create the new word SQUARES as follows:

: SQUARES CR 10 0 DO I I I . * . CR LOOP ;

The colon means that this is a new definition, terminated by the semicolon. As compilation proceeds through the line (which happens as soon as you hit return), the first action is a carriage return, then the loop limit (10) and initial index (0) are pushed onto the stack and immediately inhaled by the DO. I is the index, and each time through the loop it is pushed on the stack three times. The single dot means to print the top of the stack and then delete it. The * multiplies the remaining top two items on the stack, then the following dot prints the result. CR does a carraige return, then it LOOPs until the limit is reached. Voila. The result is:

Squares
0 0
1 1
2 4
3 9
4 16
5 25
6 36
7 49
8 64
9 81
Ok

The really neat thing about this is that SQUARES is now a new word in the language that can be used within anything else — it has just as much validity as any that are built in. If you grew up with traditional procedural languages, this is going to seem a little strange at first, but it is GREAT for hacking around with real-time hardware control… you start with the low-level interface tools and get them working. Only after you have a handle on the relationship between controller and machine do you start adding abstraction. Feedback is immediate, since there’s no edit-compile-download-debug-curse-ROMerase-retry cycle to get in the way of feeling the bits between your toes.

As I mentioned in the last issue, I have very basic tools working for both DOS and Mac environments. I just finished a MicroPhone II script based on some of Mike Perry’s old BEHEMOTH work, so you can maintain files in the Mac and download them to the MCS development system. The LCD driver routines are now such a file, so we can write English or Katakana text on the 2-line by 40-character LCD as well as output to the host machine. Here’s the script, in case you’re curious:

Set Variable * FORTHFILE from File Dialog "'Upload FORTH file?'" Send text string "'^M'" Send File * Text Line by Line "FORTHFILE" Repeat Wait Sixtieths "30" Send Line * Until Failure Send Local to Screen "'FORTH file transfer complete^M'" Send Text String "'^M'"

It’s a bit wordy, but that’s the MicroPhone II script language for ya… at least they make it easy to hack, with all editing menu-driven. The open-loop half-second delay for each line is a bit of a kluge, but there are subtleties in MaxFORTH that make handshaking non-trivial and it was getting late.

Excel Projects

Finally, I’m enjoying some new appreciation of something I have apparently undervalued — spreadsheets. I’ve always vaguely associated them with “business and finance” and used them only for rather pedestrian functions (decision support, logging training rides, tracking journal subscriptions, etc.). But Robb Walker and Scott Poorman are using Excel for the Microship weight analysis, so I finally installed the latest version, sponsored by Microsoft, on the Mac. Quite amazing.

At the moment, Sok Sun Chang is working on some front-end Excel macros and forms that will give us an integrated ship’s inventory system. This will consist of about 30 spreadsheets (databases), one for each major equipment or gear category. For each item listed, there will be a cell for name, description, vendor and contact info, price, serial number, spares, maintenance interval, weight, center of gravity in each axis, stowage area, and notes. The entry process will be automated to the point of shuttling items off to the appropriate file and generating the CG data if a known location is specified by name. The whole thing will generate summary data, interface with the weight and moment calculations needed by Robb, and provide a tool for managing the massive array of STUFF that has to be integrated into this system.

Notes

That’s it for this update. I had planned to include the text of my video system chapter from the control system spec book, but too much else was going on. (I’m hoping to finish that massive document by the end of the year, since it will be the input to much of the design work that lies immediately ahead.) There’s also a lot of “literature received,” but we’ll get to it another day.

By the way, Sok Sun has also put together the basic tools for indexing these status reports, so in time we might actually have this entire archive searchable in some online resource. In the meantime, all the back issues are in hardcopy and electronic form, so bug me if you need more background.

Finally, I might be taking a week to go to Seattle and Victoria in January to pick up the boats, do a sailing show, visit a few people, meet my possible new base manager, and take a much-needed ROAD TRIP!!!

Microship Status 12/29/93

Special Issue: Microship Mission Statement

NOTE: Earlier this week, Robb Walker commented that I’ve never really defined the design objectives and intended uses of this boat. What follows is revision 1 of my response. There have been other developments in the control system and elsewhere, but we’ll keep this short tonight…

Microship Mission Statement

The process of designing and building a complex system calls for consistent philosophical direction, a stable metric by which all decisions must ultimately be guided. This document is an attempt to summarize the design goals and intended application of the vessel.

Basic Objective

I’m entering my second decade of full-time “high-tech nomadness,” which can be defined as open-ended wandering (this time in a primarily aquatic environment) while maintaining a stable home in Cyberspace. Internet and voice communication links must be unbreakable and global, with sufficient bandwidth to allow practical and low-cost continuous travel without adverse impact on the information flow necessary to keep business, publishing, and personal connections active. By implication, this calls for robust on-board power-generation resources, multiple propulsion modes, reliable embedded control systems, redundancy in computing resources, integrated system maintenance tools, a healthy spares inventory, and net connections to tech-support people… as well as traditional life support, navigation, safety, and general sailing equipment.

Constraints

  • Full-time cruising requires significant living space on board and attention to large-scale provisioning — forcing a certain minimum size for reasonable comfort and efficiency.
  • A large, liveable boat sacrifices agility, shoal draft, ability to prowl tiny rivulets, and easy beaching.
  • The logistics of visiting people are complex, since relatively few of my 5,000+ contacts, clients, and sponsors live along navigable waterways.
  • Not all waterways are linked, and traditional boats end up stuck in single river/lake/coastal systems unless trailered between them.
  • Seaworthiness is relative, and a vessel suited to ocean crossings is a far different breed from one intended for coastal waterways and rivers.
  • I cannot assume I will always have a partner. The Microship must accommodate two comfortably, yet be capable of singlehanded operation.
  • Gravity is a factor even on water, despite the lack of hills.
  • Just “taking off in a boat” is too turnkey, too easy, and will not excite media, sponsors, or me.
  • Electronic systems, human relationships, and complex mechanisms are all more likely to fail at sea.
  • Building a boat is expensive.
  • Kayak amas of limited buoyancy impose certain constraints on total weight, sail plan, mast height, and beam.
  • There’s transient glory in using inappropriate tools, but you can tell you’re pushing a new frontier when ALL available tools are inappropriate. (thanks to Dave Berkstresser for that quote, which seems to fit here!)

Microship Design Goals

  • Maximum autonomy in power generation, communications, information processing resources, maintainability, and mobility.
  • Acceptable live-aboard accommodations, although far short of a normal yacht in scope. At a minimum, the Microship must sleep two comfortably, with up to two additional short-term guests in conditions calm enough to permit tent-bivouac on the solar arrays.
  • Self-trailering ability, with deployable or attachable wheels and struts located to yield 10% tongue weight. No logistical support other than a rented tow vehicle should be required.
  • Minimal draft, and a bottom that can withstand careful beaching.
  • Good sailing performance, though not racing scale. Reliability is more important than getting that last .1 knot.
  • Sail, solar, and pedal propulsion (with emergency power from batteries possible). Any power source (sun, wind/hydro, food) must be able to charge the batteries.
  • Singlehanded sailing capability without undue stress on the captain.
  • All resources on board under software control, with very robust distributed control system (including manual backups for critical life-support or safety systems such as lights, bilge pumps, and watermaker). Ship network accessable via remote login.
  • A variety of data communication paths that can be selected on a cost/bandwidth trade-off basis.
  • Detachable paddle- and pedal-powered kayak amas that are readily usable as dinghies, exploration craft, or survival pods. No other dink will be on board. When kayaks are deployed, there must be sufficient center hull stability to remain safely at anchor in moderate conditions.
  • Foldable akas to yield 8′ beam in trailer or compressed-berthing modes. Ideally, the aftmost akas should carry the landing gear assemblies.

Intended Use

The Microship is not intended for extended blue-water cruising, though every effort must be made to create a seaworthy vessel since we cannot anticipate wild ideas that may occur years from now. The basic plan, however, emphasizes coastal travel, rivers, ICW, protected passages, and so on. Unlike a bicycle, I cannot hop off to deal with the countless details of daily life, so the Microship must accommodate cooking, washing, sleeping, and routine repairs as well as the more dramatic operations such as electronic mail, nomadic publishing, live maritime video, and integrated comm/nav. I expect, however, that stops and land interludes will be fairly frequent… the balance of heavy luxury and light agility should thus be tipped in favor of the latter (especially since so much of the weight budget is already dedicated to electronic systems).

— Steven K. Roberts
Nomadic Research Labs

Posted in Microship Status Reports