So, let's recap:
We want to move our "hand" in a straight line (blue)
If we merely rotated the "elbow", we'd be able to move from the starting point to the end-point. But, the path would be circular (purple).
So, to avoid a circular-path we need to also rotate the "shoulder," as well.
As I gather, the typical approach is to calculate "paths" for both the elbow and the shoulder before the motion actually starts, then execute the motion.
Calculation of the joints' rotations is an interesting exercise, and can solve this problem, but isn't particularly easy for me to wrap my head around.
Also, computers are *excellent* at iterative calculations... doing things step-by-step over and over again... So, then, why try to "predict" (or "extrapolate"?) those equations, when they have to be executed step-by-step in the end?
For a more iterative-approach we still need to determine equation(s) for the line that our "hand" will move along...
That's not particularly-complicated, the regular ol' y=mx+b equations, or a slight modification thereof.
(TODO: Re-learn parametric-equations... is that y(t) = at+b, and x(t) = ct+d?)
(This might be approached in the same way a line of pixels would be drawn, iteratively, on a screen... more on that later).
Anyways, not particularly difficult, and required regardless of which approach is taken (this so-called "iterative-motion" approach, or using inverse-kinematics).
Now, let's iterate through this...
Just glancing at it, we can see the "hand" should move down, a bit... (we'll ignore the leftward-motion, for now).
A downward motion of the "hand" should be accomplishable by rotating the elbow counter-clockwise.
Doing-so causes an "overshoot" toward the left (along the purple path)
So, to compensate, we want to move the "hand" to the right. That can be accomplished by rotating the "shoulder" clockwise a bit.
Basically, that's it. Now repeat those steps, taking very small physical steps, numerous times until the endpoint is reached.
Thankfully, computers (or even 8-bit microcontrollers) can do that very process thousands, if not *millions* of times per second, so the amount of "overshoot" will be so small as to not even be noticed.
Taken a step further, those calculations can be performed faster than one's motors can step from one position to the next, and likely can occur more-often than even a high resolution encoder could detect. Which means no more "error" or "overshoot" would occur with this iterative method than with any other.
Further-still, the desired motion of the "hand" determines, in any case, the rotations of the "elbow" and "shoulder", so no motion-planning is necessary for each individual joint to consider acceleration, etc. If the requested-motion (the line) is possible per the limitations of the motors, the motion will occur. If not, a slower motor will delay the system until it "catches up." In the end, the motion will be as smooth as the motors can physically allow, and if the requested motion of the "hand" is within the means of the system, it will occur "on time" and with as much or as little "ramping" as requested.
One key-factor may be to iterate through each possible position on each motor, step-by-step. Rather than, say, requesting twenty steps on one motor, and one on the next, within one "loop." Instead, one might iterate through the loop ten times; the first ten loops would cause individual steps of the first motor, the next loop would advance both motors one step, and the remaining ten loops would cause ten more individual steps on the first motor.
This is similar to drawing a line of pixels on a screen. If you drew a line on a screen by using y=mx+b, iterating through each *integer* value of x, when m > 1, the line drawn would contain a bunch of disconnected points. Instead, you determine which axis requires the greatest "travel" and choose to use either y=mx+b or x=ny+c as appropriate, and, again, step through each *integer* value of x or y, respectively....Read more »