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.
https://www.youtube.com/watch?v=Q-XOM4E4RZQ
He goes into the nerdy depths of gear make-up, metallurgy, meshing, machining and mistakes as he manufactured metal gears on a mini-lathe.
That's also what I was taught as a best practice, but it's not always possible.
Defn: a & b are coprime/ relatively prime iff GCD(a,b) = 1
> /* 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. */
I'm aware this would be extremely difficult; maybe impossible.
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.
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.
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 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. :)
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.
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.
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.
https://ciechanow.ski/gears/#strings-attached
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:
https://en.wikipedia.org/wiki/Cycloid_gear
I first learned about involute curves from a cousin that works as a machinist. Mr. Wizard also blew my young mind with noncircular wheels:
https://www.youtube.com/watch?v=lg4_Kf9B0MI
Edit: stumbled onto this technique to make involute gears in CAD:
https://www.fictiv.com/blog/posts/creating-involute-gears-in...
If someone has a simpler method, I'd love to see it.
t = np.linspace(0, 1); (1 - 1j*t) * np.exp(t * 1j)
To me this sounds simpler.
https://github.com/deadsy/sdfx
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
)Wish I saw this earlier!
> 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.
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.
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
And even these have fallen by the wayside to digital electronics.
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
$ wc -l gears.js base.js
4135 gears.js
904 base.js
5039 total
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.
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.
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".
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.
It wasn't web delivered and was a Windows, perhaps Win 3.1 application. This was in mid 90s
PS: had to archive the link because of SSL errors prevent direct access. my guess - my browser had old number of gears :P
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.
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
Enjoy!
I last saw one of these inside an IBM 3890 check reader machine.
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.
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..).
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.
For some interesting, less conventional gears that surprisingly still function, checkout out How To Make Organically-Shaped Gears:
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/
Digital scent technology: https://en.wikipedia.org/wiki/Digital_scent_technology
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
It reminded me a lot of: https://acko.net/blog/animate-your-way-to-glory/
And it's from 1937! We have so many video editing and effects tools today, but sometimes simpler is best.
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)?
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.
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.
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.
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.
The work he put into this is admirable. A great education tool.
They all looked like that first gif (but not animated of course).
[1] http://worrydream.com/refs/Papert%20-%20Mindstorms%201st%20e...
(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.
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.
https://mobile.twitter.com/moo9000/status/121019063004082176...
These animations are running in a <canvas>.
Any idea what the author used? Is everything produced with math (eg: a gear solver, etc)?
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.)
Would be nice to know about his process.
Here it appears he is importing the graphics from somewhere else converted to imperative drawing code:
Nah... Nah I would say you pretty much nailed it in this blog post! Incredible. HN Gold right here.
The Youtube channel "Gear Down for What?" has some pretty cool planetary designs.
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 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."
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.
No, SMIL on its own cannot replicate these illustrations. I hope that some future standard for declarative reactive graphics will be able to.
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.
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.
Pretty much all the modern synths these days have infinitely lubricated gears and pulleys in them, pushing those speaker cones/amp inputs ..
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.
Minute hand, surely ;)
Minute hand: 1RPH
Hour hand: 2RPD
Joke's on you, I have a 24 hour clock!
https://www.amazon.com/GreatGadgets-1858-24-Hour-Clock/dp/B0...
If I don't post it someone else will. Here's the spinning levers video you've all already seen a million times:
