Hacker News new | past | comments | ask | show | jobs | submit login
Gears (ciechanow.ski)
2760 points by robert-boehnke on Feb 12, 2020 | hide | past | favorite | 222 comments

I have heard that it is good practice to always chose the number of teeth of two gears to be relatively prime. This is because there can be impurities in the metal, and if you have a small part of a tooth that is harder than the rest it will erode the opposing gear (there is always some friction going on). By choosing the number of teeth to be relatively prime, the wear and tear is distributed uniformly on the gears, and thus they last longer.

This is a similar problem to riding a fixed gear bike. When using skidding as a braking technique, specific areas of the tyre will wear faster unless you select a gear (front chainring and rear sprocket) combo with a large amount of skid patches. This is due to the rider always engaging in a skid with their crankset in a specific position - either left or right foot at 90 degrees, and the other at 270 degrees.

Here's a fun calculator for it: https://www.surplace.fr/ffgc/

Notice that a very common gear combo, 44/16 only gives 4 skid patches, so if you're after longer lasting tyres avoid this setup.

Anyone that is fascinated by gears owes themselves a visit to This Old Tony's video on YouTube titled "Gears! - But Were Afraid To Ask"


He goes into the nerdy depths of gear make-up, metallurgy, meshing, machining and mistakes as he manufactured metal gears on a mini-lathe.

I second TOT, his videos are just fun to watch. Plus, you learn something.

Going through his page, I immediately thought of his video on gears. Suprise! when it was mentioned at the end.

That's also what I was taught as a best practice, but it's not always possible. Otherwise, best practice is to index the gears (ie mark a specific tooth on each). That way, when you disassemble the gearbox (it's bound to happen sometime for maintenance), you can make sure it's reassembled so that the same teeth will continue to mesh, preserving the wear pattern. Otherwise, wear is substantially increased.

  That's also what I was taught as a best practice, but it's not always possible.
Well of course it's possible -there are infinitely many sets of coprime numbers! Silly engineers

Good luck for when you need exactly 2:1 ratio, like eg in clocks.

Just add more gears in between.

So it's a bit like violence.

Gears: If it's not solving all your problems, you simply aren't using enough of it.

I look forward to trying out your infinite gearbox implementation.

By relatively prime, do you mean the largest denominator == 1? Or in other words, 15 and 22 should be relatively prime?

This is what is commonly meant by ‘relatively prime’, yes. Also referred to as being coprime.

Defn: a & b are coprime/ relatively prime iff GCD(a,b) = 1

Yes, relatively prime means coprime means gcd=1

This is an absolutely phenomenal 'explorable explanation'. It methodically layers concepts to foster understanding, deploys interactivity to build intuition, and on top of all that provides crisp, clear narrative on top of all of the amazing visualizations.

If you enjoyed the article, check out others by the same author which are done in a similar way. For example https://ciechanow.ski/color-spaces/ and https://ciechanow.ski/earth-and-sun/

The interactivity also reminded me of this post from Bret Victor: http://worrydream.com/LadderOfAbstraction/

Or have a look at all his interesting articles here: https://ciechanow.ski/archives/

Excellent - thx !

We are all sitting here in collective awe, and the JS source contains this header:

> /* Dear explorer, this code works, but is by no means of high quality. Once a post is written I don't go back to the source code again and the formatting, robustness, DRYness and abstraction choices reflect that. */


What is your point? Are you saying that it's bad he didn't tidy up the source?

I think potentially pointing out the humility of the author. But unsure.

I wish I had sites or visualizations like this when I had to do maths, I mean for example I've had to use sin/cos/tan in all kinds of calculations without ever being explained what they actually are, and the formulas without being explained what they're good for.

Is there a widely known name for these types of 'explorable explanations'?

Explorable Explanations is the term AFAIK. Nicky Case has a whole page of resources on the topic: https://explorabl.es/

Drives me crazy that if I suggest diagrams like this might be useful on wikipedia or documentation I mostly get downvoted into oblivion.

I'm sure a lot of users on HN are angry that this site requires JavaScript and demand it to be accessible on a text based browser.

Haha you might enjoy this: https://anderspitman.net/17/#curlable

And of course the logical next step: https://anderspitman.net/19/#netcatable

Yeah this is amazing. Interactive learning can be super powerful for a number of topics.

If someone ever makes the creation process for this type of visualization accessible to the average university professor, it could blow the lid of the digital textbook market. Most digital textbooks I've seen are basically just putting the text and images on a web page, and maybe integrating multiple choice quizzes. That's seriously under-utilizing the medium. They need to be interactive, and encourage the student to ask questions and run mini experiments.

I'm aware this would be extremely difficult; maybe impossible.

I'm a professor currently writing an online textbook. I can assure you that writing a textbook, without anything interactive, is extremely challenging. I find it hard to imagine a time when my book will be good enough that adding interactive explorables will be the best educational return on time invested. (Though I'm thinking about it!)

I think it definitely is more appropriate in some domains than others. Sometimes you can replace 1000 words with a picture, 100 pictures with a video, and 10 videos with an interactive visualization. In that case, it might not actually be more work. I think the problem is that it's very different work, that professors aren't trained for. Again, it's not easy, maybe impossible. But if it could be done...

PS - I see you're at U as well. I work on a datavis team (iobio) in the genetics department (Steph says hi!). If you ever want to meet up I'd be interested in talking more about this.

Bear in mind that some people are more visual, so I think the interactive visualization should serve as a complement to the 100-1000 words that describe it, not an in-place substitution... (Also, let's not forget about the visually impaired, which need the interface to be accessible).

On average, vision is by far the most important sense for a human. Would you reduce the experience for most people in order to help the minority, especially when there already exist so many text-first books?

Not to dismiss your work, but do you think the best investment of your time is to write another textbook (assuming this is an undergraduate level book in a relatively well-explored field), or in adding detail/great illustrations/great interactive charts to an existing work?

I know (really, like, I know) how detrimental this would be to anyone's career, and I'm not saying this as a moral condemnation of what you're doing - just curious, as I've found myself that there are many cases in these circumstances where the interests of the author do not align with those of the audience. Just wondering if you feel the same way.

I'm writing a textbook on a topic no existing book covers: the internals of a web browser.

For your broader question---I understand what you're saying, but it's very difficult to edit someone else's writing. That's where "committee voice" comes from: it's the lowest common denominator to multiple authors working together. And often how I visualize things comes from how I look at things, and coming up with a visualization for how someone else looks at things is hard.

Take the OP as an example. This is a long blog post on gears in general, but animated by the specific question "what shape are gear teeth". If I were writing a blog post about gears, I wouldn't start at that place. And then, imagine if this blog post started text-only instead of visual. "Involute" would now be described with algebra, not a picture. The algebra is complex (compare the Wiki at https://en.wikipedia.org/wiki/Involute), and that algebra itself would need pictures. Illustrations and explorables aren't, ideally, something you sprinkle onto existing text.

OK yeah then your case doesn't apply to my general question. I imagine that for something that is as visual as your topic, animation would be extra useful though :) (like showing with a slider how reflowing works in certain edge cases or something) Not to egg you on of course :)

And I see what you're saying on how it's hard to build on someone else's work, and how what is relevant to illustrate heavily depends on the viewpoint of the author. Still I can't shake the feeling that there is so much duplication. Maybe I should just look at differently. Anyway, thanks for weighing in.

I'd be really interested in seeing even an outline of that text.

Oh, found it. Noice!


> Not to dismiss your work [...] assuming this is an undergraduate level book in a relatively well-explored field [...] not saying this as a moral condemnation of what you're doing

Why is that your default assumption? Seems very strong when GP gave basically no details.

It wasn't the assumption, I was just being extra careful to emphasize that I wasn't saying 'hey dude you're doing it wrong', but was asking about how the OP felt on a topic I had personally experienced (i.e. interests that conflict with the global optimum)

> Why is that your default assumption?

Because that's probably most textbooks.

Edit: Are people downvoting me because I'm actually wrong about textbooks, or is my answer unsatisfactory somehow?

I've always been partial to this TAM 212 online reference from UIUC. I don't know what the professor used to generate it but many of the diagrams are interactive and help build intuitive understanding of the material.


Whoa, some of those interactive tutorials are really impressive.

I developed some widgets for interactive books in primary and secondary education. We had different quiz widgets (multiple choice, etc) but also drag and drop stuff and other types of widgets. The people in editorial producing the books configured the widgets using custom HTML tags. It worked very well. As long as they knew HTML they could configure these widgets.

The problem is that anything that is easy to produce and configure with a set of options is going to be very limited.

It is certainly possible to create an environment for producing mechanical and physical simulations with visual tools but it would not be trivial to develop.

I suspect the optimum balance would still be somewhat technical. Maybe something on the level of a spreadsheet. It takes some specific knowledge to use effectively, but is still fundamentally a simple and intuitive tool.

This sort of interactivity would be perfect for Wikipedia.

There is a research area called "Empirical Modelling" which was trying to create these tools but not sure of the progress.


I really like this presentation! It’s wonderful.

I don’t mean to hijack but I thought this would be an appropriate place to share a photo album of the 3D printed planetary gears in my open source robot: https://imgur.com/gallery/GqXD2Zj

I’ve been 3D printing gears for some years now and I want to spread the word that 3D printed gears actually work really well! The gears in the image album above have been operating on that robot for over a year now and they’re showing no real signs of wear.

It can be really fun to get a 3D printer and design a little gear assembly. Once you’re comfortable with gears you can use cheap motors to make something that moves. Find a way to drive it with Python from a raspberry pi and you’re on your way to making a robot. :)

