| |
As is my tendency, here’s an absurdly long treatise describing the development
of a LEGO Train Odometer Car (a.k.a. the “LEGOdometer”).
A Little Background.
After religiously attending them for several years, I stopped going to LEGO
train shows in 2003. At that time I had reviewed my work-life-play balance, and
opted to focus my club-related LEGO commitments on the regular NELUG meetings
and Brikwars games instead of train shows. While I continued to build train
MOCs regularly I let my attendance at these great events lapse.
But when NELUG decided to participate in a small train show a mere 20 miles from
my house, I couldn’t resist. So I spent a couple of weeks repairing and
refurbishing all of my old trains, and finishing up some new offerings that
hadn’t been shown before.
The show itself was fantastic. The setup and teardown was smooth, the layout –
though significantly smaller than NELUG’s standard offering – looked great, and
all of the people we encountered were extremely pleasant. It was a wonderful
reintroduction into Train Shows, and I’m looking forward to reintegrating them
into my LEGO life.
While at the show I quickly remembered how much I enjoyed the audience and
participant enthusiasm, the gorgeous aesthetic of a full display … and the
inspirations that seem to come fast and frequently over the course of a Train
Show weekend. At one point during the weekend I asked myself, “Self, how far do
you think that train has gone this weekend?” I did some quick calculations and,
based on the size of the loop and its approximate speed compared to spectators
walking alongside it, came up with a distance of about 16-18 miles over two
days. An impressive achievement for a little toy running in circles! Still, I
thought, ‘Wouldn’t it be nice to actually have an odometer to measure the
distance travelled … ?”
Well, we all know where that leads.
Some Objectives.
I had a couple of objectives in trying to design and build a working odometer:
- I wanted to it be compact enough to fit in with most trains. Ideally it would fit in with a 6-wide train.
- I wanted to optimize the accuracy so the measured error was as small as possible.
- I wanted the readout to be easily and instantly readable by a layperson. That is, I didn’t want to incorporate any conversions or esoteric displays that would require any explanation or extensive interpretation.
- I wanted the design to be robust. This train car was to be transported to and from shows, pulled around in a layout for hours on end, picked up and displayed for demonstration purposes, and all without skipping a beat. This meant it shouldn’t be fiddly, either.
- In general only standard LEGO components would be used. One notable exception was that I knew from the start I might end up using BBB wheels. Another was that I was willing to make custom labels for the number readouts. Those aside, I intended to use all official parts.
- No RCX or NXT! For some reason I get a kick out of solutions that incorporate old-school mechanisms to perform relatively complicated feats – especially if the same task could be achieved relatively easy with a microprocessor. Plus it drives Joe Comeau crazy that I refuse to use the power of computing, and that’s just sheer bonus.
How Should the Data be Displayed?
As I began to attack the problem, I came to the realization that there were two
elements that would inform much of the subsequent design: the distance display
scheme, and the measuring wheels with their reducing gear train. Of these, the
latter turned out to be the greater challenge.
In keeping with the robust design philosophy I quickly settled on using the new
technic tread links in the display. Besides linking together strongly, the fact
that they could accept technic half pegs ensured that numerical indicators could
be attached securely.
I initially envisioned using a simple gear reduction between the various dials;
that is, a constant mesh between the tenths and the units, and between the units
and the tens, and so on. As long as the gearing ratios were correct, this would
work fine. But it’s not how a mechanical car odometer works! The smallest unit
on an old fashioned car odometer rotates continuously, but all of the other
dials “click” into place, from one digit to the next. This makes it easy to
read, in that only the last dial needs to be interpolated between the digits. I
decided to try and emulate this functionality. This would entail some sort of
periodic engagement to advance the next dial the correct amount – more
challenging, but more in line with the design aesthetic I was after. Besides,
it was important that a layperson could read the results, and most people would
not want to try and interpolate the mileage off a series of 4 or 5 “in-between”
readings.
My initial display attempt used the small technic link gears and a belt of 20
links. Every other link had a small brick block attached to it on which a
number label could be attached. A technic pin on one link could easily engage
with a three-bladed propeller tied to the next dial and turn it 120 degrees with
every revolution. Coincidentally, 120 degrees on the small link gears is 2
teeth, which corresponds to two links – perfect! This would advance the next
dial exactly one digit for every complete revolution. Unfortunately, this
20-link belt ended up being quite large. When assembled, my train car was much
too tall. There was no way it would fit in with a 6-wide train, so it was back
to the drawing board.
The large technic link gears, on the other hand, were also appealing in that
they had ten teeth – just right for a 10-digit display. Using these, my display
assembly could be much smaller. In order to advance the next dial one digit for
every full revolution the reduction between dials would have to be 1:10. I
opted to use a spoked interface to achieve the periodic dial-advancing
engagement; the readily available small spoked pieces I could find were
2-bladed, 3-bladed, and 4-bladed. Of these, the best combination I came up with
was the “Technic Pin Joiner Round with Four Bars 1L” (which during the
engagement that occurs with every revolution will advance 90 degrees, or 1
blade, for a 1:4 reduction), plus a 16-to-40 tooth gear interface (for an
additional 1:2.5 reduction – for a total of 1:10!).
Brickbuilt “panels” were attached to technic chain links wrapped around the
10-tooth link gear. Labels were made using a Casio EZ-Label Printer with 9mm
white tape.
Which Drive Wheels Should be Used?
This question plagued me right up to the end of the project. Clearly the wheel
needed to be compatible with LEGO track layouts, and it had to accept an axle so
it can interface with the rest of the system.
On one hand a larger wheel – like a BBB wheel – provides a larger moment around
the central axis when running. This larger moment could help overcome any
friction in the gear train and prevent wheel slipping, ensuring a high level of
accuracy. On the other hand, it’s not an official LEGO part.
Alternatively, the new LEGO Power Functions drive wheel – with its rubber band
for additional friction – was an appealing option. Besides being an official
part the rubber band promised a no-slip advantage. Even after I had built the
entire design using BBB wheels, I couldn’t help thinking that maybe I should use
the Power Functions wheels instead, so I started working on the analysis
required to incorporate them. I needed to know the “official” running diameter
of the wheel for all subsequent gear train calculations, so I enlisted the
assistance that greatest purveyor of LEGO-related trivia, minutiae, and detailed
information, Dave Eaton. While he sought out official word, he conducted some
bench tests in his own kitchen. During these tests he noted that the rubber
bands, while they themselves never slipped against the track, did at times slip
against the wheels. That is, the rubber bands could rotate independently of
the wheel axle – which is an unacceptable feature when rotational integrity is
paramount! Suddenly my choice was much easier – official wheels were off the
design board, and the BBB wheel design could stand!
Coincidentally, the larger wheels have another advantage. Because they rotate
fewer times per linear distance traversed, the required gear reduction is less.
This generally equates to (a) shorter computational times in the optimization
program, and (b) fewer gears in the reducing gear train, which is easier to
package and introduces less lash into the system.
Calculating the Gear Train.
This was really the meat and potatoes of the exercise. To what level of
accuracy could LEGO gears translate a wheel’s rotation into a real-world measure
of distance? This calculation starts at the beginning; the drive wheels. Using
a pair of calipers I took a series of measurements of the BBB wheel diameters.
Not-so-coincidentally, my measurements matched Ben’s cited 30.4mm drive diameter
extremely well, so that number was confirmed to my satisfaction.
Based on my initial estimates of how far a train might travel in a show, I knew
I wanted the readout to have a display range greater than 10 miles. At the same
time I also wanted to ensure that an astute viewer could actually see some
change in the odometer as the train travelled. The former requirement argued
for pushing the readout into the higher places, while the latter argued for
pushing it into the lower places. Between these two competing philosophies I
settled on a range of 99.99 miles. That is, the highest dial would display the
tens, and the lowest dial would display the hundredths.
The next step was to figure out how many rotations the wheels would make if they
were to travel the distance represented by one full revolution of the
smallest-place dial. As I had settled upon hundredths as the smallest increment
of measurement, a full rotation of that dial represents one-tenth of a mile.
Therefore the target gear reduction could be calculated by determining how many
times the drive wheel would rotate, n, over the course of one tenth of a linear
mile of travel; this then becomes the target gear reduction 1:n.
In order to obsessively optimize the accuracy of the gear reduction, I left
nothing to chance. I wrote a Visual Basic program that would semi-brute-force
through all of the possible combinations of gear reductions that can be achieved
using standard LEGO parts, and continuously retain the combination that produced
the smallest error as compared to the target gear reduction. I refer to the
method as only “semi-brute-force” in that the program utilized several criteria
on the basis of which it would rule out various combinations. For one, the
program was limited only to “clean” gear combinations, or ones that would
interface smoothly; no 14-tooth bevel gear meshed to a 24-tooth spur gear. For
another, the program would skip combinations that were getting progressively
worse; if an additional 1:8 reduction overshot the target reduction by more than
the current error, the program would automatically skip 1:12, 1:16, 1:20, 1:24,
1:36, and 1:40.
With the BBB wheels and a reasonably small target distance (one-tenth of a
mile), the program would run through all of the possible combinations and come
up with a solution within about 15 minutes. I also tested the design envelope –
using the small BBB wheels and a 1-mile distance increment, the calculation took
just over 2 days to cycle through all of the allowed combinations!
At the end of this exercise, a gear train with the greatest possible accuracy
was identified. Even so, this was not necessarily the exact one I would
incorporate. Because there are often multiple combinations that can produce the
same reduction using standard LEGO gearing, I would manipulate the results to
maintain the same overall ratio but optimize the actual part selection. For
example, I might replace a 12:20 and 20:36 pair of reductions with a single
12:36 or 8:24, or vice versa. Various design considerations informed these
substitutions. In general, it was preferable to reduce the number of gears, so
as to minimize lash. Similarly, I tried to minimize the number of 8:x gear
reductions, as I’ve never been pleased with the amount of lash when using an
8-tooth gear. Furthermore, the 40-tooth gear could only be used sparingly, as
it would have to be aligned near the center of the car body in order to keep the
overall car size down.
Still, the final results were impressive and pleasing. Given the assumptions
that went into the calculations (no slip on the track, all gear lash taken up,
and accurate wheel diameter measurements) I was able to achieve an actual gear
reduction that had an error of 0.1423% from the target – or better than 8 feet
per mile. That is, when the dial on the odometer reads 1 mile, the actual
distance gone by the car is 1 mile and 7.5 feet. Not bad! This was
accomplished using a gear train consisting of 1x1:24, 3x12:20, 4x16:24, and
1x8:24 reductions.
And that, as they say … was the easy part. Next came packaging.
One of the original goals was to keep the design as compact as possible. I knew
this would entail packing the gears in as tightly as possible, and that I would
end up going mad if I tried to sort out the optimal design in real brick. I was
not limited to studs-up construction, and I was willing to use offsets as small
as half-stud and single plates. In fact, I might have even tried to do some
fancy SNOTwork to incorporate half-plate offsets if there were a demonstrable
advantage, but fortunately it never came to that.
Instead of going mad, I opted for virtual layouts using MLCAD. I can’t
recommend this process enough – especially when working with gear trains in 2 or
3 dimensions. It is much easier to move a gear virtually and check alignments
that to do it in real life, with all of the axle and technic brick rearranging
that entails. Still, my computer shows 39 separate and unique variations on the
gear layout design as I went through the process – and even most of those
represent some evolution as I worked on them.
As much as possible, the large gear reduction pairs were frontloaded toward the
beginning of the entire geartrain. This was an intentional design choice, as I
wanted to make sure that the system developed as much torque as possible as
quickly as possible. This would then allow the friction from the relatively
smooth rolling contact between the BBB wheels and the rails to overcome all of
the gear friction in the train, plus the significant force needed to rotate one
or more of the higher-denomination display wheels.
For the few designs that I did build, the actual construction was
straightforward. Using an MLCAD layout as a schematic, I could assemble the
framework and build the entire assembly from scratch within an hour or so. To
summarize the geartrain design process:
- Determine the contact diameter of the measuring wheels
- Specify the smallest increment size to be displayed
- Run the VB gearing optimization program to determine the best gear reduction
- Manually evaluate and substitute equivalent gear combinations, while retaining the same overall gear reduction
- Use MLCAD to virtually arrange gears into a compact and robust package
- Build real-life gear train according to MLCAD design
This process was repeated many times before the final arrangement was
determined.
Clearly this design uses a large number of gears meshed in series. In order to
reduce the effect of lash in the gearing, all of the dials have a progressing
ratcheting gear; they “click” into place as they advance, and cannot swing back
with vibration or motion. The only exception is the smallest-denomination dial,
which is geared directly to the wheels.
As a direct result of this ratcheting feature, the train is unidirectional; it
will bind up if run backwards. There are a number of arrows on the car to
indicate the proper direction of motion. One benefit of this unidirectional
design is that the slack in the gears should never be a problem. Once the
system has taken up all of its gear lash in the forward direction there is never
any more slack.
What’s Not Ideal?
As Dave Eaton likes to point out, the length of the outside rail on a circular
train track will be longer than the length of the inside rail. This same effect
holds true with nearly all train layouts that are seen in shows; the length of
one of the rails will be longer than the other. So the question becomes – what
do we truly want to measure? The distance the train has gone around the outside
rail? The distance along the inner rail? Or some distance in between?
As implemented right now, the LEGOdometer will measure some distance that lies
between the outer and inner rails, but exactly where in that range cannot easily
be determined. The current design has two outer wheels linked by solid axles to
the two inner wheels; these two axles are then geared together so that their
rotations are tied together. Because the outer rail is longer, some of the
wheels will have to slip when the car goes around a curve. In one extreme case,
it would be the inner wheels that always slipped; in that case, the outer wheels
would remain in perfect contact with the outer rail, and the measured distance
would be that of the outer rail. Conversely, if the outer wheels always slipped
to accommodate the different lengths of the two rails, the measured distance
would correspond to the length of the inner rail. In actuality it is likely a
blend of both inner and outer wheels slipping at different times, creating a
quasi-averaged value that lies somewhere between the two.
A secondary effect to this actually occurs just as the truck enters or exits a
curve. Because both wheel axles are geared together, the leading wheel pair is
forced to rotate at the same speed as the trailing wheel pair. But when the
leading pair has entered the curve while the trailing pair has not, one of the
two pairs (or a combination of both pairs) is slipping. Conversely, the same
thing will happen when the car exits a curve. In theory these effects would
cancel each other out, but if they don’t they could introduce some error to the
measurement.
Ideally, I like the idea of implementing a differential between inner and outer
axles. This would average the length of the two rails, giving a “centerline”
distance traveled. I have assembled a couple versions of a differential
wheelset, but have opted against using it so far since the trucks that house
them are significantly wider.
So How Well Does It Meet the Objectives?
On this score I am pleased! To address each of the objectives in turn:
- Size: having this as a consistent design goal produced great results. The overall dimensions of the “final” design are 10-3/8 L x 2-3/16 W x 4-7/8 inches H (~33 studs L x 8 studs W x 1 5 studs H). Although the car is about 8 studs wide at its widest, much of the body is actually between 6 and 7 studs wide. All told it is small enough to fit in with many 6-wide trains. It is, however, relatively heavy! Even after swapping out all of the regular bricks for lighter technic bricks, it weighs in at 1.47 lbs! This could be an issue if it were part of a long train, but on a moderate length train the motors should have no problem. On the other hand that mass ensures good contact between the wheels and the rails, such that the gear resistance does not induce any unwanted slip in the system.
- Measurement Accuracy: Accurate to within 7.5 feet per mile while measuring a distance that lies somewhere between the inner and outer rails! With an option to swap out the truck for a differential version that specifically measures the mid-rail distance!
- Readability: I’m mostly pleased with this. It’s not quite as intuitive as I’d like, but once someone is told where to look (“read the numbers along the orange markers”) the digits are legible and clear, easy to pick out. The decimal point isn’t quite ideal – in fact, as I’m typing this I’m realizing that it would probably be better to make the decimal dials in a different color for clarity. Still, with about 10 seconds of instruction anyone would be able to make out the reading, even as it goes by as part of a moving train.
- Durability: Success! I’ve moved this car around all over the place, taken it to show people, brought it into work on multiple occasions, and never had a single piece fall off. It requires one calibration during construction to ensure that all of the gears between the dials are aligned correctly, but from then on it’s simple to reset. I really like that the design is not at all fiddly!
- Standard LEGO only: The exceptions that I’ve made here – BBB wheels, and Tape Labels – were ones I anticipated going into the project. I sleep okay at night with the choices I made.
- No RCX or NXT: Ha! Mindstorms is for cheaters ;)
The total build time was about 2 months, 6 days a week, about an hour a day. So
that comes out to … about 50 hours of actual build time? On top of that, there
were about 10 hours of VB programming, and probably close to 20 hours of MLCAD
geartrain layout work (39 iterations!). Add to that a couple hours of Bricklink
order compilation, various technical investigations, photography and a 3700-word
write-up, and the whole effort tallies up to about 100 hours. Roughly.
Other images are available
here.
So Let’s See it Work!
Done! For the purposes of demonstration I threw together a simple drive stand
that will set the wheels spinning. Here are two short videos: the first shows
the straightforward rotation of the hundredths dial. The second shows the
engagement of all four dials flipping over when the LEGOdometer passes any value
of the form X9.99.
Video 1
Video 2
x-posted to .trains, .technic, www.trains-n-town.com, and www.nelug.org
|
|
Message has 13 Replies:
 | | Re: LEGOdometer
