by Steven K. Roberts
to UCSD Microship Student Project Participants
October 13, 1993

In 1993, I landed at UCSD as adjunct faculty for the first two years of the Microship project… and this detailed “project catalog” was written to attract students to our development team. It was structured as a projects course (ECE-190B), and I took over the microwave lab in the engineering building. It was a very intense time, strongly shaped by this document.

The character above is Mini-Steve. I made this scale model of myself in 1993 to match a cardboard miniature of the trimaran (version 1.0)… then used it to explore usability, access, and ergonomic issues. I never was comfortable with Mr. Template in a CAD system; I prefer physical objects and playing “let’s pretend” with various scenarios. (Besides, this is also part of the CAD system… Cardboard Aided Design!) All the joints and limb segments, as well as overall dimensions, are reasonably accurate representations of my own body at 1/4 linear scale… although of course rather cartoonish.

The Sea Moss Microship is now officially resident here at UCSD and SIO, and one of the major reasons for University interest in this 2-year endeavor is the wide range of coordinated engineering projects that will be necessary to bring the whole system to fruition. For involved students, the Microship will be a rare opportunity to participate in a complex interdisciplinary project using the latest technology, working with industry sponsors while very much in the public eye. By its very nature, this development program integrates a wide range of disciplines into a single piece of work, and understanding the implications of this will go a long way toward preparing you for the complexity of the real engineering world.

We will use the Microship not only as an interdisciplinary project platform but as the focus of an informal series of talks on development engineering, complete with such unavoidable real-world issues as:

  • vendor relations
  • documentation standards
  • critical path management
  • packaging constraints
  • environmental abuse
  • thermal design
  • RFI/EMI
  • communication between systems
  • differences between “business problems” and “technical problems”
  • support after delivery
  • software/hardware integration
  • art and engineering
  • making the jump from wall-staring to CAD
  • the countless details that are never anticipated at startup time

All this will be coordinated as appropriate with involved professors, giving the project continuity with other coursework. I will periodically invite industry partners to visit and share their thoughts. And media spinoffs in the form of trade-journal articles and conference papers will share bylines with involved team members, giving you a head-start on the critical “publications” component of your resume.

Now that the Microship program is underway, it’s time to start defining projects, management issues, and other areas in which assistance will be needed. As you read this, please consider each item in the light of your own academic and career interests… there are some “dream projects” here as well as others that may seem mundane, but all will be integrated into an exciting team effort that will be a source of education, satisfaction, publicity, and fun for everyone concerned.

Breaking the Microship down into projects like this underscores the parallel between this project team idea and “life in industry” — what we have here is a suite of interconnected subsystems, each distinct enough to carry a finite set of specs, yet interrelated in ways that demand full-system awareness during the entire design process. This extends well beyond the control environment to include packaging, inter-process communication, wide-area networking, human interface, power management, maintainability, documentation, and the requisite measure of amusement.

Partly in the latter category, and partly to keep people interested in the project after it sails, we will create a “Mission Control” server here at UCSD, accessible via Internet to anyone interested. Every hour, the Microship will transmit a telemetry block via the best available data path (Qualcomm satellite link, Standard-C, cellular modem, packet radio, AMTOR, RAM Mobile network, or eventually Iridium — depending on conditions), routed via Internet to a fingerable machine on campus. These will be serial numbered and time-stamped, and contain a complete map of data from all slices of the system: navigation, power, data collection, biomed, security, environmental, etc. In addition, there is room for an optional text update, as well as the occasional JPEG still-video frame grabbed from one of four on-board cameras.

The effect here is that people can remotely monitor the performance of the system they helped build, as well as track the Microship geographically. We may even be able to build in some hooks for external code updates via the reverse path… whatever the ultimate details, the Mission Control system will keep us all in touch long after the machine reaches escape velocity. I can imagine new projects built around this — like an expert system to deduce from bio, weather, and other data when the pilot is in trouble… or a way to tweak control algorithms on the fly and gather remote statistical data to assess the effects… or the assessment of municipal environmental impact based upon the rate at which water quality deteriorates as we float downriver…

There are all sorts of interesting potential projects here. Bear in mind also that the whole undertaking will require active management (any budding engineering managers out there who want to be in charge of resource allocation and scheduling?), coordinated documentation (any tech writers and CAD experts?), extensive public relations activity (communications or technical marketing majors?), historical record-keeping (print, photo, and video people?), administrative assistance and gofer tasks (I need help at all levels!), machining, fiberglassing, painting, sanding, wiring, board layout, debugging, field testing… and someone to hold it all together and keep us fed, happy, and organized. So even if none of the jobs defined below sound like something you’re ready to take on, you can still get involved in the Microship in any of a number of very useful ways — if the program sounds interesting, talk to me! We can probably find a place for you.

The project list is sorted into major categories. Notice that the classic artificial distinction between hardware and software is absent at this level — neither can exist meaningfully without the other. Notice also that some of the boundaries are blurry, with functions like communications falling into multiple categories. I must stress that this, like industry, is interdisciplinary — no matter what your avowed academic focus, you will find that it involves a wide range of skills that are not generally considered to be related.

A note on timing. Since we have the luxury of a large team and extensive sponsor support, we will proceed simultaneously on many projects. This is destined to create some confusion and competition for resources, as well as a few “deadly embrace” situations where two groups are stalled, each awaiting a key component from the other. In general, there will be two parallel tracks: mechanical fabrication and electronic system design, with the latter mechanically retrofitted to the former yet partly defined by it up front. This is the first lesson of system engineering… no interesting task is ever trivial.

Finally, I’ve become quite aware of how many projects in the academic environment take the form of theoretical studies and simulations. This one is REAL, folks, and if you get involved you’ll come to know the smells of solder and epoxy, the tedium of wiring followed by the thrill of the smoke test, the satisfaction of precision machining, and the joy of sharing a complex project with a group of intelligent and creative people.

The rest of this document is a reasonably up-to-date collection of projects, clearly-defined component tasks, initial studies required, and other jobs that will help make the Microship a reality. Please also read the project prospectus, which is a more general overview of the whole system…

Embedded Control Systems

The overall control architecture, including graphic front-end processor — probably a diskless Ampro PC/104-standard CPU atop a multidrop network of Microchip PIC RISC controllers. Other possibilities include Echelon Neuron chips for client-server distributed control, networks of 8031/DS5000 chips using the Faddis architecture, or crosspoint networks as on BEHEMOTH. The control environment is the heart of the Microship, and this key team will be involved in virtually every aspect of the system from top-level user interface to RF networking and data collection.

  1. Choose embedded platform
  2. Establish development system
  3. Build host PC and display
  4. Initial test of multidrop or other network architecture
  5. Choose cable/connector standard for net
  6. Begin coordination with various control developers
  7. Microship management software development
  8. External hooks via laptop, packet, and Internet

Power control, solar, and battery manager

This processor models the complete power system, performs load shedding, displays time-to-full/empty, warns of declining battery performance, and integrates with the propulsion system to assign some percentage of incoming power resources to the thrusters. The control algorithm should be sensitive to seasonal and latitude variations, changing assumptions that affect power budgeting. This is a good candidate for an extended project that attempts to fine-tune the algorithm by actively tweaking parameters via Mission Control. Here is an example of multiple disciplines in what appears to be a single narrow area: this involves battery selection and packaging, serviceability, environmental issues, high-current wiring and switching, low-loss regulation, hall-effect current sensors, clever adaptive software, and fault tolerance to the point of continued but degraded function in the event of processor failure. Quintessential EE…

  1. Battery selection and scaling
  2. Fallback charge controller and fail-safe handoff
  3. Hall-effect sensor interface
  4. Battery performance modeling software
  5. Active control of charging process
  6. Integration with PV module profiling system
  7. Work with power distribution group on cabling
  8. Battery charge via pedal input
  9. Hooks to remote net access

Power distribution processor

All loads are FET-switched onto the battery bus under software control, with dedicated local switching regulators instead of a centralized, inefficient, failure-prone power supply. This processor acts as a server for distribution management, turning things on and off as requested and serving up a map of active loads whenever requested.

  1. Fabricate standard FET/regulator boards
  2. 15-V gate-pullup switching supplies
  3. Define standard control format
  4. Careful attention to power-on-reset effects and glitches
  5. Software for distribution map and load management
  6. Crash recovery without creating a power emergency

Propulsion control system

In addition to the sail, there will be solar and human power generation that together provide about 1.2 horsepower for the thruster. This allows generation via the kayak-mounted pedals when there’s no sun, and will let me divert some percentage of solar power to propulsion. The motor will require smart management. There will be about 720 watts of solar panels, yielding some 50 pounds of thrust in full sun — with more available in emergencies by dumping main batteries.

  1. Hi-rel JATO-mode switching technique
  2. Speed controller with software hooks and manual override
  3. Code to devote x% of solar input to thrust

Internal data collection system

This not only collects, displays, and transmits to Mission Control, but also acts as a server on the control network for measurements needed elsewhere (redundancy should be provided here considering the central nature of this task). Air/water/bay temps, enclosure pressure, wx data, trim, depth soundings, water in bilge, etc. Note that the Microchip PICs are so simple and cheap that this may break down into a number of smaller projects, perfect for those just beginning to deal with microcomputer interfacing. Such an approach adds fault tolerance as well.

  1. Equipment bay pressure sensors and hooks to pump control
  2. Pneumatic system humidity and seawater incursion
  3. Temperature sensors
  4. Bilge pump activity and standing water sensors
  5. Holding tank level sensor
  6. Water-processing system measurements
  7. Hooks to NMEA 0183 marine instruments
  8. Software for reporting, condition polling, and alarms
  9. Direct hooks to packet and external probes

Environmental data collection

An interesting Microship application, more for education than for hard science (given the randomness of my route), is a data collection module that profiles various environmental observations as a function of lat-long, time, and weather. I have a small radiation monitor already, and probes will be added for pH, salinity, presence of easily detected pollutants, average EMI, CO, turbidity, water temp, and so on. This should yield an interesting tie-in with environmental studies, not to mention the engineering aspects of the data collection itself and the spinoff potential of a standalone, packet-linked environmental monitoring module (NSF and TERC have already expressed interest in helping support this part of the project). Besides, it would be most amusing to see a bump in radiation and temperature curves as I slowly cruise past a nuclear power plant…

  1. radiation monitor (pulse output) interface
  2. water-quality sensors, possibly a single integrated unit
  3. temperature sensors
  4. report format and polling protocol
  5. hooks to GPS for offline archiving of snapshots

Communication system manager

Virtual front panels for the radio gear, PTT steering, antenna switching, MAYDAY generation (panic button). Marine VHF, EPIRB, SSB, ham radio, etc. Much of this will involve remote packaging of the comm gear with hacked front panels and software control from an console processor task — this minimizes console clutter and operational complexity. However, reliability in life-threatening situations requires at least a backup Marine VHF and EPIRB that are in no way hacked or integrated with a potentially inoperative system.

  1. CI-V interface for Icom, or hooks to fiber-linked panel (HF)
  2. Control hack for Marine VHF radio
  3. Ham station manager
  4. Front-end software for panel emulation & automatic control
  5. CW keyer
  6. Multimode and low-power TNC interfaces

Security system

Depending on the environment, this will take care of tamper-detection, paging, and so on. This unit will call the police via cellular and issue alerts via satellite and marine radio if it becomes convinced that the system is being stolen or damaged. It will interact with the comm system manager, as well as data collection and isolated subsystems (hey… since we’re on the water, this is true pier-to-pier networking…) — it should not depend on the high-level control hub for this extremely critical function.

  1. Determine motion filter function to ignore water/wind effects
  2. Package and interface microwave proximity sensor
  3. Hatch and bulkhead violation sensors
  4. Independent hooks to celphone, GPS, synth, and comm gear
  5. Status sentence format for remote polling
  6. Write response matrix code in the MCS manager

Packet monitoring system

A new hardware unit from TAPR allows easy data collection and control via a packet radio link — we’ll use this as a back door into the control system to allow remote access for security status, event summaries, power monitoring, and any other potential problems…. all via the backpack laptop and a tiny TNC/radio combination.

  1. Acquire and test hardware via packet (hams required for this)
  2. Write control net software to allow unattended ops
  3. Remote power-control and status access (surrogate host mode)

MCS (Microship Control System) display manager

Reliability and resource conservation dictate that high-level power-hungry disk-based systems not be in the loop for continuous control/monitoring tasks. The console display of essential info is thus handled via a dedicated LCD and this processor, which polls the net to update a display map. The choice of processor here is critical — we will probably use the new PC/104 industrial control standard pioneered by Ampro to accommodate robust off-the-shelf tools.

  1. Choose low-power LCD and driver
  2. Choose level of PC/104 standard PC (286, 386, or 486)
  3. Select development tools and front-end environment
  4. Write polling software to graphicaly present system status
  5. User-interface tools Network hooks to Mac and PC for file backup and comm tools
  6. Hi-rel RAMdisk or Flash (PCMCIA?)
  7. Packaging in console
  8. Interface with mouse and waterproof keyboard (shared)
  9. Back door hook for packet/Internet access
  10. Special front-end code as needed for each low-level controller

Audio crosspoint server

A component with product potential, this is a dedicated micro to control the audio network matrix originally developed for the bike. This needs some ground-loop and analog refinement, as well as some very clean software that will let the entire audio network appear as a server to the control network (allowing software to establish virtual links between any audio devices on the boat).

  1. Bring up an 8816 board; perform noise analysis & distortion tests
  2. Write drivers and connection tools (FORTH on bike available)
  3. Integrate with audio devices

Video turret controller

This will steer and zoom the on-deck video camera under software control. This system may also run a video source switch analogous to the audio crosspoint, responding to requests from the high-level machines.

  1. Work with mechanical group to select control structure
  2. Video switch software

Biomedical telemetry

We want to monitor potential human failure modes… if this is realistic without invasive hardware.

  1. Investigate possibilities before launching this one

High-level Systems and Applications

Macintosh

The primary working environment will be a Mac PowerBook, probably the 180C with color active-matrix screen. This needs to be packaged, fed with synthesized ADB console devices, linked to serial crosspoint and network interfaces, and provided with power management.

  1. Physical repackaging in sealed console enclosure
  2. Mouse interface from DOS-intended or custom FSR pointer
  3. Keyboard ADB hack (again, hardware designed for DOS)
  4. Network hooks to other console Mac and RF to laptop
  5. Replacement of normal battery/charger with system power
  6. Installation of general software tools
  7. Hooks to Internet, Satcom driver, other email tools
  8. Backup tape or file server in equipment bay; CDROM drive

Navigation system manager

This integrates GPS receiver, flux-gate compass, waypoints, chart display, etc. The NMEA 0183 bus will be connected to one of the high-level systems (probably the 486, keeping the Mac free for personal productivity, writing, and email). The nav system will integrate live charting with the contact database while providing the full suite of tools needed at the helm of a well-equipped cruising yacht (including support for celestial nav).

  1. Repackaging of 486
  2. NMEA interface
  3. Select and acquire nav/charting/marine software
  4. Network to Mac
  5. OrCAD and/or other DOS CAD tools
  6. Power management
  7. Integration of KB and Mouse with Mac group

Inter-boat and boat-manpack RF networking

The Mac on the console will be in constant data communication (AppleTalk) with companion craft, the copilot console, and the manpack laptop. A recent visit to Digital Ocean has suggested that their spread-spectrum “Grouper” product is ideal for this. We need to consider antenna issues as well as integration with a hardwired net. This is an area with extensive industry spinoff potential — wireless data is a very hot field.

  1. Acquire Digital Ocean equipment and test
  2. Integrate with wired net to other Mac
  3. Establish simple protocol for other boats
  4. Gateway software to make Microship email hub

Human interface issues

Chord and waterproof QWERTY keyboard, macro expansion tool for the Mac, cursor control (probably InterLink force-sensing resistor based), speech, and hardware/software solutions for seamlessly sharing these resources among the three high-level systems.

  1. Compare InterLink DuraPoint with FSR XYZ custom unit
  2. Write ADB driver for above (whichever wins)
  3. Make (Paravant?) sealed kbd interface switchable Mac-DOS-DOS
  4. Explore speech input options
  5. Integrate Audapter (or?) with MCS hub and xbars
  6. Software front-end for MCS display manager

Video and conferencing system

Frame-grabber, compression, control of on-board cameras and other sources, transmission of stills via cellular and satellite email, motion using Colby and other compression schemes, multimedia applications on-board, CuSeeME conferencing via the Net, and more.

  1. Track down Cohu or similar small cameras
  2. Investigate available frame-grabbers
  3. Choose video platform
  4. Talk with Colby re support for compression
  5. Try CuSeeME via cellular
  6. Define and integrate video sources/sinks via crosspoint switch
  7. Software for inclusion of JPEG images with hourly postings

Geographic Information System

This will be integrated with database and GPS, built around GeoQuery. Currently we need Mac drivers for the GPS to automate map centering around the ship’s current location, and the software is not yet tested with commercially available machine-readable charts (only the internal road and state/county boundary maps). All database entries are geocoded and presented in graphic context.

  1. Get GeoQuery and ComGrafix together
  2. GPS data into Mac
  3. Select Mac/Dos platform for CD-based charts (or cartridge?)
  4. Investigate putting CD chart lib at MC sys and downloading
  5. Integration of chart data with radar/nav (commercial software)
  6. Build auxiliary databases from EYP and elsewhere; update code

Multimedia demonstration package

We need a way to integrate everything into a demonstration, considering how often this will be on stage or in the media. Speech, graphics, active control of systems, and so on…

  1. Managers: assure up front that hooks exist for this

On-board CAD tools

System maintenance underway should be facilitated by a hierarchical file structure, accessible graphically, for all mechanical structures, electronic systems, pneumatics, water processing, sail controls, and so on. This should be designed up front to fall directly out of the project development tools.

Networking and Support Systems

The Mission Control system (map display, telemetry decode & distribution, mail hub, alarms). This might run on a SPARC, with fleshed out (human-readable and abstracted) data fingerable and appended to an ftp server in a variety of formats that support tabular download, geographic plotting, and trend analysis. It should be possible for anyone on the Net to finger this machine and receive a complete snapshot of Microship activity, including lat-long, heading, speed, depth, weather, time, air/water temps, radiation, salinity, turbidity, pH, solar performance, battery level, propulsion level, water system levels, security status, recent statistics, brief commentary, and so on.

  1. Establish hourly report format (work with NSF/TERC)
  2. Code to archive in useful form (chartable)
  3. Franklin Antonio re mapping (QTRACS)
  4. Converters as necessry for image formats
  5. Login shell for remote system maintenance and diagnostics

Satellite Internet link

I’m working closely with Qualcomm, an active sponsor, on this part. Issues yet to be decided include antenna packaging (microwave attenuation through fiberglass is apparently not too severe, and mounting below a deck bubble will minimize seawater damage), polarization tricks at the limits of the footprint, and smooth integration with on-board and Mission Control systems. We have already developed the code for BEHEMOTH to support Eudora on the front end and a SPARC task on the back end, effectively yielding a seamless email path anywhere in North America, Europe, the Pacific Rim, or Australia. This team should also study Standard-C satellite service and stay alert to the implications of the upcoming Iridium system.

  1. Select between two models of OmniTRACS
  2. Full test of MCTtool in the Mac
  3. Physical packaging of terminal and antenna units
  4. Study possible need for gimballing (hopefully avoided) — test!
  5. Write SPARC code to “throw switch” between sat and phone path
  6. Email filter
  7. Connect with wireless networking community re future

Cellular phone

