w:
p:
q:

a:
b:

What is this?

It's a kinematics calculation thing. I saw people on my university working on something with inverse kinematics, and thought it looked interesting. I wanted to work out the math for kinematics, and then work out the inverse. After working out the kinematics part, I made this page to test if my math was correct (I did not yet know about the wonders of Desmos). I got bored with this, however, and never decided to work out the inverse.
Later, in 2023, I decided to also finally work out the math for inverse kinematics. After making sure it works in Desmos I implemented it into this page as well (poorly). You can find the Desmos project here. You can also find how I worked this out on my reMarkable here. If you can figure out what my ramblings mean, and you can read my horrible handwriting, that is. The actual part where I worked it out is on page 3. Don't go to page 4.

I don't really care if this is not the best way to do it, or if this has been worked out before. I just like doing math like this sometimes. It's a nice puzzle to solve. Both the kinematics and inverse-kinematics algorithms use only a single trig function per base node (so 2 trig functions in total). If you just want the position of the secondary node (idk what to call it, it's called M in most of the pdf), you don't need a trig function at all for the inverse-kinematics formula I came up with.

A few technical things about the tool:
The angles will sometimes teleport when you switch from kinematics (moving the 2 secondary nodes) to inverse-kinematics (moving the green node). This is because my inverse kinematics implementation mindlessly prefers to have the secondary nodes facing in opposite directions. (There are like 4 solutions to almost all coordinates.) I could fix this by keeping track of the angles of the nodes when switching modes, but I honestly cannot be bothered.

Weird things start happening when you try to move the green node too far away from or too close to the base nodes. This is because the problem is unsolvable for those positions. I implemented a very basic algorithm that just rotates the nodes a certain way to make sure the arms don't just disappear, or the green node gets placed in an impossible position. Again, this could be fixed relatively easily, but I really don't care enough lol.

For this tool's code you can of course just open the devtools. I never obfuscate my js because that's a shitty thing to do (if you don't have it publicly available somewhere else).