Iterative Motion

It seems like motion-algorithms could be significantly simpler than the explanations I've seen... So here I ponder.

Similar projects worth following
Say you've got a simple robot-arm with two joints that allow the end-point to move in a plane. (a "shoulder", and an "elbow", the endpoint being the "hand").

Now, say you want to move the endpoint in a straight line... To do-so, one has to rotate *both* the elbow *and* the shoulder by certain amounts, as rotating *only* the elbow would cause a *circular* path. That circular-path may begin and end where you wanted, but the path itself wouldn't be a straight line.

As I understand, the typical approach is "inverse-kinematics" whose equations are way too complicated for someone with my years-of-forget. Also, as I understand, they're more of a pre-planned motion... E.G. calculate the rotation of each joint for the entire motion: r1(t) and r2(t), which then gives you the endpoint-motion e(t).

Far too complex for me... How about we look at this differently...

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 »

  • Revisit

    esot.eric10/30/2017 at 10:31 0 comments

    back to two joints:

    Thing is... say, again, that this is a stepped system... digital, rather'n analog. (Kinda a key factor, I think, for this iterative approach). E.g. DC motors with optical encoders, or stepper motors, as opposed to, say, RC-style servos with a potentiometer...

    trigonometry is quite hard on a lowly 8-bit microcontroller... so calculating the "error"/"overshoot" for every "step" (before compensating) could be quite time-consuming, slowing motion to a crawl...

    Maybe something can be done about that... e.g. lookup-tables are usually quicker. OTOH, say each axis has 32000 steps per revolution, that's a huge lookup table. Two of 'em!

    Then there's the matter of one motor's relative position to the other... it's likely that, say, if the shoulder takes one step then the elbow's entire coordinate-system will be rotated such that the lookup-table is no longer aligned with horizontal, even by subtracting a step from its position.

    ... so, nah... two huge lookup tables probably wouldn't alleviate the need for some trig to determine the position of the wrist.

    And doing it visually... well that's how the description does it... but most cameras don't have nearly the resolution and frame-rate necessary to assure smooth motion, say, for machining a diagonal line in some aluminum.

    Surely I had something else in mind when writing that description.. but now it eludes me.

    Something, maybe, related to pixel-drawing of lines...

    ...and/or maybe related to not *calculating* the endpoint's position, but in determining whether it's too far left or right (but not necessarily How Far), and iterating until it is no longer...

    To be pondered...

    Key factor: moving the elbow down (clockwise) will definitely cause the endpoint to be left of desired... (how to know this algorithmically?)

    Then, moving the shoulder counter clockwise introduces a new curve, similar to the purple one... and that curve may have similar algorithmic stuffs to the first... possibly allowing to iterate in a known direction until an intersection...


    actually, the reason I revisited this was in thinking about my old hanging plotter, the kind with two motors, pulleys, and cable... which requires a lot of trig. And, upon revisit, I think this method is a long ways from alleviating that system of its trigonometry.

  • ramblings on multiple joints

    esot.eric03/30/2017 at 07:38 2 comments

    Ramblings in this log prompted by @Simon Merrett.... Surely they'll come to something more... realistic... when I build a system and do some experimentation...

    Not sure if I made it clear, previously, but I'm certainly no expert on robotic-arms... these are thoughts I've come up with while *not* understanding the material I've tried to read on the matter.

    Experientially, I do my work "from scratch": I've done Cartesian systems (mostly just X/Y, without Z... plotters, etc. *Cartesian*, not CoreXY). I've done a weird combination rotational/linear-system whose exact-positioning and trajectory weren't particularly important, and a completely different one which was also rotational/linear where positioning was highly important. And I've done one of those hanging-plotter systems, where there are two pulleys in the upper corners, which requires a bit of trigonometry, Pythagorean theorem, and if your pulleys are like mine, then consideration of the varying diameter of the pulley as the cable winds-up on it.

    The last... well, I haven't really thought about it too much, but it's plausible it could've benefited from the strategy described here. (TODO: Think about this!)

    But... Arms... Well, I haven't done them before.

    So, the ramblings on this project-page, so far, are purely-speculative.

    The ramblings in the description seem pretty obvious to me... BUT... they only account for a very simple motion... with a very simple machine... Two joints, two dimensions to work within.

    So, lacking the energy to think this through and write this out too thoroughly, let's consider adding a third joint, while still working in a two-dimensional plane...

    This system, as-implemented, would be pretty limited.

    I've vague thoughts on:

    Ponder each joint's relative-angle with respect to "ground" (not each other)...

    If a motion-left is desired, start by rotating the joint/axis which is, presently, most-vertical.

    If a motion-down is desired, start by rotating the joint/axis which is, presently, most-horizontal.


    You can probably imagine, then, that with three joints, a "path," for the end-point "hand," may result in different motions of the joints, depending on their present states.

    You can probably also imagine, then, that with three joints, this method might result in a non-optimal approach... e.g. a leftward-motion might result in first the (short) "wrist" rotating from vertical to horizontal, (of course, causing the elbow and shoulder to compensate, keeping the motion horizontal). But the wrist's motion-left may not've been leftward-enough, at which point the elbow might take over the leftward-motion. But, now, the wrist needs to rotate (WRT the elbow) to stay horizontal, and the shoulder needs to rotate to compensate for both...

    The end-result may be a multi-step motion (wherein the shoulder might rotate away from its end-position before returning) which might've been accomplishable via merely rotating the shoulder (first) from the start!


    There's definitely a bit to be considered, here...

    The other approach, though, is to keep in mind that with three joints there's no "right" way to do the motion, IF all one cares about is the motion of the *end-point*.

    Some other considerations: One might care about the motion of the "hand" with regards to not only the location of its finger-tips, but *also* its wrist... (e.g. picking up a vertical object might require the fingertips and the wrist to be horizontal). OTOH, for that particular motion, there's no requirement on the elbow and shoulder, as long as the "wrist"'s end-path goes as planned.

    But, what then of *limited* joints...? Some joints (or all!) may only be able to rotate a certain amount *with respect to* another! I dunno about you, but my elbow only rotates roughly 180 degrees, not with-respect-to (WRT) "ground," but WRT my shoulder.

    So... yeah... it could get a bit complicated. And it's entirely possible the "simplified" technique explained earlier would only apply to an idealized scenario... e.g. where every...

    Read more »

View all 2 project logs

Enjoy this project?



Sergei V. Bogdanov wrote 04/05/2018 at 09:40 point

Thank You for "Like" for my project, the math to compute 2-joint hand is a part of my 5-link (5 joint) calculation. You need just a half of our calculation, for one secondary lever and one primarily lever.

  Are you sure? yes | no

Morning.Star wrote 03/26/2017 at 19:20 point

Computation versus calculation. You are a smart man, Eric, love the explanation ;-)

  Are you sure? yes | no

esot.eric wrote 03/26/2017 at 22:36 point

Ah hah! I should reword some of those "calculate" with "compute" Great Call!

Thanks for loving the explanation, but I can't vouch for its being *right*, only my understanding! Spose I should put it into action, sooner rather'n later. :)

  Are you sure? yes | no

Morning.Star wrote 03/26/2017 at 23:07 point

Is there a *right* way to pioneer, one wonders. ;-)

Cheers Eric, be lucky!

  Are you sure? yes | no

Similar Projects

My 'blog'
Project Owner Contributor

blogifying .io


Does this project spark your interest?

Become a member to follow this project and never miss any updates