The phone itself, Axcell, modems, and so on — This might fold into comm systems and networking, but the industry is heating up in its quest for people literate in wireless networking. Cellular phone integration and interfacing.

  1. Choose phone/modem combo (Motorola UDS or Axcell-supported)
  2. Talk to Qualcomm re dual-mode CDMA/analog unit
  3. Study new cellular data options… changing fast
  4. Physical repackaging of phone, interface hooks to net, antenna

Fabrication, Mechanical Design, and Packaging

The video turret

This is a waterproof glass dome on the deck, housing a video camera that can be steered and zoomed under software control. Perhaps night-vision can be integrated with this… Study existing commercial systems (oceanographic)

  1. Find outer envelope, sealed
  2. Choose camera, interfaceable
  3. Code for camera control
  4. Apps software (security, documentation, vessel ID)

Equipment packaging and environmental protection

Pressurized equipment bays (with dryer), connector choices, sealed boards, sensors for salt/water incursion, pressure drop, excessive temp rise, shock, and more. This group will be responsible for the air-handling system, valves, sealing protocols, connector choices, and more — coordinating other packaging teams to maintain consistency in this extremely critical area. Consulting is available from Scripps Institiution of Oceanography, MBARI, and some of the industry sponsors.

  1. Select pump, filter, desiccant, valves, and tubing/fitting standard
  2. Test system for cleanability if loaded with salt water
  3. Pressure sensors for each enclosure, ref to ambient
  4. Control software for pump and alarms (see controls, above)
  5. Temp, shock, door ajar, and other package monitors
  6. Set standards for connectors, bulkead fittings, sealing protocols

Hull design and stress analysis

Work with Nelson/Marek yacht design and our epoxy/composites sponsors to optimize hull shape, accommodate the cross-beam and landing gear stresses, and implement using the appropriate fabrication technique (probably either cylinder molding with compounded ply or the more traditional strip composite construction that accommodates more complex hull shapes). Finite-element analysis of complete structure.

  1. Express complete design in AutoCAD
  2. Pass CAD files and material specs to FEA group
  3. Choose fabrication method
  4. Set up vacuum-bagging facility
  5. Strong-back jig and station templates from N/M design data
  6. Stress analysis of bulkhead-area forces (wheels and akas)
  7. Design akas as sealed beams for flotation and strength
  8. Determine whether commercial double kayaks adequate
  9. Design bulkheads and internal structure
  10. Build hull(s) -> Cable routing and deck fixtures

Road mode

The Microship will contain integral trailering capability, with fold-down wheels from the bulkhead stations and a bolt-on hitch for the bowsprit. The stresses will be enormous, and up-front design must consider the shock amplitudes and frequencies encountered on the highway, point-loading stresses, suspension design, and more.

  1. Study laws and standards covering trailer design
  2. Implications of four widely-spaced wheels during turning
  3. Choose wheels and detachable hitch
  4. Trailing-arm suspension design, retractable
  5. Work with hull stress-analysis group
  6. Nacelle covers to minimize turbulence and friction
  7. Hull and panel nesting for secure road transport
  8. Testing

Aka deployment

The outriggers and associated solar arrays must retract to yield a maximum 8-foot beam in compressed mode, yet accommodate the severe heeling stress at the aka-vaka joint. The general F-27-style folding concept is established, but we need materials selection, mechanical design of the linkages, automated retraction, over-center hysteresis, stress analysis around the receivers, and detachable kayak hardware design.

  1. Model linkage assy and subject to testing stress
  2. Determine retraction via lines; select lock-downs and hardware
  3. What detachable connection to the amas?
  4. Design beams, with accommodation of solar arrays
  5. What dihedral? Adjustable?
  6. Build it!

Solar panel packaging

