by Steven K. Roberts
April 2, 1994
It’s been a hell of a week. My new manager de-materialized before she fully materialized, someone who needs to be severely spanked scratched the face of my new Sharp active-matrix color LCD, and our neighbor in Seaweed Canyon pushed over a giant storage shelving unit in my bay and partially destroyed one of the new custom boats. The damage was serious, with bad rips in both hull and deck sections and over a foot of keel fractured. I have yet to find the person who’s going to get the repair bill, but I’m working on it; in the meantime, we’re looking at a significant fabrication setback and permanent aesthetic impact (unless the current downsizing effort induces us to change to single kayaks instead of the current Libra doubles, which is a distinct possibility).
Whatever the case, this is going to cost…
The Microship is again micro. I was beginning to spell it Macroship, but we caught it before it became a megayacht — now much of the original kayak-scale thinking is again driving the design. There’s a real synergy afoot: a smaller boat takes less power, making solar and human energy more effective, reducing required sail area, and further lightening the overall structure. I’ve been studying back issues of Human Power and HPV News, sketching sleek little boats, and ferociously tightening all of the specs.
(NOTE TO PROJECT TEAMS: All components of the ship must be as light as possible. This means careful attention to strength-to-weight ratios, drilling out unnecessary material, choosing wire sizes appropriately, eliminating redundancy except where safety is at stake, and otherwise thinking in terms of absolute weight minimization. Little things add up…)
To give you an idea of the scope of the recent changes, I’ll summarize my meeting with Scott Poorman yesterday morning: we went over the weight-study spreadsheet, considering each item in the context of kayaking and camping (not yachting and living aboard), and managed to cut the bottom line from nearly 4,500 pounds to about 1,500 — including two humans!
This still includes 80 square feet of solar panels, a sample of which is now in the lab. The new study assumes Current Designs “Expedition” kayaks, lightweight folding crossbeams, and a 20-22-foot center hull about 3 feet wide. This will be low, accommodating the pilot in a cockpit enclosure that wraps display and console real estate around the pedaling envelope. The kayaks will be kept simple — no pedal drive or additional hardware beyond the additional stucture required to support demountable crossbeam attachments. A second cockpit can support a companion, without computer equipment but with pedals. Sail controls, now much simplified, will simply consist of lines and cleats, and steering is a set of levers driving the rudder via cables (with a turn around a drive wheel for autopilot and position encoder).
On-water bivouac is expected to be limited to relatively mild conditions whenever possible. In this case, a pair of rectangular dome tents can be erected on the solar arrays, linked by a “hallway” that covers the cockpit area. Under windy or rough conditions, if a landing is impossible, the pedals must be removable to allow sliding down into the hull with a camping mattress — not luxurious, but survivable.
The electronics enclosure, once a pair of 6-by-3-foot rackmount cabinets in a narrow cabin below deck, is now a flat, easily accessible pressurized bay atop the center hull segment. This will unfold for access, greatly simplifying service while eliminating over 100 pounds of structure.
The head, an unfortunate necessity for environmental, biological, and legal reasons, will probably be the smallest available porta-pottie located in the forward hull segment. On-board water processing will be minimal, with a maximum of 5 gallons of tankage.
A lot of this will sound familiar to long-time readers of these reports. You may recall that this whole thing started as a kayak, became a kayak-catamaran upon my realization that I couldn’t move around on a single, evolved to a tri after more study about stability, then ballooned into a kayacht when I started thinking too much about my long list of required on-board functions. The equipment list was growing completely unconstrained, with the BEHEMOTH Effect very much in evidence — even though the actual liveability of the design was questionable in a 30-footer with only one narrow aft cabin.
Robb Walker has the new weight study and is thinking about a design with minimal sail plan. We need to converge quickly on some essential dimensions, now that one of the project teams is working on the folding crossbeam assembly… if we play this right, we should be able to start center-hull fabrication in a couple of months.
Control Network Consolidation
In keeping with all this, I’ve taken a hard look at the control system specification which has been defined as 16 FORTH nodes on a multidrop bus, a Hub, two Macs, two PCs, and a SPARC — plus an RF-linked manpack PowerBook and random embedded controllers. Many of the nodes were VERY lightly loaded, and achieved node-hood on the basis of conceptual simplicity or I/O convenience.
The new version is now emerging, and it takes advantage of the FORTH multitasker to allow essentially the same set of software functions in far fewer processors. Bear in mind that this doesn’t just reduce the number of 4-ounce NMI 68HC11 boards, but also the space and weight of the structure on which they’re mounted, the requisite cabling, and the hardware documentation complexity.
The dedicated L-Solar and R-Solar processors have been folded into the Battery management processor, as have Port-ama and Stbd-ama (which were primarily involved in thruster control). One central power controller thus replaces five processors that had to coordinate through inter-node mail. Similarly, the Fore, Midship, and Aft processors are now one, although I’m not rejecting the possibility of having a processor in the crew module if local functions would justify the cabling-reduction of a nearby node. The dedicated Distrib processor for power distribution turns out to be quite unnecessary, for the other boards can trivially switch FETs to handle power control as directed by the Hub or upstream user-interface systems. That amounts to 7 fewer machines that have to be mounted, powered, interfaced, and maintained. Of course, the complexity of the others increases, but the overhead reduction is a net win by a wide margin.
At the high end, the new configuration is not fully defined, but may well be reduced to the Ampro PC for dedicated graphic ship control, a Mac for my home working environment, and MAYBE a dedicated chart/nav system (which is actually somewhat redundant, especially if we can get two LCDs on one of the new PowerMacs). I’ll still need a manpack computer, possibly a Duo or something else small and light.
The good news is that none of this affects work already completed, except that some of the FORTH code needs to be moved from foreground into tasks to allow additional code to operate without mutual interference.
Spring Project Summaries (preliminary)
Much of the work in this past week was the definition of new project teams. With the disclaimer that this is still in a state of flux, here are the seven projects that will be underway during the next 2.5 months. In a future report I’ll tell you who’s doing what and begin reporting on details…
- POWER MANAGEMENT: This 4-person team will handle battery charge control, solar module performance analysis, motor-generator control, and power budget monitoring. This is a central, critical task on the Microship, and includes an algorithm that deduces from power budget and available solar input what operating range is mapped onto the throttle control (which can be overridden to full power in emergencies). I’m investigating industrial NiCads now.
- AUTOPILOT: Two people will be working on taking input from GPS and compass, as well as navigation information from the host system, and controlling the rudder. This may involve some fuzzy logic control in order to incorporate accelerometer data in the attempt to override the deleterious effects of certain sea states on traditional autopilot algorithms. Attention will also be paid to deadband and damping issues to minimize electrical power waste, and the design may incorporate a trim tab on the rudder instead of the more demanding tiller control.
- HOST INTERFACE: The Hub team from last quarter is back, and will be working with one new person to create the initial toolset that allows a graphic front end to map onto a complex library of FORTH commands. We’re working to define a set of “views” of ship subsystems that will comprise the whole user interface to the Microship.
- PACKET DATACOMM: A two-person team will integrate both business-band and amateur packet radio into the ship’s control structure, allowing remote login and control/observation of everything on board. This requires connect detection, user validation, path routing through the network, power control, and error recovery… and will yield considerable security and diagnostic functionality. The cellular modem should drop into this same system.
- SHIP MANAGEMENT: Two people will be working on data collection and security. This began as bilge-pump management, but reliability issues dictated leaving them autonomous with software error and duty-cycle detection. Related ship monitoring issues include security sensors, hatch status, bay temperatures, and so on. This processor (the amalgam of Fore, Mid, and Aft noted above) will become the “Watch” machine that is constantly scanning for potential intruders, leaks, fire, open interlocks, bad crossbeam modes, or other problems.
- VIDEO TURRET: A 4-person team (three from Mechanical Engineering, one from ECE), will build a sealed, pressurized cylindrical acrylic turret, containing a color video camera with azimuth drive motor and platform-position feedback. This will be mounted on the bow for general video applications — as well as automatic control in the event of a security breach.
- CROSSBEAM ASSEMBLIES: Three mechanical engineering students are working on the critical 4-bar “aka” structure, which includes the retraction design, the composite box-section beams themselves, and the demountable kayak interface. This will also accommodate later design of the landing gear assemblies, which are expected to interface with the aft beams.
With such a diverse collection of projects (unlike last quarter’s overlap among the three crossbar matrix groups), this will be a very busy and challenging ten weeks!
Finally, I’ll close this longish update with a few help requests for local folk.
- NEW MOCKUP: I’m tearing apart the giant mockup that’s been in the lab for a few months, since the ship has changed. We need a new one that is tightly wrapped around a recumbent pedaling position, and we’ll need pedals and a seat, an external frame, and lots of clever cardboard-aided design (CAD). Anyone want to participate?
- BLACKBOARD MOUNTING: The lab blackboard is not earthquake-proof — whoever stuck it to the wall was unclear on the concept. After the horror of discovering the kayak damage, I don’t want BEHEMOTH to take a hit in a temblor. About an hour’s work, this.
- KAYAK CRADLES: This is not quite well defined since the boats may change, but I’ve purchased some sawhorse brackets and want to make a couple of workstands.
- FLOTATION BAG LEAK: The trainer kayak has a leaking flotation bag, and it needs to be inflated and submerged to find the bubbles, then patched.
- MINI SOLAR STILL: Dan Perry aqcuired the hardware for a now-oversized solar still, including $40 worth of heavy teak that we should return. I want to investigate the feasibility of shrinking it to a size that is realistic for the smaller boat, then do it.
- PARTS INVENTORY: I need to spend a few hours with someone getting the lab IC and small-parts inventory into shape.
- SECURITY SENSORS: There have been some false alarms from the lab security system (Radio Shack, of course). I’d like to move to door sensors from the existing infrared and ultrasonic, then add a couple of features to the response hardware.
That’s it! Cheers from another gray day in coastal fog….