That project looks great! I'm very tempted to start building this because of how good it looks, but I know it would take lots of time and effort, even with the designs already available.

As an aside, would something like https://www.makerfol.io/ be useful for your build log? I see many people using imgur for this but it's always struck me as suboptimal.

Thank you! It’s certainly an involved project. I recommend starting by building one motor and gearbox assembly and getting control working from python. If you can get that far you can build the rest!

And the website you linked looks nice. There is also hackster.io and hackaday.io. While those sites are fine, it becomes one more thing to update. I prefer imgur for simple photo albums as that integrates well with reddit, my primary promotional place. Imgur actually works really well for me there. And then my real build updates are on my YouTube channel. And I have my own website where I try to throw everything.

So I end up trying to funnel people to my website and just using whatever media hosting makes sense for that particular media.

That makes sense, thanks! Regarding the build, I didn't see any information regarding the control system on the material I saw, but I probably wouldn't want to make it as autonomous as you have. I'd probably connect an ESP8266 as the controller and a receiver for my RC radio and control it that way.

Out of curiosity, is there more detailed information about the controller somewhere?

Well do you mean the motor controller, the control computer, or the remote control?

I’ve got some info on the motor controllers I’m using: https://reboot.love/t/vesc-mods-for-robotics-use/

The control computer is a raspberry pi running python. It looks like I’ve not committed the code in a while, but this repo may be helpful: https://github.com/tlalexander/rover_control

Though for the above, I’ve recently found that I can use velocity control on the VESC, which is easier than doing velocity control on the Pi as I had done in that repo.

For the wireless remote control I use, it’s my own design and they’re not for sale or well documented. I’d recommend any wireless controller that you can read in python.

The software should be pretty simple now that I’ve switched to velocity control mode. You just need to read a joystick and convert that to velocity commands for each VESC. Technically even the VESCs could do that onboard if you wanted to modify the firmware.

But if you can drive the VESC from an esp32 that would work too.

Oh huh, that's pretty involved, thanks. Can I ask why you rolled your own instead of using off the shelf RC components, like what is used in RC cars, for example? For the remote control and ESC, at least, it seems like it would be simpler.

Well for the remote control, I already had the one I used. I started a wireless electronics company in 2013 (and eventually failed), so it’s a point of pride to use my own remote. But any RC remote would work.

For the ESC it’s more complicated. The VESC is off the shelf, but it has a feature most ESCs don’t. The VESC supports encoders. The use of an encoder is very important to get full motor torque on the brushless motors even at zero velocity. This allows Rover to slow down or stop even on a slope. The encoder is also used for precise velocity control, which keeps all the wheels spinning in concert. Additionally, the encoder data is sent up the CAN bus to the raspberry pi so my program knows wheel velocities.

You could certainly build a rover without encoders and with a regular ESC, but it may have trouble starting from a standstill and it may not always drive in a straight line if the wheel velocities are not all the same. Another thing to note is that if you spin the motors really fast you’d probably melt the gearboxes. I’m moving the motors pretty slowly compared to their maximum speed. But a regular ESC might work fine! I’ve not tried it.

That's very helpful, thank you. So you're basically turning the brushless motors into stepper motors with the VESC, that's very interesting. Again, great project, congratulations.

Hey, nice project :)

A few friends were experimenting with 3D-printed gears for their robots, I've advised to switch to helical gears as these should make less noise, and less prone to wear (since the load never happens on a single teeth, but is transfered progressively). Of course, that creates axial load, which might or might not be an issue (and countered with a second cog), and complexify assembly, especially for planetary gears. But if you try (or already have) them out, let me know.

On our part, the test have proved successful, but we're not looking at tens of kilometers, and mostly print PLA.

To clarify why they aren't used more, their production process is traditionally more complex, but that doesn't happen with additive manufacturing. I'd also guess that the teeth shape makes them more robust than conventional filling, and more evenly distributes force on the layer joints.

Thanks! I’ve used helical gears in some of my projects. i didn’t have a specific rationale for not using them in Rover, except it’s more CAD work in my particular CAD program. But they can be nice! Rovers gears certainly do make some noise.

Which material are you using the print the gears?

PETG. Specifically it would either be Hatchbox PETG or PushPlastic PETG.

I'm very new into 3D printing scene, so far only been printed with PLA.

Also have some ideas that includes some motorised parts with gears. Do you think PLA is a bad choice for this?

For gears in general PLA is fine. If they have a lot of friction they will heat up and that’s where the PLA could fail. But PETG is very easy to print with! You’d need to adjust nozzle and bed temp but it prints very nicely. :)

PLA is fine to start with though. If you see failures you can switch.

Have you considered fibre reinforced plastic? I'm not an expert but I'm curious if that's a good option.

I’ve seen fiberglass reinforced nylon gears used with success in commercial injection molded gearboxes. It can definitely help by increasing gear stiffness.

However 3D printing with fiberglass causes rapid nozzle wear, and recently people are saying that fiberglass reinforced 3D printing filaments represent a human hazard.

Since I’ve managed to get my gears to work without reinforcement, I’ve not tried it.

One thing I do with printed gears is make the gear teeth much larger than would be strictly needed in an injection molded solution. This lets me deal with reduced material performance compared to injection molding.

You might be interested in resin casting technique. It gives amazing results. Lcamtuf wrote a whole series about this:


and very nice article for make zine:


Have printed many spools of CF and glass filled nylons using nozzles with tips made from ruby.

Check out “Hardcore Ruby” nozzles, now there are even diamond nozzles.

I print with 0.25mm nozzle in nylon, fine enough for Module=1.5 teeth.

A 0.15mm nozzle would make an acceptable Module=1 gear I would guess.

Yes I’ve seen ruby nozzles. Expensive though.

I actually print with a 1.2mm nozzle as I want to print big parts. I’ve even got the e3d Supervolcano hot end. :)

The most important section is on involute curves. It's the curve formed by unwinding a string against the circle:


It creates a constant angular velocity ratio at all points where the gears mesh (the law of gears).

In layman's terms, the tip of the tooth gets thinner so that the angular velocity there is reduced at that larger radius. Otherwise the gears advance/retreat as they rotate, which creates vibration.

I think there might be a whole host of curves that work for this, the other main one being a cycloid, which I'm not really familiar with:


I first learned about involute curves from a cousin that works as a machinist. Mr. Wizard also blew my young mind with noncircular wheels:


Edit: stumbled onto this technique to make involute gears in CAD:


If someone has a simpler method, I'd love to see it.

Well, I think the parametric formula for the involute of a circle is (1-it) exp(it). If you pop open Python with Numpy you can say

    t = np.linspace(0, 1); (1 - 1j*t) * np.exp(t * 1j)
And that gives you almost a radian of the involute, unless I've screwed something up. You can evaluate that at the desired number of points, clipped to the desired range of radii, export the coordinates to CSV if necessary, and import them into your CAD program as a smooth polyline. For example, with FreeCAD, you can directly script it in Python and https://forum.freecadweb.org/viewtopic.php?t=27866 Draft.makeBSpline will apparently do the job. Blender should be similar.

To me this sounds simpler.

I wrote a CAD package in Go that has a function for it.


  func InvoluteGear(
   numberTeeth int, // number of gear teeth
   gearModule float64, // pitch circle diameter / number of gear teeth
   pressureAngle float64, // gear pressure angle (radians)
   backlash float64, // backlash expressed as per-tooth distance at pitch circumference
   clearance float64, // additional root clearance
   ringWidth float64, // width of ring wall (from root circle)
   facets int, // number of facets for involute flank

Cycloid gears are used in roots-style superchargers. I learned about the shape back in college when I thought I was going to build one from scratch.


Geartrax software, it will draw perfect involute splines.

Wow this is great OP! If you like this check out http://507movements.com/ - an animated webpage of 507 mechanical movements with descriptions from a classic book.

I'm sad to say it took so long to occur to me, but I believe 507 was what introduced me to the concept that it's levers all the way down.

Came here to post that link :)

Nicely done. Reminds me of https://geargenerator.com/ which I used to build gear systems for fun.

Also Matthias Wandel's gear generator


I didn't know anything about gears until someone filed an issue to tell me that a graphic on the Caddy homepage was wrong: https://github.com/caddyserver/caddy/issues/2949

Wish I saw this earlier!

It's funny how often that happens. A favorite example: https://en.wikipedia.org/wiki/Two_pounds_(British_coin)#Desi...

In case anyone else couldn't tell from the image and didn't want to read all of the history:

> An oddity of the design is that it depicts nineteen interlocking gears. Because there is an odd number of them, the mechanism could not actually turn.

That's not the case for the two pounds though. In the coin's situation, it's because the three gears at the top are interlocked and jammed.

For me, nothing beats the mechanical calculator used to calculate torpedo firing solutions in WWII. It was a sophisticated differential equation solver that kept a real-time updated firing solution using ... gears.

There's a whole maintenance and operations manual beautifully scanned here[1]. I've wanted to build one forever, but lack the time and expertise.

1. https://maritime.org/tech/tdc.htm

I am interested in differential analyzers too, especially after the anecdotes in Richard Hamming's Learning to Learn (aka Hamming on Hamming)[1] about re-purposing "gun directors" to solve engineering problems.

Some of the mechanisms involved are really elegant, like the torque amplifier[2] which wasn't invented until the 1920s. A tabletop demo of one is on my to-do list.

[1] https://www.youtube.com/playlist?list=PL2FF649D0C4407B30

[2] https://en.wikipedia.org/wiki/Torque_amplifier

The same sorts of things were built using analog electronics.

And even these have fallen by the wayside to digital electronics.

In college, one of my lab courses required us to learn manufacturing techniques. We covered a wide range of methods for machining and shaping things, all out of metal.

Making gears was interesting, we had to first turn a rough blank of metal on a lathe to make a steel gear blank (about 12cm in diameter and 2cm thick) then drill out the center and broach a keyway for the axle that would go through the gear. This was all pretty straightforward, but the final piece of work was more difficult, it was cutting the teeth of the gear. The teeth of a properly made gear require complex shapes.

There are, as I recall, two ways to cut the teeth. Hobbing uses a helical cutting head turning on an axis that is roughly perpendicular to the axis of the gear. The cutting head and gear turn at the same time in a synchronized manner and the teeth are eventually cut out by the cutting head. See [1] for a video of a large complex gear being made this way.

The other method, broaching, uses a straight bar of tool steel that has thick straight across cutting teeth. The bar is pushed past the disk shaped gear blank. The cutting bar moves in a straight line parallel to the axis of the gear blank. Repeated passes over the gear blank cuts out the spaces between the gears teeth.

Master machinists taught us how to make these kinds of projects. They would produce a finished gear in about 15 minutes of instruction; then we would have something like two weeks to make the gear. They made everything look easy; it definitely wasn’t easy for me.

[1] https://www.youtube.com/watch?v=0rnTh6c19HM&feature=share

I'm going to add very little to this discussion, but it's the second article from this blog I've seen here, and - like the other one, about the Earth and the Sun - it's absolutely amazing. This is some of the finest work in "explorable explanations". I'm going to save the copy of both just to be sure to show them to my kid in a couple of years; this beats any educational material on the topic I've been exposed to before.

It is indeed great, and probably one reason you don't see it more is that it's a ton of work! That's 5K lines of hand-written code! (view source and it's at the end of the page)

    $ wc -l gears.js base.js 
     4135 gears.js
      904 base.js
     5039 total
I've wanted to make visualizations like this for my blog. Writing a blog post takes me around 10 hours, which is a fair amount of effort.

I believe that the visualizations will take more time than writing in general -- i.e. it would be more like 20 hours, bringing the total to 30.

If you consider that it's 4K lines of code (assuming the base library is reused), it's very easy to see that it could take 20+ hours. Probably more like 40-80 to be honest.

I guess there is that other thread that says people only write 10 lines of code a day, which would make it 400 hours ;) I don't think that applies here but it could be closer to 400 than 10 or 20.