This is most likely on NidaCore polypropylene honeycomb substrates with grab rails, non-skid perimeter, center-folding design with suitably scaled web. We need thermal analysis of expansion coefficients that may stress the panels-substrate interface, cable routing between Tedlar PV sandwich and substrate, connector choices, electrical configuration, half-power operation when rafted, calculation of allowable solar cell deflection to determine required substrate thickness under worst-case impact loads, and so on.

  1. Calculate substrate thickness and acquire
  2. Design web, hinging, stowage scheme, and cable routing
  3. Do the layup, designing in serviceability
  4. Electrical tests (including individual panel profiling)
  5. Integration with beam assemblies & mechanical tests

Hull fabrication

Automatic sand-mold generation from CAD for complex shapes (such as cowlings), working with Dave Berkstresser and Autodesk as first users of this new technique now under development.

  1. Choose test project and talk to Dave…

Marine, Nautical, and Safety Issues

Radar

This project includes display repackaging, antenna placement, interface with the GPS server, and possible export of video to the Mac or PC for charting overlay and export to Mission Control.

  1. Find out if Furuno radar video is exportable
  2. Physical repackaging for console
  3. Integrate with NMEA data stream
  4. Extract radar images
  5. Study microwave exposure and optimum mounting site

Waterworks

Desalinator and water manager, including sensors for levels, salinity, etc. Alert user to imminent failures. This includes the head cooling heat exchanger as on BEHEMOTH, with a working fluid sealed in the system and thermally coupled through the hull to ambient seawater. Backup desalination to augment the reverse osmosis system will require fabrication of a solar still.

  1. Acquire R-O system and integrate with tanks & through-hull
  2. Head cooling system and performance analysis
  3. Instrument complete water system
  4. Build solar still

Naval Architecture

Sail design, computer modeling of trimaran balance and performance, placement of appendages, rudder design, seaworthiness, trim calculations, rigging, hydrodynamics, possible front-rudder for fast-tacking and CLR-tuning, thruster placement, and more. All this will be in cooperation with our sponsors, Nelson/Marek yacht design (who did the Stars and Stripes catamaran) and Sobstad Sails.

  1. Research alternative sails including rotors, wings, and foils

Thruster

We need to figure out cavitation issues, depth, prop dimensions and shape, rudder integration, speed, and mechanical deployment by remote control from the helm. The plan is to have two thrusters, one at the stern of each kayak outrigger, allowing a high degree of maneuverability as well as individual kayak propulsion via pedals.

  1. Thruster selection
  2. Mechanical mounting and deployment
  3. Controller software
  4. JATO-override (work with controls group)
  5. Steering and rudder integration
  6. Kayak pedal system

Miscellaneous Subsystems, Gizmology, and pure EE

RFI/EMI reduction

The industry is desperate for experts in this field, and since computers and radios are mortal enemies by nature we can assume that it will be… well, interesting. This group will work with all controls and comm groups.

  1. Participate in cabling design
  2. Enclosure specs and EMI suppression
  3. PSD plots of noise leakage in all modes
  4. RF hot-spot minimization when transmitting

Antenna farm

Not just the skyhooks, but grounding, tuning, and performance analysis. This will be extremely challenging on a small craft. Copper mesh will be glassed into the hull as counterpoise coupling to the water… is this enough? How do the antennas interact, and what happens when the mast is down?

  1. Hull mesh design and cabling
  2. Lightning protection
  3. HF dipole, vertical, or backstay sloper?
  4. Placement of VHF, UHF, cellular, differential, and other antennas
  5. SWR and radiation pattern analysis in all modes
  6. Deployable cellular, VHF, and UHF yagis

Diagnostic Toolset

DPM, status bit multiplexer, coordination of test points, external network hooks, self-test facilities, and more. While testability is the responsibility of each control system group, centralized tools will require a separate project to ensure uniformity and consideration during cable harness design. This includes working with the power management group to map the 24 individual solar panel outputs to predict impending failure of any unit in the array.

  1. Design a self-scanning analog mux for DPM power monitor
  2. Clone the bike’s LED matrix bit-scanner
  3. Specify scope points to other groups
  4. Solar array mapping system
  5. Test loops in connectors for configuration self-check

Cable Harness

Far from being a boring passive component, this is the critical interconnect matrix for the entire craft. In this harsh environment, proper connector and wire choices will make the difference between success and failure of the whole system. We’ll have help from Scripps and MBARI, as well as a new sponsor that specializes in military cabling.

  1. Low-loss power distribution from solar array
  2. Battery bus standard
  3. Audio distribution standard
  4. Waterproof connectors
  5. RF shielding and crosstalk minimization
  6. Coaxial cable choices
  7. Through-bulkhead techniques
  8. Diagnostic hooks
  9. Multiplexing and fiber if appropriate

LED lighting system

As on BEHEMOTH, we’ll use high-brightness LED clusters everywhere except where white light is required. Properly potted with internal switching supplies, these have strong product potential in the marine marketplace, drawing 1/6 the power of standard products.

  1. Determine legal lighting requirements
  2. Design integrated bi-color and mono-color lights; pot clear
  3. Red LED lighting in chart table and console
  4. Spot and flood lights

Support Tasks, Logistics, and Management

Microship Project Partner

This is a big one. It has become quite clear that even with extensive engineering help and base-office management, I need a full-time project partner. This may be the person who occupies the ship’s crew module as well… so if you yearn for high-tech adventure, have extensive business experience, deal well with the media, express yourself clearly, feel comfortable living on the Net, and are free to devote the bulk of your time to a large-scale project (expenses paid), please contact me.

Engineering Management Team

A critical function during this development effort will be active, hands-on management of a large number of simultaneous projects. I am assembling a management team of three people, one each from ECE, ME, and CS — they will participate in ALL the projects to ensure consistency, good progress, availability of resources, inter-group communication, and access to help when needed. This group will provide me with frequent updates and alerts, and also help produce the more-or-less-daily project status report emailed to all participants and active sponsors. Industry is desperate for people who can manage projects WELL, and are not just MBA’s plopped atop an engineering group. If you’re on your way to an engineering management career path, talk with me about this.

Project Archive Management

Much of the support for these technomadic projects can be traced to an active program of publishing technical details… essentially sharing all the intellectual property related to the system in exchange for product donations, the assistance of wizards, and continuing media interest. This is fine, but the flip side is the time involved… I could easily spend all my time writing and none doing engineering. The project needs an archivist to handle video, still photographs for publication, status reports from workgroups, the CAD documentation binder, and help with monthly columns and other published material. This person or group has to be literate, precise, and willing to meet hard deadlines.

FTP and Listserv Maintenance

Closely related to the foregoing, this involves keeping the electronic archives and mailing lists current. Nearly 10,000 people receive project updates via the Internet, and in my chronic state of overload, reports are far less timely than they should be. While they should still carry my writing style, some help with organization, deadline reminders, list updates, and ftp site maintenance would be extremely useful.

Database Maintenance

Help keep up with databases of contacts, sponsors, resources, and ship inventory. This includes batch geocoding of all addresses to allow integration with GeoQuery. There will also be a file of all on-board components, detailing weight, VCG, LCG, cost, spares, vendor, and so on — we need someone to manage these files and make sure they are well backed up.

Administrative and Support Tasks

We need a lot of help in this area: photocopies, errands, document generation, filing, sending for literature, purchasing, and general office management. If you’re heading for a career in administration, this will give you good experience (and I’m willing to pay for help with a few particularly boring tasks that nobody in their right mind should volunteer to do for free!).

Most of the projects can be developed by small teams, or in some cases individuals. Yet they are all connected, which enforces system awareness and standardization of protocols, uniform packaging, consistent documentation, and so on. This is very good discipline for the engineering profession in general. Despite the serious aspects, however, we must never forget the constant undercurrent of fun… which is, after all, the bottom line. Also, this is largely supported by sponsors, so there will be some very interesting new toys for us to play with (OK, I confess: this is part of the addiction that has kept my high-tech nomadness alive for ten years).

I look forward to your comments and suggestions on any aspect of this. And again, remember that the project needs help at all levels… before this is over, we’ll have a spirited team of dozens, earnestly working to get me out of town. Please contact me with your interests!

Thanks and cheers,
Steven K. Roberts

Posted in Microship and tagged