|
| Very impressive! I don't know what is the most amazing: the odometer itself or the extensive write-up ;o) Would you have more details (MLCad?) of the gearing/ratcheting between dials? And BTW, did you see this: (URL) (16 years ago, 5-Aug-08, to lugnet.technic, lugnet.trains)
| | | Re: LEGOdometer
|
| (...) -- Major Snippage! -- (...) Awesome MOC! It was interesting reading about the process you went through in developing this vehicle. Thank you for sharing this fantastic work with everyone here. Cheers, J.P. Manalo (16 years ago, 5-Aug-08, to lugnet.technic, lugnet.trains, FTX)
| | | Re: LEGOdometer
|
| (...) <snip> Great idea! Tempting to build something similar for our next show... The only disappointing part of the story is that it took a number of days of computing power to come up with a solution that doesn't use computing power ;-) (16 years ago, 5-Aug-08, to lugnet.technic, lugnet.trains, FTX)
| | | Re: LEGOdometer
|
| (...) Interesting. I thought this might be interesting to use in our displays...until I read that it binds up in reverse. When we lose a car for whatever reason (often some young kid's hand straying where it ought not to), we usually recouple by (...) (16 years ago, 5-Aug-08, to lugnet.technic, lugnet.trains, FTX)
| | | Re: LEGOdometer
|
| (...) Your "LEGOdometer" is amazing! I especially liked hearing about the design process and the fact that the final product is purely mechanical. I'd never be able to design something like this... -Bryan (16 years ago, 5-Aug-08, to lugnet.technic, lugnet.trains, FTX)
| | | Re: LEGOdometer
|
| Shaun, Impressive work, both in construction and the write up! Welcome back to the fold of trains (at least for a little bit)...did you know that the next National Train show (that ILTCO has been particpating heavily since 2005) will be in Hartford (...) (16 years ago, 5-Aug-08, to lugnet.technic, lugnet.trains, FTX)
| | | Re: LEGOdometer
|
| A nice explanation and reading. A better MOC. Also intend to return later and read it more carefully. It is extensive, to get everything at first. ;) (16 years ago, 5-Aug-08, to lugnet.technic, lugnet.trains, FTX)
| | | Re: LEGOdometer
|
| (...) --snip (as is my own tendency ;) )-- Wow. I imagine if I had a clue how to build technic there'd be a few more wows but you can tattoo me impressed as is. Tim (16 years ago, 6-Aug-08, to lugnet.technic, lugnet.trains, FTX)
| | | Re: LEGOdometer
|
| Shaun, OK, I'm not a train guy and or even a moderately skilled Technic guy, but it's easy to see that this is officially ridiculously awesome. I've become interested in incorporating Technic functionality into minifig scale MOCs, but I don't think (...) (16 years ago, 6-Aug-08, to lugnet.technic, lugnet.trains, FTX)
| | | Re: LEGOdometer
|
| Nice box ! I ran most ratios through a pathetic microsoft product to derive a comparible metric read-out for those that made the transition from the stone age. put simply: 1 1:12 3 20:36 1 16:24 produces 1:104.9 at 95.5mm per rotation or for every (...) (16 years ago, 13-Aug-08, to lugnet.technic, lugnet.trains, FTX)
|
29 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
