I would like a rod on top of a cam to move up and down as the cam rotates.
Any suggestions? Here's the project with the two objects:
https://snap.berkeley.edu/snap/snap.html#present:Username=glenbull&ProjectName=Cam%20Example
The cam rotates. Now I need the rod to rest on top of the cam, moved by the motion of the cam.
With a physical cam of this kind, the position of the top of the cam can be described by a sine function:
This becomes evident when the positions are recorded and graphed:
I'm getting a different result with my attempt to create a digital version in Snap!, but I'm not sure what I'm overlooking.
Sure. Using the nested sprites feature, put an invisible dot at the edge of the circle, where the arrow is pointing. Put the rotation center of the rod on its horizontal black bar. Then just put this script in the rod sprite:
forever
set y to (ask (invisible-dot-sprite) for (y position))
(If you wanted to show off, you could do without the script, by making the rod a clone of the invisible dot, and just have the rod inherit the dot's y position!)
Edit: Why nested sprites, rather than setting the cam's rotation center to where the arrow points? Because you're going to want the cam's rotation center to be the point you really want it to rotate around!
You were typing this message as I was answering your first one. I don't know what you're doing wrong because you didn't include a project link. But here's my version:
In this case, because you're not trying to animate a cam but just draw a sine wave, it's totally the right thing to have two sprites, one a clone of the other, with the clone inheriting the y position of its parent.
Here's a link to the cam project:
https://snap.berkeley.edu/snap/snap.html#present:Username=glenbull&ProjectName=Cam%20Example
The rod follows the dot on the rim of the cam. So now l need to calculate the offset from the y-position of the dot to the top of the cam.
The sine wave example is beautiful. But in this case, I actually am trying to create an animation of a cam that mirrors the physical cam that we created.
Maybe I'm misunderstanding what you're trying to do, but it seems to me that this is totally backward.
The behavior of actual physical cams and rods doesn't come from the cam computing sine functions. Rather, the sine function arises from the actual behavior! So instead of all that computation, the cam's script should just be
forever
turn ↺ 1 degrees
And then the rod should follow the dot, and the graph of the function should follow the rod.
In this case, we're trying to create a digital version of the physical cam; in the physical version, the rod rests on top of the cam. This video may illustrate this better:
So rather than following a dot on the rim of the cam, we need to determine where the top of the cam is.
https://snap.berkeley.edu/snap/snap.html#present:Username=bh&ProjectName=Cam%20Angle%20Conversion
There's a bit of unfortunate complexity because MY TOP doesn't do what I need if the sprite is rotated.
P.S. I stand by my "totally backward" comment, which applies in this case too.
This is really nice. (Thank you.) We're planning to use a physical knob connected to a microcontroller so that as the knob is turned, the digital cam on the screen will rotate.
BTW, as you know, many systems begin with 0 degrees pointing North (like a compass) and rotate clockwise. The coordinate systems in school math textbooks begin with 0 degrees pointing East, and rotate counterclockwise (so that 0 degrees on a compass is 90 degrees in the school math system). Does anyone know of a good history that explains why these two different approaches evolved in the way that they did?
Well, the math one, I think, has to do with the fact that X comes before Y in coordinate pairs, so the unit X-direction vector comes before the unit Y-direction vector, but I'm not really sure. It's slightly weird, though, because the function with the short name (sine) is associated with the Y coordinate, while the X coordinate is just the co-sine. But I imagine that's because the triangle-trig people made up the names before the circle-trig people came along. Kinda like Ben Franklin guessing the direction of travel of electrons wrong.
The other one, used in measuring compass directions (for steering your ship, orienteering, etc.) has to do with the fact that compass needles point north. Clockwise rather than counterclockwise, just as in clocks, have something to do with most people being right-handed, I believe, but I'm vague about that part.
The compass system does make sense since compass needles point north. The math system seems less intuitive, for the reasons that you note. My understanding is that ancient astronomers were attempting to chart the positions of the stars, and discovered trigonometric relationships in the process of measuring the angle of stars in relation to the horizon. I bet there's a really good story behind it ... this would make a great book, like Dana Sobel's book about longitude.
My colleagues Steven Greenstein and Eileen Fernandez at Montclair State University report
"On the use of the letter x for our variable (not necessarily related to the plane): this came about during the printer typeset of Descartes' Le Geometrie. The typesetter was running out of the last letters of the alphabet and asked Descartes if he minded which of the three got used to indicate the unknowns in his treatise. Descartes said it didn't matter to him, so the printer chose x because it gets used less in the French language than y or z."