I wrote this piece after spending quite a bit of time designing an automated solution to a messy problem: distributing tonnage on a boat in such a way that she remains balanced in longitudinal, transverse, and vertical axes. Marine architects made this issue abundantly clear when I was first designing the Microship, so my geeky solution was to integrate the math into the same database that I used for managing ship inventory. The images are blocky and specific FileMaker references are to an old version, but otherwise this is a timeless subject and should help folks who are dealing with boats, airplanes, helicopters, blimps, submarines, ROVs, or anything else that needs to stay balanced despite having a bunch of junk on-board.
by Steven K. Roberts
Nomadic Research Labs
April 27, 2002
I heard it from them all… every multihull marine architect who had ideas to contribute to the Microship project urged me, at one time or another, to do a weight study. Robb Walker… Gino Morrelli… John Marples… Jim Antrim… luminaries in the field, every one. Each informed me that a critical first step in designing a ship (or an airplane) is a thorough inventory of gear and fixtures with at least a summary of their weights and centers of gravity.
I really didn’t want to do this.
My first attempts were therefore pretty crude: one-page listings of broad categories, with wild guesses about aggregate weights. As I pointed out to my advisors, I could hardly come up with a detailed inventory when I still didn’t know the size of the boat, now, could I? “Tellya what,” I told ‘em cockily, “you tell me the constraints, and then I’ll massage the inventory to fit!”
No dice. “Do a weight study,” they responded. “It affects the entire design.”
Obviously, what we have here is a circular problem, and an iterative one at that. You make a list, discover that the weight budget won’t support a 100 gallon water tank (that’s 800 pounds of water), change the capacity to 50 and nudge it forward in the hull a little bit, then try again. There’s a lot of head-scratching and guesswork involved, and whether you’re outfitting a voyaging yacht or a racing skiff, the sheer volume of data can be overwhelming. If said yacht happens to be a multihull, the weight and center-of-gravity issue is even more critical… this is not a place for shortcuts. And, I should point out, the same problem arises in aircraft design but with even more critical implications.
So after a few false starts with a paper binder (tedious) and a spreadsheet (ugly and a mess to edit), I decided to develop a weight-study database that would maintain not only a running total but also calculate, on-the-fly, the ship’s aggregate center of gravity. This is derived from the weight of each object (starting with the vessel itself), and its vertical, longitudinal, and transverse centers of gravity (VCG, LCG, and TCG) – entered in any convenient notation (such as height above or below waterline, distance to port or starboard from centerline, and station, or distance from the bow).
This works beautifully, and we now have a tool that objectively (not optimistically) shows the effect of every added object – not only in terms of bottom-line poundage, but effect on trim. This makes it easy early in the design stages to modify decisions about battery bays, tankage, spares inventory, and more – all with solid feedback on how product choices and placement will affect performance.
This article will show you how to accomplish the same thing, using any robust database package, on any computing platform. The example here was created in FileMaker Pro for the Macintosh, but the theory and field definitions are fully explained so you can implement it in other packages (or in a spreadsheet such as Excel, if you prefer that over a database). This tool will not only give you much greater control over the trim of your boat, but also provide a convenient place to keep track of spares, costs, insurable totals, vendors, serial numbers, service intervals, and things to buy.
Let’s start with an introduction to the whole “center of gravity” concept, see how to calculate the effect of an object’s weight and location, then dive into the database design…
The Principle of Moments… A Few CG Basics
Every boat has a center of buoyancy (CB), which is the center of the underwater volume of the vessel. She also has a center of gravity (CG) which is where all the mass would be concentrated if it had to be compressed to a single point. If the boat is to float properly on her design waterline, then the CG must be in line vertically with the CB…. if it’s not, then the boat will correct for it by changing trim (and thus underwater shape) until the new CB is in a vertical line with the CG.
This pretty well sums up the problem. There’s not much you can do about the CB for a given boat (which wanders around with heel angle, but we won’t worry about that since it’s out of our control), and the CG of the raw hull is pretty much a given as well. But the moment you start installing equipment and people it all changes… often dramatically. Just take a stroll from bow to stern of a canoe for a quick demonstration of how much your weight can affect the trim of something with 1,000 pounds or more of buoyancy.
I’m not going to go into the extensive mathematical analysis of all the factors affecting this – it’s well covered in nautical textbooks and on the Web (a good place to start is Ted Brewer’s Understanding Boat Design). What we do want to discuss instead is how, exactly, you compute the resultant CG from the locations and weights of random objects so that you control the process from the beginning… instead of shoving stuff around later trying to fix it.
If you have one object sitting alone, then determining net center of gravity is obvious – it’s just the object’s own CG (fairly easy to guess for most smallish things, not hard to measure for large ones). But as soon as you have two or more attached the same substrate, such as a boat, you have to do a mathematical trick to find out their collective center of gravity.
An easy way to start visualizing this is with the seesaw in Figure 1. A heavy kid and a light kid, to achieve balance, must arrange themselves in such a way that the former is closer to the pivot point than the latter. It happens that the math is simple: all they’re doing is equalizing their moments, which are defined as their respective weights times their distances from the pivot point. If we have an 80 pound kid and his 50-pound little brother sitting on a 12-foot seesaw, they will automatically position themselves such that their moments are equal. Assuming that the light kid is sitting on the very end, his moment is 6 feet times 50 pounds, or 300 foot-pounds. To balance, the 80-pounder just divides 300 by his weight, yielding 3.75… then moves to that spot on the board. Of course, he doesn’t actually calculate this; he just scoots forward until the seesaw balances… and that’s where he ends up: 3.75 feet from the fulcrum.
What we have here is a simple demonstration that a small object far from the pivot point (CG) of a vessel (er, seesaw) has the same effect on trim as a large object that’s closer. If the kids on the seesaw happened to have instead been paddling a very tender canoe and had the nautical sensibilities to keep her properly balanced on her waterline, they would have positioned themselves similarly…
Now let’s see how moments can be combined to yield the aggregate center of gravity of any arbitrary number of objects.
It’s a process much like averaging. Looking at part (a) of Figure 2 below, let’s pretend that the horizontal line is a small 20-foot boat (we’ll ignore its own mass for the moment, so to speak). It turns out that any point can be used as a reference, so to keep measurement simple and avoid the added confusion of negative numbers, let’s call the bow our “reference datum,” which is a fancy name for zero.
I’ve arbitrarily placed two objects on board this imaginary vessel: a 55-pound battery 6 feet back from the bow, and a 85-pound outboard motor whose center of mass is 1 foot forward of the stern. Let’s calculate the moments:
Battery 55 lbs X 6’ = 330
Motor 85 lbs X 19’ = 1615
Where’s the resultant CG? Just add the moments and divide by the total weight of the objects:
CG 330 + 1615 = 1945 = 13.89 55 + 85 140
The center of gravity of the battery and the motor is 13.89 feet back from the bow… not very good trim!
In Figure 2(b), let’s add a second battery to see how the CG is affected. When you run the numbers with 110 pounds instead of 55, how much does the CG move? It scoots forward by over 2 feet! Our new CG is 11.67 feet (try this yourself to make sure you get the same answer).
But what if we instead kept the 55 pound battery but relocated it to a point 1 foot back from the bow, as in Figure 2(c)? Let’s ignore the fact that this sort of behavior is ludicrous from a nautical perspective (not only is that a poor place for a battery for purely electrical reasons, but you generally want big massy things near the boat’s CG to prevent hobby-horsing and other pathological behavior… this is what “moment of inertia” is all about). If you run the numbers, you see that the battery’s moment is now only 55 (55 lbs X 1’). Adding that to the motor’s moment and dividing by the total weight of the two yields a net CG of 11.93.
Now you can really see the interacting effects of an object’s weight and its location… the result of doubling the weight of a battery located 6 feet from the bow is almost identical to that of moving the original battery to a point only 1 foot from the bow. This is a key observation… for every object on your boat, you have two knobs to twiddle when determining its effect on trim: weight and location. Since the former is a little hard to adjust for most things, your most powerful balancing tool is moving things around with an understanding of moments.
This simple calculation scales to any number of objects, of course – we can add a thousand moments, divide by the total weight of those 1,000 objects, and the number will be their net center of gravity.
Now, take everything I’ve told you and expand it into three dimensions. CG comes in a trio of flavors, which add up to a point in space, located somewhere inside your boat. What we’ve been discussing so far is known as longitudinal center of gravity, or LCG, and lays along a line from bow to stern.
If you walk around to the stern and look at the boat from that perspective, however, you can see that the same kind of issues are present with side-to-side balance; you don’t want to be sitting all wonky in the water (here’s one situation where it’s good to be listless). The magic number here is called transverse center of gravity, or TCG, and is affected by tankage and other heavy things that people like to tuck out of the way to port or starboard. When calculating TCG, it’s traditional to use the centerline of the boat as the reference datum, with objects’ distances measured to port (-) or starboard (+).
And finally, if you tilt your head sideways and think in terms of stability, you have exactly the same set of phenomena operating vertically, naturally called vertical center of gravity, or VCG. In general, you want this to be down as low as possible; if it’s way up in the air, you could have serious problems! The reference datum for VCG calculations is arbitrary, but is often the DWL (design waterline), as that’s just about the only well-defined horizontal plane sliced through a hull. I mean, how many flat surfaces and straight lines are there in a boat? In all cases, the choice of reference datum is ultimately irrelevant, so if you have a more convenient way to measure from, by all means do so… just be absolutely consistent.
The foregoing quick introduction is all the background you need to perform the magic math that yields the center of gravity of your boat, including everything from the hull itself to that stainless steel crescent wrench you just bought. All this adds up to much more information than you’d ever want to keep in your head, so let’s automate it.
The Weight Study Database
First, I need to make a quick comment on the implementation. It happens that I developed this database on a Macintosh under FileMaker Pro version 3.0, which was back around the turn of the century.
None of this should matter much anyway, since you’ll doubtless want to configure the database to fit your own needs, using your own tools; by the time you’ve done all that you’ve basically created your own database (it’s not hard). 2017 Note: for years, I had the ancient template on my server, but it really is getting long-in-the-tooth… so I deleted it.
OK, let’s talk about how this actually works. Please take a look at the screen shot of my Microship inventory database.
The whole idea here is to have an inventory database for the ship, at any level of detail you like. To keep it from becoming a full-time job during initial planning, I just cluster whole piles of things into single units – like “tool kit” instead of the 200 or so entries that make up its contents. But the design does accommodate grouping, as we shall see in a moment.
The database does a lot of traditional things in addition to the magic center-of-gravity calculation – letting you track spares inventory, record serial numbers and vendor information, make notes about each item, and so on. And in my case, I also have a few dollar-value fields that most people don’t need, as much of our equipment is sponsored and it’s fun to keep track of that. I even have a $/pound calculation, which is utterly useless but amusing. (“Why do we do it? Because we CAN!”) I should also note that the values you see here are from an ancient test phase of this database, not reality… so please don’t draw any conclusions about the Microship project from this bogus data.
Let’s take it from the top, field by field.
Title: At the very top is a title, which appears on each record. This is completely superfluous, as it’s also shown in the title bar… but it’s pretty.
Item Name: This identifies the widget under consideration, in this case a marine deep-cycle battery.
Source: I find it useful to associate a vendor or sponsor with each item, where applicable… I bought this at West Marine.
Category: This field is a pop-up menu of all possible categories of goods on the boat, which makes it easy to look at just the contents of one locker or pack… or see how much the electronics weighs by doing a find on a single category. Here’s the full list from the test version of the database; yours will look different:
INTEGRAL: Cockpit furnishings
INTEGRAL: Marine Misc
INTEGRAL: Landing Gear
INTEGRAL: Water System
RIGGING: Ground tackle
RIGGING: Sails & Running
FileMaker allows you to edit a “value list” for a field and present it as a pop-up list, pop-up menu, check boxes, or radio buttons… it’s best to use this kind of approach for categories so your searches won’t be thrown off by alternate spellings.
Contact, Phone, and Serial #: These fields let you keep track of additional details about the item in question, for insurance or support purposes. This is the kind of data that can end up scattered to the winds (usually in old notebooks or receipts) if you don’t make some effort to put it in one place… and since you’re going to all the trouble to inventory the boat for a weight study anyway, you might as well put it here.
Cost and Value: I have two fields where only one is needed, just to let me keep approximate track of sponsorship, good deals, freebies, hand-me-downs, and so on. Cost is actual out-of-pocket; Value is what it’s worth.
Item Weight: Here you enter the weight of the item in pounds… and click a radio button to indicate whether it’s estimated or real. This turns out to be useful when you’re in the planning stages, and a quick find operation can tell you what’s still ambiguous.
Item LCG: Longitudinal Center of Gravity… this is where you record where the item is on your boat, measured in feet from the bow.
Item TCG: Transverse Center of Gravity… as above, here you record the location on either side of centerline (use negative numbers for port and positive for starboard).
(Item VCG: Vertical Center of Gravity. My boat, a micro-trimaran, is so low that this turns out to be irrelevant for me, so I left it out. It works exactly like the others, and adding it is an exercise for the reader.)
Status: This line of check boxes is a quick-and-dirty way to flag items that need to be acquired, or otherwise create useful abstract subcategories for searching.
PM Months: I haven’t really done anything with this yet, but the idea is to periodically print out a Preventive Maintenance schedule, with items sorted into intervals (like checking the batteries in your strobe every year). As with any other field in this database, if it’s not useful to you, just delete it.
Batts/Spares: Here we have a place to record what batteries or spare parts associated with this particular item need to be on hand… and the two radio buttons to the right indicate whether they are local or back at home base.
Notes: Anything you like goes here. I tend to expand the description a bit and record any other details I might like to know someday.
OK, here’s where it starts to get fun. Everything from this point on is updated automatically by the database every time you add or modify a record. Nothing below this line is ever manually entered (and the database will stop you if you try).
Total Value: This is a “summary” field that totalizes all the “Value” fields in the database. A nice thing to know.
Total Cost: Likewise for the real out-of-pocket…
% Spons: This is a calculation based on the past two fields, and is defined as ((Total Value – Total Cost) / Total Value). In practice, I find that the separate sponsor database is a much more useful place to keep this information, as it includes things that don’t appear in the ship inventory. I’m leaving it in just to give another field calculation example leading up to the CG stuff, but I don’t particularly recommend that you use it.
$/lb: Be honest, now… don’t you also wonder about completely useless things like this?
Item LM: Item Longitudinal Moment, or the result of the item’s longitudinal (Weight X LCG) calculation (55 X 6.5 = 357.5). This number by itself isn’t particularly useful, though it does show you the “torque” applied to the boat by the object in question. It exists as an intermediate calculation step in the development of the value we’re really after.
Item TM: Item Transverse Moment. Exactly as above, but reflecting instead the item’s effect on side-to-side trim. Note that the battery is centered in the boat, so even though it weighs 55 pounds its effect on the transverse center of gravity is zero (55 X 0 = 0).
Total LM: This is the sum of all the longitudinal moments in the database, at this instant equaling 7,142.08 foot-pounds. If you tried to pick the boat up by its very bow, this is the torque you would have to overcome.
Total TM: Likewise, the sum of all the transverse moments. Since the center hull of my boat is a canoe and things tend to more or less hover around the centerline, this shows just a minor negative value. In a millpond, this would translate into an almost imperceptible list to port.
Total weight: This is the beginning of the bottom line. Recall from our explanation that at some point we’re going to need the total weight of everything on board. This is a summary field that automatically increases – frighteningly quickly, I might add – with each item you lug aboard.
Net LCG: Here we have the result of the final longitudinal center of gravity calculation: the database has totaled all the longitudinal moments and divided by the total weight to yield a point just aft of center.
Net TCG: Similarly, this is the result of the final transverse center of gravity calculation.
Using (and Enhancing) the CG Database
Putting all this to use is easy… just start throwing stuff at it and watch the numbers converge! But it’s best to begin with the boat itself.
This isn’t as hard as it sounds. You need a scale that can handle about half the weight of your boat. Follow these steps:
- Weigh each end of the level boat, wherever and however convenient.
- Note the exact distance from the bow of each measurement point.
- Multiply each weight by the distance from the bow.
- Add those two numbers.
- Divide the total by the sum of the two weights.
Sound familiar? You just performed the same old moment calculation to determine the boat’s LCG! If she’s on a trailer, you’ll have to measure the weight of the wheels and tongue, then make the same measurements on the unloaded trailer and subtract. Either way, it’s important to start with the substrate, the single largest contributor to the CG numbers you’re after.
Once you have this, create a database record for the boat itself, ideally with no equipment installed (I know, that’s not always practical with an existing boat, but you need to draw a distinction between things that are part of the boat and those that are not). This is your starting point, and every subsequent component in the growing calculation will nudge the CG figures back and forth, left and right, up and down… giving you an evolving look at your static trim.
If the empty boat rested perfectly on her lines, you already know the target values… you want the final net CG figures to be exactly the same. If she didn’t float level, well, at least you know which way you have to tweak things to achieve a proper balance. And don’t forget the ephemeral variables: tankage, people, and stores. It might be useful to include a yes-no field called “empty” and use it to flag separate records for the contents of tanks, expected personal gear brought on board by crew, and even the crew themselves in estimated locations. When you do a FIND on the database with empty=yes, you have the CG of the empty boat; if you do a find-all (hitting command-J in FileMaker), the additional weights of all the added cargo are considered in the calculation.
Incidentally, there’s a lot more to this than just the CG. That lets you determine static trim when sitting quietly in the water and has a lot to do with stability, but there are dynamic issues as well. In particular, the phenomenon known as moment of inertia will affect the rolling and pitching action in a seaway: if all the mass is concentrated at the center, the resulting motion is quicker; if it’s at the ends, slower and deeper. There are all sorts of trade-offs here that are further affected by your boat’s hull design and purpose in life; see Link#2 below for a useful discussion on the subject. Adding moments of inertia to the database is no big deal (the basic difference is that you square the distance figures to exaggerate their effect on the total).
I noted earlier that we happened to have done this in FileMaker Pro on the Mac, and that you are encouraged to implement it using other programs or computing platforms. One of the most interesting database environments is the range of SQL-based tools, such as the popular MySQL available free for Linux. The fundamental difference is that this kind of relational database appears more as a linked collection of tables, and there is no mechanism for internally maintaining calculations as we do here. However, it’s quite easy at the query level: you would write a query that computes the various totals and net CG on demand and let the machine run the whole process anytime you ask for it… such as
select sum(weight) as totalWeight from myInventory
to compute the total weight of all items on the boat.
Finally, I should note that all this applies equally well to airplanes, helicopters, submarines… anything for which balance is important. You can even apply this tool to backpacking or bicycle touring, for a nice low CG makes life much more pleasant when you’re hauling something around with your body. Feel free to experiment… the real point here is the basic calculation method; there are countless ways to put it to work and this database is just one convenient way to package it.
Good luck, and may your vessel always rest gracefully on her lines!