Question about units when calculating arm end-effector velocity

[Alex2014]

I have a data set for a simulated arm moving in a single plane (as if sliding along a tabletop). The arm has 2 joints (shoulder and elbow). My data set includes the shoulder and elbow joint angles (in radians) at each timestep.

My goal is to calculate the end-effector velocity of the hand/wrist of this modeled arm. So far, I have been using the Jacobian matrix for this system, using the following:

velocity_x = dx/dt = [-L1*sin(theta_sh) - L2*sin(theta_sh + theta_elb)]d(theta_sh)/dt - L2*sin(theta_sh + theta_elb)*d(theta_elb)/dt
velocity_y = dy/dt = [ L1*cos(theta_sh) + L2*cos(theta_sh + theta_elb)]d(theta_sh)/dt + L2*cos(theta_sh + theta_elb)*d(theta_elb)/dt

where theta_sh is shoulder angle (in radians), theta_elb is elbow angle (in radians), L1 is the length (in meters) of the upper arm segment, and L2 is the length (in meters) of the forearm segment.

After I have calculated the individual x and y velocities, I take the square root of the sum of squares to calculate the overall curvilinear velocity of the hand/wrist.

From my literature reviews, I would expect a human-like arm to have a curvilinear peak velocity in the range of ~0.1 to 3 meters/second (or ~10 - 300 cm/sec). Currently, when I use the units mentioned above, my resulting peak velocity values are around 0.04, which is clearly not consistent with either m/s or cm/s units.

If I multiply the resulting curvilinear velocity values by (180/3.14159), this brings them into a reasonable range, although I'm not sure if this adjustment is justified.

If I convert the joint angles to degrees and perform the calculations, the resulting velocity values are in the correct range (for meters/second units), but the plots look jagged, whereas the velocity plots calculated using joint angles in radians are smooth, as expected.

Does anyone have advice about how I should convert my units in order to yield an end-effector velocity in the range of ~0.1 to 3 meters/second? My data have been vetted for validity, so this is not a problem with the data set itself.

Thanks in advance for your guidance!

 

[IRstuff]

units should not matter. If the results are not qualitatively the same, then you are doing something different in the calculations.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

Of course I can. I can do anything. I can do absolutely anything. I'm an expert!

 

[IceBreakerSours]

What sort of analysis are you carrying out?

Are you new to this forum? If so, please read these FAQ:

http://www.eng-tips.com/faqs.cfm?fid=376

http://www.eng-tips.com/faqs.cfm?fid=1083

 

[IRstuff]

"but the plots look jagged, whereas the velocity plots calculated using joint angles in radians are smooth, as expected."

This should not be the case. Since you are taking derivatives, the result should be choppy, since any data errors are magnified.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

Of course I can. I can do anything. I can do absolutely anything. I'm an expert!

 

[Alex2014]

Thanks for all of your input, everyone.

In response to IRstuff:
>> "but the plots look jagged, whereas the velocity plots calculated using joint angles in radians are smooth, as expected."
>> This should not be the case. Since you are taking derivatives, the result should be choppy, since any data errors are magnified.

I have attached a PDF that shows 3 versions of the plot, each created using a different strategy. I'm not sure if it's accurate to categorize the third plot (the one I described as "jagged") as "choppy"; I suspect that the qualitative differences between plot 3 vs. plots 1 and 2 is the derivative being taken on units of radians vs. degrees.


In response to IceBreakerSours:
>> What sort of analysis are you carrying out?

I'm comparing the performance of different controllers for this simple arm system. Right now, I am just working with a single, 100-timestep data set so that I can determine the proper processing method for these velocity plots, but eventually, I'll be processing large sets of numerous tasks. My ultimate goal here is to take my joint angle data and to determine, with correct units, the end-effector velocity of the hand/wrist, so that I can contrast different controllers' behavior on this performance characteristic.


The PDF I attached also includes my Matlab code. It seems that the first plot in this attachment is reasonable in its appearance (using units of m/s), but I am just wondering if I am justified in multiplying the tiny resulting velocities I get from my angles-in-radians calculations by (180/pi) to convert to degrees, *after* the velocity processing has been complete... Thanks for any additional insights anyone has.

 

[IRstuff]

The equations CANNOT used with degrees. The fundamental equation is still r*theta, where theta is in radians. Just consider multiply r*360 degrees; that will not get you the circumference of a circle. Your attempt at conversion is reversed. What you claim is a calculation in degrees, can only be done in radians, so if the table is in degrees, you must convert to radians:
q = jointAngles,3:6) assumes RADIANS in the table

q = jointAngles,3:6)*(3.14159/180.0) assumes degrees in the table, since you get deg * rad/deg = rad

Likewise, had you read the manual, you'd see that sin and cos require arguments in RADIANS:

http://www.mathworks.com/help/symbolic/mupad_ref/sin.html

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

Of course I can. I can do anything. I can do absolutely anything. I'm an expert!

 

[Alex2014]

Thanks for your response, IRstuff. I should clarify that my data in the input file are actually in *degrees*. (In my OP, I stated that the data are in radians because I was converting from degrees to radians, and didn't think that mentioning the raw form of the data was relevant.) Given your point that radian units are *required* for sin() & cos() functions, it makes sense that the two plots in my attached PDF file above that are produced from the radian data look as expected, while the one that used degrees is problematic.

My fundamental question remains: when I do use the joint angles in radians to calculate the endpoint-effector velocity, the resulting velocities have tiny values (e.g. peak velocity value of a typical movement is 0.037), which small magnitudes do not correspond to any typical units used to report velocities (e.g. meters/second or cm/second).

Is it legitimate to take the small velocity values that result from my calculations, and multiply them by (180/pi) to yield velocities in units of meters/second? If that is not legitimate, how should I go about 'translating' my small velocity values into physiologically-meaningful units?

Thanks for your input!

 

[IRstuff]

No, it's not. That would make zero sense, since your answer is ostensibly meters/second, so why would multiplying by an angle conversion factor even make sense?

But, I see your problem, now. This is one of the reasons I use Mathcad, which understands and tracks units. You did a difference function and called it a "derivative." As you probably tecall from calculus, since you did the symbolic math correctly, is that a derivative is the ratio of differentials. So, your derivatives need to include the difference in time. In Mathcad, the result would have been glaringly obvious, because the answer would only have meters instead of meters/second.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

Of course I can. I can do anything. I can do absolutely anything. I'm an expert!

 

[Alex2014]

That makes sense, IRstuff. Thanks for your input; I will consider my options given your updates.

 

[Alex2014]

Update: Thanks to your post, IRstuff, I realized that my derivative indeed hadn't been including the time element; once I added code to divide the joint angle differences by my timestep of 0.02 seconds, now the resulting velocities are of the expected magnitude! Since the arm segment lengths are in meters and my time units are in seconds, the peak velocities I'm seeing, of magnitude ~2 m/s, are physiologically reasonable values.

Thanks again for your responses, IRstuff and IceBreakerSours; your posts really helped me to work through this issue to the correct solution.