I also wonder if you can save time by using a less "hand-written" style (e.g. d3.js, which seems to be on everyone's wishlist to learn).

My inclination is also to go "hand-written" rather than using a bunch of JS libraries. I think you get a better result that way. It's interesting to see that I'm not totally wrong -- the thing everyone praises ends up being very hand-written. And it's smooth and fast, etc.


another edit: I also believe one reason that this visualization is good is because there's no build process in the JS. The author clearly just edits the code and refreshes the browser. You need that kind of fast edit-view loop to make good visualizations.

IOW, consider using plain JS for blog posts. They are documents and not apps.

Having been down this road, yes, it does take time, but you can save some time by using SVG and some DOM library. Although canvas is faster, most diagrams don't really need it, so I use SVG unless I really need to switch to canvas. SVG also adjusts for screen dpi automatically.

The things I like:

1. Reactivity (ObservableHQ, Vue.js, hyperactiv.js, etc.). There's usually some underlying data and then a corresponding visualization. These reactive systems let you modify the underlying data and then the visualization updates automatically. You don't have to figure out which diagrams to update when. Even easier: just redraw everything every time you change anything.

2. Some easier way to write the DOM (d3.js, jsx, vue, lit-html, etc.). Since I'm writing a blog post with html, I usually prefer writing my js-in-html (vue) rather than html-in-js (jsx) but try both directions and see which you prefer.

3. No build step. This is especially important when I want to update a page years later and don't want to figure out which build tools I was using in 1997 or 2007 or 2017. I want my pages to last for decades, and I still update my pages from 25 years ago.

I tried recreating one of the gear page diagrams in ObservableHQ https://observablehq.com/@redblobgames/unwind-circle-example . It's not a lot of code. There's a slider, there's a loop to generate the lines, and there's the output svg. Whenever you move the slider it recalculates the output.

I admit that I'm not using ObservableHQ much for my own projects because I want more of a "hand-written" style. I used d3.js for my older pages and vue.js for my newer pages. Vue's reactivity and templates save me probably a factor of 2 or 3 over d3.js.

Thanks for these tips -- I've seen your visualizations and it's nice to hear from people who have done it!

It's cool that you were able to reproduce the diagram quickly and in a small amount of code. It looks a bit foreign to me, probably because I don't know much about SVG (or canvas for that matter). And as I understand it Observable is almost another language on top. (I do know HTML, CSS, and JS pretty well, but there's still a gap.)

Do you ever mock visualizations up in a WYSIWIG tool, or do you always use web technologies in a text editor?

Doing it programmatically has advantages when you need to make 30 similar diagrams, as in this post about gears.

But I also feel WYSIWIG tools could help in prototyping to avoid throwing away a lot of code that wasn't properly conceived of. That is, implementing the visualization is only part of the huge amount of work; the other part is designing it of course. And in many cases the design effort is probably larger.

For example, I have wanted to write an article about regexes, visualizing NFAs and DFAs. I find that some programmers have trouble with the idea of nondeterminism, which is more of a mathematical thing. A subtitle would be something like "A trie is a special case of a DFA".

This post has some nice diagrams, and you can easily imagine them being interactive and more approachable:


(in fact a few months ago else I posited that a textual summary of these great but dense posts would be useful too)

I can sort of imagine what I want to visualize, but I also think there will also be many false starts. Though maybe a pencil and paper is sufficient. I'm not sure I will get to it, but this polished and smooth gears post got me thinking again! Using something reactive like vue rather than doing it "vanilla JS" is also probably something I should look into as well.

SVG is declarative. You write <circle cx=300 cy=400 r=100 fill=red/> to make a red circle at (300,400) with radius 100. You can then change any of these properties and the system will redraw automatically. Canvas is imperative. You write ctx = canvas.getContext('2d'); ctx.fillStyle = "red"; ctx.beginPath(); ctx.arc(300, 400, 100, 0, 2 * Math.PI); ctx.fill(); and the system will draw that circle. You handle redraw yourself by redrawing everything on that canvas, so you need to keep track of it all. The DOM helpers (React, Vue, etc.) help you with SVG but not with Canvas.

I usually mock visualizations on paper! I'm interested in using WYSIWIG interactive diagram tools like http://aprt.us/ but I never seem to get into them. When I started, making the visualizations was the largest part of the work, but now I've gotten better at it, and making the explanation is now the part that takes the most time.

After paper, I often use SVG to make a non interactive diagram, either by hand, or in inkscape. One of my guiding principles is that the page should be usable without interaction, so the static diagram is a test of that. If it looks promising I can then gradually transform it into an interactive diagram. For example if I had the circle above, and I am using vue.js, I can change it to <circle :cx=x :cy=y r=100 fill=red/> (note the ":" before attributes), and then vue will fill those values in from the object I give it. I can give it {x: 300, y: 400}, and any time I change x or y, it will automatically redraw. I can then hook up x or y to a slider to try out the interactivity. This allows me to start with a static diagram, gradually add interactivity, and then build reusable abstractions that I can apply to multiple diagrams. ObservableHQ and React/JSX allow something similar, with slightly different syntax.

I'd love to see an article about regexes with interactive diagrams. There's a standalone diagram tool https://regexper.com/ and an interactive tutorial https://regexone.com/ but neither is an essay in the style of the Gears article. If you're pursuing this, let me know at redblobgames@gmail.com and I can send over more resources.

Observable is amazing! Some time ago, I prototyped half of the 2.0 version of a company's product in it in a scope of a few days; that's how nicely the notebook interface and reactive programming fit together.

I didn't realize Vue can work without a build step; that's actually great. While I so far avoided using any JS on my tiny little blog, I'd really like to do some interactive explanations. I'll check this workflow out. Thanks!

Last but not least, I'm a great fan of your articles! Keep up the great work!

Observable's templating is directly inspired by lit-html, which also works without a built step, and works great with SVG.

Thanks for sharing these tips! I didn't realize you were trying out ObservableHQ too.

I love ObservableHQ! I think it's a neat model that fixes a lot of things I didn't like about notebooks. I don't use it much though. It makes the simple things easier but it makes the complex things harder. Examples:

1. I often start making a diagram interactive by adding a slider connected to some state. The slider/state is in one "viewof" cell and the diagram is in another cell. But for more polished work I often want to use direct manipulation, where you move something around in the diagram itself. In my usual JS+Vue code it's a small amount of extra work. But in ObservableHQ it seems like a lot of work: the diagram has to modify state defined in a different cell (breaking the simple spreadsheet model in my head), and the diagram is being re-rendered while it has event handlers active.

2. I often start out by making one diagram. This is nice and easy. But then I want to make multiple diagrams with some shared state. In my usual JS+Vue code I can lift the diagram code into a function, pass in a shared object for shared state, and instantiate objects for non-shared state. In ObservableHQ those properties are in cells, and I can't generate multiple cells programatically (afaik).

I also would prefer to host things myself, both because of longevity, but also because I sometimes work offline (e.g. in a park or on a train). And the biggest reason I'm not using ObservableHQ is that I'm so much slower editing text on it than I am in Emacs. So I continue to use ObservableHQ for some simple projects/prototypes but I don't do a lot with it.

Yeah, the centralization aspect is a big turnoff for me. I'd thought about the direct-manipulation issue (the rather crude visualization of skeletonization I linked below benefits a lot from it) but not the multiple-projections problem. Can't you put the entire state in one cell and then create multiple cells that render some reduced dimensionality projection of it? Or do you mean that there's no way to factor out the aggregation of three such projections into a reusable unit?

I recently walked my girlfriend through your explorable on populating landscapes with Perlin noise btw. It was great.

Writing a small program takes much less effort per line than writing a large program, especially if it doesn't have to be maintainable and extensible, especially by other people. http://canonical.org/~kragen/sw/dev3/circlegrid.html only took me three hours of JS hacking, and it's like 200 lines of code. The simplified version of the basic COCOMO model in David A. Wheeler's "SLOCCount" is Person-Months = 2.4 * (KSLOC1.05), which suggests a budget of 0.44 person-months for this code, about two weeks, which is clearly too high; we've all written and debugged a few hundred lines of code in a day on some occasion after getting out of the larval stage. This probably would have been faster if I hadn't been so out of practice with DHTML.

Another thing, though, is that some things are easier than other things. Usually in a programming job you have to do the easy things and also the hard things. This brings down the average. If you're writing a bunch of blog posts for fun, though, you can just publish the ones where good visualizations came out pretty quickly and discard the others that are much more effort for less return.

I feel like visualizations using d3.js are still pretty "hand-written".

That's true, and like everything I'm sure writing JS visualizations gets faster with practice, and you become more familiar with the tools.

Still, after finishing the article, I'm impressed by not just the the number visualizations, but by their legibility and smoothness. I can't in any universe imagine it taking less than a week of full-time work. If you told me it took a month of full-time work I wouldn't be surprised at all.


I liked this concept of "interpretive labor" and that's what I'm really getting at:


There’s a tradeoff between the energy put into explaining an idea, and the energy needed to understand it. On one extreme, the explainer can painstakingly craft a beautiful explanation, leading their audience to understanding without even realizing it could have been difficult. On the other extreme, the explainer can do the absolute minimum and abandon their audience to struggle.

I've been writing for public consumption for about 3 years and really feel that tradeoff. When I put effort into some writing or explanation, the result is better. People tell me it clicked, etc.

And I would say you can go a lot further than you think in bridging the gap. This article is evidence of that! Lots of people here are saying they wished they had this in high school, etc.

3Blue1Brown's videos are another example of that. I was fairly good at math in high school but if those videos existed then, I would have probably gotten a lot further.


This ties in nicely to your Dercuano notes which I have had open in my browser for awhile! There are many interesting topics there. But I also feel like you went to the other extreme and there's a lot of interpretive labor involved in reading them :)

Why did you decide to polish and publish the "memory models" post? I'd like to see more posts like that. (I could send you the notes that jumped out at me if interested.) Whenever I've taken the time to polish some writing, I've never regretted it. For some reason it feels annoying to start (probably because I have to clear my brain of other things), but when I'm doing it it's fun, and when I'm done, it's worthwhile.

> Still, after finishing the article, I'm impressed by not just the the number visualizations, but by their legibility and smoothness

I think the author probably had to try a lot of things before hitting on such a well-balanced set of visualizations: not too much detail, not too little, not too many degrees of freedom, not too few, usable on hand computers, usable on laptops. But I think that if you gave someone the web page to look at and asked them to make similar visualizations, it would probably take them a day or two.

> I would say you can go a lot further than you think in bridging the gap.

You might be right, but I'm kind of cynical about it. I think it's easy for people to fool themselves into thinking they understand things after seeing a good explanation. Nova on PBS resulted not in rapidly advancing physics from the generation of kids who grew up watching it, but instead Deepak Chopra and The Secret — the fruit of the illusion of fluency without the corresponding skill.

Worse, the educational system is in many ways optimized to promote the illusion of fluency. You have textbooks of the variety Feynman complained about, with the wakalixes. You have semester-long self-contained courses, discouraging spaced learning. You have pre-announced big-bang exam dates for those courses, so students game the system by cramming to get better grades. In many cases you have multiple-choice tests to make grading easier, so guessing the teacher's password is the highest-return gaming strategy, even if often insufficient by itself. The whole educational experience is compressed into a degree program of four years or thereabouts, further discouraging spaced learning. Students rarely attend any classes they aren't getting credit for, even though this is technically permitted at most universities I've visited. It's a commonplace observation that students forget almost everything they "learn" within a few years. So the idea students get of learning is very different from what learning is; schooling systematically distorts their ability to evaluate whether they are learning or not. (Paul Graham has explored this theme from a different angle in http://www.paulgraham.com/lesson.html as well.)

How would we distinguish a universe in which this beautiful post on gears successfully transmitted learning to its readers from a universe in which it only transmitted the illusion of learning to them? In both universes the post is popular. In both universes people say things like "I wish I had this in high school!" But in one universe people are able to do things they couldn't do before; perhaps design gear trains for 3-D printing that show up in Hackaday projects, or perhaps laser-cut unusual gear-tooth profiles with different pressure angles or different depthing/ripple tradeoffs or something. But that could take a while, and it might be really hard to trace back. Is there a lower-latency indicator we could observe, even if it's something hackable like school exams?

I don't want to sound like I'm above all this. I feel like I have new gear knowledge from reading this post, despite having read hundreds of pages about gears and watched hours of gears videos previously; it happens to be something I can state, namely that the pressure angle always needs to point at the point of tangency of the pitch circles. But I'm not yet sure if that's really true or what happens if it's false (you can definitely design gears for which it is false). I'd need to struggle with the problem for a while in order to really understand it.

(A different learning effect would be that people learn that posts like this are very popular and make more of them, having been inspired by this one. I'm pretty sure that will happen whether or not people learned things about gears from this post.)

> This ties in nicely to your Dercuano notes which I have had open in my browser for awhile! There are many interesting topics there. But I also feel like you went to the other extreme and there's a lot of interpretive labor involved in reading them :)

Thanks, that's flattering! I'm glad you're enjoying it. Are you using the HTML version or reading the raw Markdown?

> Why did you decide to polish and publish the "memory models" post?

I don't know. I think it was just random chance. I enjoy doing that kind of thing but I don't do it very often. Even memory-models is pretty unfinished and has some parts that are pretty raggedy.

> I could send you the notes that jumped out at me if interested.

Sure, that would be wonderful! If you wanted to commit to commenting on further drafts within some timeframe, that would probably help motivate me to work further on them.


I want to be careful to disclaim a particular interpretation here. In "Real Programmers Don't Program in Pascal" it says, "If it was hard to write, it should be hard to read." I don't believe that. I don't believe that if something was hard to discover, it should be hard to learn. I think we should make learning as easy as possible, and I agree with the post you linked that this benefits from improved explanations, and that improving those explanations takes a great deal of work.

But I have been burned many times even by my own illusion of understanding, let alone those of Freud and Chopra, to the point that I am wary of it. It is well that we remember, as Euclides said, that there is no royal road to geometry; a good tutor can save a student from remaining in error and from failing to notice the importance of something they could learn, but ultimately the student is the one that must do the hard work of constructing the knowledge within their own mind.

I'm with you that there can be an illusion of fluency, but I don't think that casts any doubt on the value of the article.

Most people will read it and say "fun" (including me, since I don't work with gears) and maybe 5-10% will go on to do something else with it, but that's working as intended.

I agree you can't really say you know something without testing the knowledge. You need to do more work to test whether you know it or not, but having the concepts and words at hand is a prerequisite for that. I'm certain if I were to actually work with gears I would come back to this article. (I would probably also learn where it falls short in practice, but I would learn that about any resource AFAICT.)


Testing your knowledge is one reason my brain flipped from math to programming over 20 years. Math is hard to test but programming is easy to test.

However, one thing I found surprising is that publishing tests your knowledge, but writing does not. I would categorize Dercuano as writing but not publishing at the moment.

It tests it in exactly this way:


Blogging is a public act. Anyone can read this. When I write a blog post, I imagine my supervisor, a respected colleague, or a future employer reading my explanation. These imagined readers force me to ask myself honestly if I understand what I am writing.

I found the same thing while writing my posts on https://www.oilshell.org. If someone digs this up in 5 years, is it going to look dumb? And of course simply not knowing something is not dumb, but pretending you know something you don't is dumb (likewise with promising something you can't deliver, which I've been careful not to do).

I can see there are a lot of great ideas in your notes, but I have 100% certainty that polishing those ideas will lead to a better understanding, more ideas, and forcing a focus. The writing alone alone doesn't cut it. (I know because I also have 3382 personal wiki pages with notes and URLs accumulated over 15+ years with overlapping research!)

I would definitely comment on drafts. I was paid to review the second edition of Effective Python last year, and am also reviewing a book for a friend currently, so I have some experience with that. I'm most interested in the posts on parsing, automata, languages, compilers, and (parallel) algorithms -- I have less experience with graphics. I didn't know you were working on HAMMER -- that line of research is also in my wiki pages and I have several thoughts about it. I'll send you a mail with the ones that jumped out at me.

I've responded to your email! Let me know if it got spam-filtered.

> another edit: I also believe one reason that this visualization is good is because there's no build process in the JS. The author clearly just edits the code and refreshes the browser. You need that kind of fast edit-view loop to make good visualizations.

You can go a step further and reload code without refreshing the page. This makes it even easier to make the sort of fiddly tweaks that visualizations require while avoid change blindness.



In some cases I've exposed sliders to enable a 60Hz feedback loop on those fiddly tweaks. In other cases Firebug or its modern successors already expose enough.

This. The time and effort it takes to put such a visualization together for a target audience that might possibly just gloss over the content is immense. Its like making a multi-million dollar movie about people who have no money just to show thier situation. Instead of giving them the money directly. And on top of that you need all the requirements to actually be able to view it in the latest browser.

I can't quite remember what the software was, but I vaguely recall something in school that we used to explore various topics in physics which used an approach very similar to this. Literate text with interactive diagrams and input variables.

It wasn't web delivered and was a Windows, perhaps Win 3.1 application. This was in mid 90s

In addition, his page lead me here http://archive.is/S01gX Start at "The little gears that couldn't." section

PS: had to archive the link because of SSL errors prevent direct access. my guess - my browser had old number of gears :P

This was simply wonderful, and hidden at the bottom was a link to an insect named "Issus coleoptratus"[1] which evolved something like a biological gear for synchronizing its legs.

As an almost complete aside, in Terry Pratchett's "Last Continent" there is a God of Evolution that comments on how difficult it is design a biological wheel.

“It’s very hard to design an organic wheel, you know,” said the god reproachfully. “They’re little masterpieces.”

“You don’t think just, you know, moving the legs about would be simpler?”

“Oh, we’d never get anywhere if I just copied earlier ideas,” said the god. “Diversify and fill all niches, that’s the ticket.”

“But is lying on your side in a mud hole with your wheels spinning a very important niche?” said Ponder.

[1] https://en.wikipedia.org/wiki/Issus_coleoptratus

You may find yourself wondering: what would happen if the gears are not circular?

The answer is then they can implement a wide range of mathematical functions like reciprocal, tangent, square etc. and you will get a kick out watching an hour long video about a mechanical "computer" with cams building up differential calculations: https://www.youtube.com/watch?v=s1i-dnAH9Y4


A very cool style gear is a harmonic drive. It has a somewhat flexible inner gear driven by a cam which engages it to the outer gear. It allows for extreme gear ratios with high torque in very small packages (think helicopter pitch control).


Very cool! It looks like the output shaft has quite a bit of lateral movement, perhaps something like a Schmidt coupling (https://www.thingiverse.com/thing:233667) could be used to remove that movement and allow a fixed output shaft.

I last saw one of these inside an IBM 3890 check reader machine.

The whole blog, really. Someone throw money at this person to write science texts full time.

Imagine if we could revamp the textbook industry so articles like this have a fighting chance of being included.

If only textbooks could be this good.

Exactly. Or put another way, why is there not more pedagogic material like this on the web? We have Jupyter notebooks in many different academic subjects but so many of them are half-baked. This website serves as an example of how good web-based teaching material can truly be.

I think we'll get there. Part of the problem has been ensuring that the content keeps working. There has been so much educational content produced on Flash, Java Applets, and other platforms that currently have no support.

But the "modern web" (HTML5 and javascript) seem likely to last a long time and be supported on many, many platforms. So now we need better authoring tools, because as another comment suggests, not everyone is up for writing 4K lines of code.

That's what I thought, but now more and more features are being disabled either entirely (as with the SQLite interface in WebKit) or for unencrypted sites, which — correct me if I'm wrong here — includes web pages you've archived on your local filesystem. Maybe <canvas> will survive that, despite its use in browser fingerprinting, but camera access and appcache are already nuked, and the only interface that let you do custom realtime DSP on audio streams from an unencrypted origin is deprecated.

Lack of incentive to create it?

Really great interactivity and visualizations on this blog. Check out the other posts too: https://ciechanow.ski/archives/

Cool, really cool. I really wish I could've seen that as a kid. Not asking, but logical next step is to go 3-D with straight-cut gears & helical-cut &c &c.

Anyone else play Gizmos & Gadgets as a kid? I can't help but flash back; I feel like that's how I learned "gearing" (and magnets, and maybe more..).

I played Gizoms and Gadgets. Fun game.

Slightly off topic but it has long bothered me that racing simulations let you pick arbitrary gear ratios in the tranissions and differentials. Real life has two restrictions, you can't have half teeth, and you can't have huge teeth count. A 3.00 ratio sure, 12:36 but a 3.01? No car differential can fit a 100:301 ratio gearset and 10:30.1 just won't turn past the broken tooth.

I'm not a car guy, and I don't know about the differentials, but don't continuously variable transmissions allow for this? I'm guessing they're not in common use on race cars, but in principle, shouldn't they allow for a 3.01 ratio?

Yes, a CVT uses a steel belt around two cones, and can have any ratio between them.

Most race cars use mechanical transmissions with automatic controls as that's the most robust design. Some stunt vehicles use automatics or CVT as landing with the wheels at different speeds than the vehicle causes a massive shock through the drivetrain. In a manual that shock goes right to the engine, in automatics there is usually some amount of absorption of rotational shocks due to the less rigid coupling.

Diffs are almost always a ring and pinion gear.

There should be some tool to make such nice animations easily. Not just gears, but any other illustrations with moving parts with the ability to have a zoomed in detail beside the animation, etc.

You're in luck, such a tool exists! It's HTML and JavaScript. :)

I think you missed the 'easily'.

Well illustrated and explained.

For some interesting, less conventional gears that surprisingly still function, checkout out How To Make Organically-Shaped Gears:


I have a dumb question about this. Under the header 'Torque', where the wrench is introduced the first time, the length of vector F is non-linear with the position of the slider; in other words, the curve you see (that of the length of F) is not straight. Why is that? Torque is distance times force, where is the non-linear component? The article goes on to talk about the angle of the force, but that isn't relevant in that graph yet, is it? (meaning, that graphic seems to suggest we're talking only about a force perpendicular to the wrench?)

Torque = distance×force, so force = torque/distance, so force is linear in 1/distance.

Thanks, that makes sense. Once you start thinking about it, it's obvious (e.g. F can never go to 0), turns out I've always had a wrong mental model of how the length of a lever influences the torque (beyond 'longer lever = more torque' of course).

Loosening a bolt gets easier as you turn the wrench, no? I assumed thats what the diagram was showcasing

Yes, but my idea was that pushing the wrench at distance x is double as hard as pushing it at distance x * 2; my understanding of the diagram is that it's not.

I am learning about car mechanics as a hobby. How a car works is a nice learning site. [1]

Just learned about starter motors today. I didn't know it has gears too, in particular the planetary gear system, which is not mentioned in this tutorial. (I quickly skimmed through)

[1] https://www.youtube.com/watch?v=VRe_hKxzKUg&t=1094s https://www.howacarworks.com/

Nicely made. And as soon as the fan appeared my cpu fan started to spin like crazy. It felt real

Now it needs to be 3D and a smell generator that emits grease odor and you will have a full 5D experience!

Digital scent technology: https://en.wikipedia.org/wiki/Digital_scent_technology

These interactive animations are so well done.

If you're interested in the machining/making of gears there's a youtube channel where a person makes clocks and other timekeeping devices (some of ancient designs). It's fascinating to watch, and makes me want to get a metal lathe/mill someday.


Clickspring's work on the Antikithra mechanism (and the Pateron exclusive Byzantine Sundial) is particularly interesting, because not all of the movements created by gears are circular or even. The input can be purely rotational, but the output is not.

For example on the Antikithra mechanism, it has to account for the procession of the moon's orbit which causes an uneven time to complete one orbit. To properly simulate this, a pin-and-slot system is combined with an offset pivot to turn the rotation of gears into a movement that lags behind and then speeds ahead, mirroring the actual orbital period.

I worded that poorly; the video does a better job of explaining it (within the first minute), and the rest of the video shows the gear train coming together


This is a great learning resource. I just found tec-science the other day and I agree with the author that it is worth to take a look, as they have some excellent visualisations. https://www.tec-science.com/mechanical-power-transmission/ge...

This is wonderful and I can't wait to go through his other articles.

It reminded me a lot of: https://acko.net/blog/animate-your-way-to-glory/

Nicely done! It kind of reminds me of this old video: How Differential Steering Works (1937)


I love this video. It's such a great visualization, simple and clear, and gets the point across while being entertaining.

And it's from 1937! We have so many video editing and effects tools today, but sometimes simpler is best.

This may be a stupid question, but it is something I always wondered.

Torque is effective due to the mass of the lever having a force applied to it, right? Is the length of the lever being used as a stand-in for the mass being affected (a longer lever would necessarily have more mass)? If the lever had no mass, would there be no torque? If the lever did not have a uniform mass distribution, would the difference in applied torque differ based on where on the lever you applied the force (is the derivative of torque with respect to mass not constant for a non-uniform mass distribution)?

Nope, the mass of the lever doesn't play in to the torque that is applied at all. All that matters is that the force be transmitted via atom-to-atom motion. It's the rigidity of the wrench that mediates that, not its mass.

Of course, to create rigid objects, practically speaking they need to be made of something that will have mass. So the rigidity and the mass are related in a very loose sense. In any case, from a Newtonian physics perspective, you'll see none of those terms in there - neither a "rigidity" nor a mass. The torque is simply the length of the wrench multiplied by the magnitude of the force.

In a more detailed analysis, you might consider the flexure of the wrench by analyzing the stress and strain inside the wrench. That would no longer treat the wrench as a perfect idealized body that is completely rigid, but rather a body that can stretch based on the internal compressive or tensile forces that arise inside of it. Sometimes we don't think of metals as being stretchy, but with enough force, they're not so different from a rubber band.

With all that said, once you consider the _dynamics_ of the situation - how the forces applied give rise to motion - then mass does come into play. If you apply torque to a wheel, that will cause an angular acceleration proportional to the mass of the wheel. If you were using a wrench to spin a gear, then the mass of the gear decides how fast it will start to spin. Also, the mass of the wrench matters here, since presumably it will be spinning too: some of your effort has to go into angularly rotating the wrench. So it would have a "parasitic" effect on how fast you could get your gear spinning.

The mass of the lever just adds or subtracts from any other external force(s) applied to the lever - depending on the direction of the external force relative to the direction of gravity.

So a heavy wrench is helpful when pushing down, while loosening a rusty nut. But a light carbon fibre wrench would be better when pulling up.

How much torque gravity adds or subtracts in that case is also dependent on the distribution of mass along the length of the lever.

And to add to the fun, the mass of the leaver does add momentum into the equation, which comes into play as extra work required when changing speed of the rotation (e.g. starting, stopping the turn). And how much momentum also depends on the distribution of mass along the length of the lever.

No, the mass of the object that has a force applied to it has absolutely nothing to do with the torque.

Here is how Wikipedia defines the torque caused by a force acting on an object with a rotation axis: Torque is the product of the magnitude of the force and the perpendicular distance of the line of action of force from the axis of rotation.

So the force generated by the torque is completely unaffected by the mass of the lever? Then, why does applying the force on a longer portion of the lever create more torque? I had thought it was because there is more mass acting on the point of rotation (longer lever = more mass).

> So the force generated by the torque is completely unaffected by the mass of the lever?

Yes, that's right.

> Then, why does applying the force on a longer portion of the lever create more torque?

Most of the answers to this question reduce, upon examination, to "that's how we define torque". We define the torque of 100 newtons at a lever distance of one meter as the product of 100 newtons and a meter, which we can call 100 newton-meters, which is equal to 1000 newtons at a lever distance of 0.1 meters.

But that doesn't really answer the question, which becomes, why is torque defined in this way an interesting thing to think about? And the answer is that if the lever is a rigid body free to rotate around a fulcrum, then 100 newtons at one meter in one direction will make it start to rotate, while 1000 newtons at 0.1 meters in the opposite direction will precisely cancel that "moment", as we call it, and there will be no tendency to start rotating. It's about what forces are needed to cancel each other.

Well, but, why should that be? Why does it take exactly 1000 newtons and not, say, 316.2 newtons? And I don't think I have a really good answer for that question. In the case of an elastic solid body it falls out of Hooke's law and the geometry of the situation, which you can reduce to two long, skinny triangles sharing a common side bisected by the fulcrum. But it seems to be much more general than that.

> I had thought it was because there is more mass acting on the point of rotation (longer lever = more mass).

Nope. You can try using a pair of scissors or a folding ladder as a lever, or pull in different directions on the end of a fixed-geometry lever. The lever's mass doesn't change, but the leverage certainly does.

A generalization which applies to levers, pulleys, and hydraulics is mechanical advantage while conserving energy. You have a system with input work and output work (energy) that are the same, ignoring frictional losses.

Recall that work is force over distance. The mechanical system relates the input and output distances by a scalar coefficient. Since the working distances are related by a ratio, the working forces are related by the reciprocal of that ratio.

You can find the lever and fulcrum ratio with simple geometry. The input and output lever segments are radii, and the travel is distance along two arcs. Since the arc length is directly proportional to radius, the ratio of lever radii translates directly to the same ratio of arc lengths, and the reciprocal ratio is the force multiplier. Your 10:1 lever sweeps 10:1 arc lengths and balances with 1:10 opposing forces.

Yes, that's an excellent point, but I think the lever law is more general than that. For example, it continues to apply when the lever in question is stationary, even though no value of the forces involved would violate conservation. In fact, it holds to higher precision in that situation because your measurements aren't confounded by vibration and accelerating masses.

Maybe you can derive it from some kind of generalization of Hooke’s Law to cover nonlinear stress–strain relationships, elastic hysteresis, anisotropy, viscoelastic behavior, and so on, but it's not obvious to me what that would be. Also, I feel like the concept of angular moments acting to produce angular acceleration is simpler and more general than all that stuff, but I'm not sure if conservation of energy and geometry alone are sufficient to derive it.

> So the force generated by the torque

Torque is nothing more than "spinny" force. For example, sometimes you will see the term "generalized force" to mean both force and torque, because it doesn't really matter in some contexts. For example, if I have a robot arm that has some linear joints (like that of a 3D printer) and rotational joints (like that of an arm), you can talk about the generalized forces of each joint. Some of those generalized forces are linear (and people call that "force"), and some of them are rotational (and people call that "torque").

They are exactly analogous to (linear) velocity and _angular_ velocity.

When you talk about force _generating_ a torque, the only thing I can understand is how the linear velocity at a point on a disk (say you blow across its surface) _generates_ an angular velocity.

It's the distance that matters. If you push a car it will speed up. If you push it twice as far it will speed up more.

If you apply the same force using a longer lever then the end of the lever moves further (it follows a bigger circle) so you are applying the same force over a bigger distance.

No, torque has nothing to do with mass. Even making the level "massless" would not change the applied torque one bit.

I think that the only role the mass of a lever would play in contributing to torque is through inertia.

Seymour Papert writes in the introduction Mindstorms about he was fascinated by gears as a child and spent much time playing with them, and what he learnt through play provided a valuable intellectual foundation for learning many elementary and advanced ideas in mathematics.


I am super impressed by the smooth animation and the graphic design of the elements.

I wish this were all open source so I could just copy it in to a project I’m in the middle of.

Very inspiring.

There are 30(!) different animations on this one blog post alone.

The work he put into this is admirable. A great education tool.

That gif at the top reminds me of an IQ test I took in 6th grade. There was an entire section where they would show you a sequence of gears and tell you what direction one of them was spinning. Then they would ask you what direction some other gear was spinning.

They all looked like that first gif (but not animated of course).

Seymour Papert's childhood (cf. "Mindstorms" [1] introduction) obsession with gears sprung to mind.

[1] http://worrydream.com/refs/Papert%20-%20Mindstorms%201st%20e...

Maybe I’m misremembering but isn’t torque usually expressed as a cross product of force and radius?

(Making pound-feet the pedantic but correct phrasing of the colloquial “foot-pounds”)

That way the torque vector points in the direction that a screw would move if you turned it in the direction it’s being forced.

That is the correct way to express torque with vectors.

The definitions in the blog post are not vectors, they are scalars and the dot is not a dot product, just multiplication. (F_t there is what is commonly notated as F_perpendicular). I agree it is confusing to those of us used to seeing bold letters usually used for vectors (and I would argue that using more conventional notation at even a basic level is better), but it's not wrong.

This is Also a very helpful GIF how a gearbox in a car works


Bravo for the author for such a captivating interactive blog post. Works great on mobile!

This is great! The visual representation of rotation speed at each point makes a confusing subject much clearer. Is anyone familiar with the gear wars? I know it wasn't all about the gears, but I would love to get more insight into it

This looks pretty fantastic on mobile. Nice and responsive. Great animations. Good job!

Works fine with noscript and ublock active.. wish all sites played this well

This is very well done. Interactive textbooks should look like this.

I would need additional proof that gears were designed with many of these mathematical considerations in mind and didn't just arise out of trial and error by the machinists

Wow!. I always blank out when my MEs talk to me about Gear ratios and TOrque when designing Electro mechanical systems. This is really helpful. Thanks for making this.

Oh my! These animations are sooooooo satisfying to look at!

This is a really awesome article and brought me back to intro physics class, saving it and will return to it in the evening so I can fully digest :) Thanks!

https://youtu.be/Q-XOM4E4RZQ An awesome video on making gears.

This is beautiful. Great explanations, and a really powerful interactive website. A really impressive and engaging page to pull it all together.

The writing and interactive examples are really amazing. Would deffo read the entire series of articles. Gonna bookmark it.

Very nice!

These animations are running in a <canvas>.

Any idea what the author used? Is everything produced with math (eg: a gear solver, etc)?

I was wondering the same!

The author appears to be using his own functions written in vanilla JS. The Gears page loads a custom Canvas library base.js [1] plus an page-specific gears.js [2]. iOS graphics appears to be an area of expertise [3] for the author.

[1]: https://ciechanow.ski/js/base.js

[2]: https://ciechanow.ski/js/gears.js

[3]: https://github.com/Ciechan?tab=repositories

(P.S. <canvas> is an interesting choice, I had expected <svg> before opening the page inspector. Separately, I love the creative use of TLD in the domain name.)

Thanks for the JS files.

Would be nice to know about his process.

Here it appears he is importing the graphics from somewhere else converted to imperative drawing code:


That's just a function that draws a spanner.

Obviously, but my point is that if you look at the coordinates these do not seem to have been handwritten.

That diagram with the wrench and force increasing as the radius decreases should be linear.

Great article. How did you make those images with sliders? Any tool or library you used?

High quality content. Thanks OP!

I remember learning gear size ratios in sixth grade math class with special LEGO sets.

Must have been an insane amount of work to put this together - well done!

This is incredible, and apparently every other post on that site is too.

i'm so happy for the global pause button in this article

> The considerations behind real world gears are much more complicated than what I’ve presented

Nah... Nah I would say you pretty much nailed it in this blog post! Incredible. HN Gold right here.

How are these animations implimented?

Incredible. Thanks for posting this.

Cute explanation; Thank you;

This is a beautiful article.

This is a beautiful article

Can you 3d print gears?

Absolutely, they even work for a while.

The Youtube channel "Gear Down for What?" has some pretty cool planetary designs.


Why only for a while?

Hi guy so thx

Amazing work!

Lovely work, thanks!

The illustrations are what draws attention and they are very nice and informative.

In context of parallel HN discussion¹ on merits of animated SVG, I consider it a loss for open standards that these animations are not made in SVG. If you try to inspect this page, the design and animation is hidden behind canvas and some (nicely written BTW) imperative javascript. It is hard to replicate, and hard to compose with other elements. The illustrations are completely white when disabling JS, which is less than ideal graceful degradation. Some people would argue that executing custom scripts should not be required to show animated graphics, even if it includes basic interactivity.

For comparison, visit this page² and try to 'inspect' animated graphics. Observe the SVG element in DOM and see how it changes when you scroll. Just by spending few minutes exploring you could probably recreate them, or at least reuse them somewhere else. We still don't see what's driving the animation (also JS), so that could still be improved using SMIL, but there is obvious benefit for using SVG here.

Don't take me wrong, it is really a nice article with very pleasant and clear animations. I'm merely speaking from perspective of open standards, and technology stack that provides good foundation for building complex illustrations. The author is not to blame here, as we lack decent tools for declarative graphics/animations.

¹ https://news.ycombinator.com/item?id=22297461 ² https://www.opencrux.com/

It's really funny you mentioned the other discussion because that's what I immediately thought when I looked at this page: that's a great use of SVG animations.

It's why I made this comment in response to a UX designer (many people on the thread seem to think that SVG animations are mainly for animating UX components): "There are whole worlds of use-cases outside the very restricted design paradigm you're describing."

> The author is not to blame here, as we lack decent tools for declarative graphics/animations.

Please show me the pure SMIL declaration for a pixel-exact replica of the example from the wonderful article: number and size of teeth on a spinning gear scales based on the horizontal position of a draggable slider.

On a related note: this wonderful article is an article. The next time an HN article about web complexity triggers another HTML Class of 4.01 Reunion, it would be great if admirers of this article would post the link and force them to reveal the true depths of their asceticism.

I think I win either way. If there really is an SMIL solution then then the 4.01 grumps would be forced to backport declarative graphics/animation into their nostalgia. If not, then my point stands.

Can you explain what is it that you win? Because the current state where it takes a talented programmer + mathematician + designer to create this kind of content is loss for everyone.

No, SMIL on its own cannot replicate these illustrations. I hope that some future standard for declarative reactive graphics will be able to.

I personally disagree with people who disable JS and expect the web to continue working as expected, but one of the other downsides of using Canvas for such animations is that there is no good way of exposing that animation to screen readers. Some projects get around this by having an accessibility layer in DOM that overlays the Canvas which renders the actual animations (e.g. https://proxx.app/), but I imagine that a11y animated SVGs would be a better approach here (if they were easier to create).

> I personally disagree with people who disable JS and expect the web to continue working as expected

In a general sense, I agree with you.

But pages that are generally static, like a blog or news article, should still work.

I think it's completely reasonable that the animations in the linked article break with JS disabled. Could they have been done differently and had graceful degradation? Yeah, I suppose. But I think it's fine as-is.

It's easy to lose track of in the face of scene graph vector formats like svg but you have to remember canvas + javascript can be thought of as a procedural cad system, that is, the epitome of drawing tools.

The svg is a static weak alternative to true procedural generation.

For reference the postscript language is the same way. hand written procedural postscript is an amazing drawing tool.

The diversity of topics, hand-crafted graphics, and quality of explanation on all the posts on this blog remind me a lot of Andrew Glassner's columns from IEEE CG&A. Really delightful work (in both cases).

This is awesome. I wonder if the author could be convinced to participate in a similar discourse on the subject of gears, as they relate to audio synthesisers?

Pretty much all the modern synths these days have infinitely lubricated gears and pulleys in them, pushing those speaker cones/amp inputs ..

For the author: adding support for touch events, or using normal HTML sliders would be helpful.

Curious: does something not work for you? If so, what platform are you using? Asking because it works perfectly for me on mobile...

I was on a Chromebook with a touchscreen. Maybe you do "platform detection" and don't register touch handlers on laptops. I haven't looked at your code (I didn't see a repository link and I didn't bother looking further).

Cheers on the cool demos, I think it could be the start of a great resource for elementary school teachers introducing machines. I know this sort of thing would have been great when I was in grade 3.

Sorry, I didn't mean to imply I was the author - I was just curious what failed. Thank you for the explanation! I agree that OP made cool demos. :)

> Almost by definition, the second hand of a clock rotates at 1 rpm

Minute hand, surely ;)

The minute hand would be one revolution an hour.

Hoist by my own petard!

The minute hand rotates at 1 revolution per hour ;)

Second hand: 1RPM

Minute hand: 1RPH

Hour hand: 2RPD

> Hour hand: 2RPD

Joke's on you, I have a 24 hour clock!


While I appreciate the beauty this piece, I can't help but think of the irony of such a complicated piece to explain something which mechanics and engineers, who actually use gears, understand completely intuitively.

Why is it ironic? The target audience clearly is not mechanics and engineers who actually use gears.

I had the same feeling, hoping to receive an epiphany, perhaps on the bevel of the gear teeth, but nope. Then I thought, ok, surely there's an insight to be gained regarding helical gears, but it was never discussed.


I'm not sure this is intuitive for many mechanics. I can remember studying for the ASVABs in high school (it has, or at least it did, have a whole section on spatial orientation and gears and pulleys), and it was pretty common for people to be flummoxed by the questions about picking which direction a gear in a set would turn when another was rotated. And this was with a set of people that tended to tinker on cars and snowmobiles all the time for fun.


If I don't post it someone else will. Here's the spinning levers video you've all already seen a million times:


It's been posted on HN a few times too, although without much discussion.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact