New Control System Projects
You haven’t seen one of these reports for a while, have you? (Some of you — the new UCSD Microship engineering team — have NEVER seen one.) Well, between June ’93 and April ’94, I put out over half a megabyte of these project updates. Somewhere last spring, I got out of the habit of posting these little quickies, so the audit trail of the project was interrupted.
Microship Status, Issue #78
Steven K. Roberts
San Diego, California
January 19, 1995
Well, I’m happy to say I’m at it again. The VERY short summary of activities between then and now is that I bought a Fulmar-19 trimaran, spent a few months realigning the whole Microship project concept to that tiny platform, met Faun, integrated a basic test system (power management, GPS, security, and Marine VHF), packaged camping and nautical gear, hauled the boat to Seattle, borrowed another Fulmar for Faun, spent 2 very exciting weeks on the water, decided the Fulmar is too small to be practical for extended travel, left it in Seattle for sale, drove back to San Diego, did a 7,500-mile speaking tour with BEHEMOTH and Faun via diesel truck, and returned again to UCSD to dive full time into system development over the next two quarters. We now have a promising team of 12 sharp engineering students, and are hard at it with the assumption that the entire lab will be moving (I won’t say where because I’m not yet sure) by early summer and these may be the last two quarters of project teams.
And, since every boat needs something under it to float it (does that make sense?), we’re looking closely at the Stiletto 27 catamaran… but more on that in another issue.
New Control System Projects
Things are hopping, with a whole new front-end to the control system (we’re doing it all in HyperTalk on the Macintosh now… it is infinitely more pleasant than Turbo C++ on the DOS machine), and a new and improved role for the Hub. I’m working on the Mac and helping all the teams with hardware, and Faun has just finished our 1994 accounting on Quicken and is getting into FORTH, desktop publishing, and database management.
The Macintosh Front End
(Steve Roberts with help from the Hub team)
This is a true delight. It took me about 3 days to create a lovely front-end for the Audio Crossbar (AuXBAR), complete with icons representing all the audio ins and outs of the ship. The individual handlers are trivially simple, and they use an XFCN called CommConnect to interact with the Hub via the Comm Toolbox. This contrasts with a 6-month project to accomplish the same thing with DOS, and it has more features. It will be possible, for example, to set up a suite of up to 8 connections, then save it as a named “macro” for instant use later. This front end does not interfere with on the fly audio links created by other applications, of course; the <Audio Matrix> view will report on all current connections.
Both consoles (Faun’s and mine) are now Macs, as are the two manpack laptops. They will all be on AppleTalk (wired or wireless, depending), and any Mac can take the helm by simply executing the same HyperCard stack and routing its serial port through the network (now controlled by the Hub for greater simplicity). This feels a lot better…
The architecture is very structured: Microship operation is sliced into 25-30 “views,” each of which is a single card in the stack, each presenting some conceptual slice of the system no matter how many physical nodes are involved. The Hub interacts with the view, rerouting messages or returning local copies of node variables as appropriate. If the Mac is off doing something else (like running the nav/charting package called MaxSea, word processing, or just in the neighboring MacNavigator stack of nav tools), the Hub will buffer any messages that need service — alerting me in an emergency via audible signal and a small local LCD.
The Hub
(James Batti, Harrison Li)
The Hub now has a more robust role that we defined last year, along with much more I/O than before. This and all nodes are still New Micros 68HC11 FORTH boards, which are working reliably and provide a very flexible platform for building a distributed network.
As I mentioned above, we’re moving the Serial Crossbar (SeXBAR) to the Hub, partly because it really doesn’t need a dedicated node, and partly because it will be involved in rerouting the Hub’s own console… we don’t want a deadly embrace here! We’re also adding 64 bits each of parallel input and output, and a second serial port (which is just an address on the SeXBAR). The Hub’s MAIN task remains the FORTH interpreter, and talks with the Mac; other tasks are responsible for Manpack wireless logins, security and watch functions, background updating of all sensor variables, and keeping an eye on the watchdog tasks in all nodes. If a node dies, the Hub is empowered to restart it, cold start and reload the board, or physically reset the entire network if necessary. (Reloads call for the help of the Mac as a file server, but it’s all in the background as far as I’m concerned… except for a time-stamped status report on the <Hub Messages> view in HyperCard.)
Much of that added I/O will take care of power management, local console sensors, load shedding, the DTMF transceiver described below, and localizing some of the security hardware to allow a more effective power-saving shutdown mode.
Manpack
(Filippo Loddo, Larry Conly, Chad Neale)
This is a fun project, and will go a long way toward adding functionality to the whole system. Here, we’re building a smart backpack with an embedded FORTH processor, capable of setting up high-speed wireless data links to the ship for full multimedia communication. A low-speed control channel will use DTMF via Motorola GMRS transceivers, and pulling out the PowerBook and executing a command will choose the highest bandwidth available channel, log into the Hub, execute a user authentication procedure, then allow the manpack client to access any comm resource on board ranging from the compass data stream to the AppleTalk network itself. This, or Hub console connection, will allow full control of all Microship functions via remote laptop.
The Manpack will carry a miniature color video camera on the shoulder strap, with a direct video transmitter designed by Bill Brown, WB8ELK for full-motion feeds to the ship. The user interface consists of a chord keyboard on the left shoulder strap, and simple voice feedback via an ISD chip. The internal FORTH board manages all resources, including an audio multiplexer that allows the various manpack resources to appear as a channel on the ship’s AuXBAR via GMRS, ham radio, cellular, or compressed digital audio.
Our hottest demo for this project involves a custom “nautical chart” of the UCSD campus, scanned and implemented in MaxSea by David Crane. Someone will walk around campus wearing the Manpack, with the Helm Mac displaying their location as a moving icon. Meanwhile, live voice, video, and data links will allow full interaction…
Video Turret
(Alex Burmester, Nathan Parker, Faun Skyles)
The lovely video turret built last year with mechanical engineering by Robert Lipsett now hosts a FORTH node, and this team is building the interface and writing the code to let either the low-light B&W or the color camera to point in any direction (or scan any angular range at any speed). The outputs are addresses on the video crossbar node built by Delon Levi, and can thus be routed anywhere on the ship. The turret also carries an instantiation of the pressure task described below, since it will be the most exposed electronic subsystem on the ship.
Faun is not an engineer, but is working as part of this team to gain experience in FORTH, control theory, hardware packaging, and the general behavior of the Microship network. (She and I have been together 6 months now and fully plan to travel together long term, so she’s immersed daily in parallel learning curves.)
Pressure System
(Mark Whitney, Tim Scheer)
Electronics and salt water must never mix… the results are swift and disastrous. To maximize the chances of long-term survivability, all electronic systems are housed in pressurized enclosures. The idea here is that pressurization with clean, dry air (water separator and desiccant cartridges) will allow a leak to outgas, rather than thermally breathe during diurnal temperature cycling. Theoretically, we should be able to monitor this and alert the crew that something needs to be fixed.
This project involves a number of trade-offs and long learning curves, and I solicit input from anyone with related experience (email me and I’ll put you in touch with the team). Basically, they will generate a task that can be installed in any node, which then tracks local temperature and pressure to determine the presence of a leak.
Sensors
(Inocencio Lasam, Sung Kim)
This is a very general project, with the objective of generating a number of standalone FORTH tasks that maintain variables according to measured phenomena. In the simplest case, these are just switches such as hatch and landing gear status sensors, but we also need a wide range of data from radiation, temperature, motion, barometric pressure, water quality, and other sensors. These will give our HyperCard front end something interesting to start displaying other than the details of the network itself!
I’ll leave it at that for now, and pledge to continue these postings as frequently as possible. While assembling the narrative of the project’s first year for our NRL Monographs, I was amazed at how effectively these notes captured the ongoing agony and excitement of engineering a complex system — you can easily track the changes and refinements as knowledge replaces vague notions. I was so close to the details during that time that I could hardly see the progression!