COW arm: Difference between revisions

From Alnwlsn - Projects Repository
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
For this year's Winter Camp, Space is the theme. Therefore, after upgrading my electric wheelchair robot base this spring with [[RC Wheelchair 2|a new motor controller]], I decided that it should also have a robotic arm, making it useful as a Mars rover - esque robot platform. The wheelchair base weights a hefty 100+ pounds, and I want this arm to be actually useful (ie, able to lift more than a tissue box). I have named it the '''Cow arm''', as it is designed to be beefier than those crummy kit arms that use servos.
For this year's Winter Camp, Space is the theme. Therefore, after upgrading my electric wheelchair robot base this spring with [[RC Wheelchair 2|a new motor controller]], I decided that it should also have a robotic arm, making it useful as a Mars rover - esque robot platform. The wheelchair base weights a hefty 100+ pounds, and I want this arm to be actually useful (ie, able to lift more than a tissue box). I have named it the '''Cow arm''', as it is designed to be beefier than those crummy kit arms that use servos (Ok, well, it has to be called something).





Revision as of 16:17, 14 August 2019

For this year's Winter Camp, Space is the theme. Therefore, after upgrading my electric wheelchair robot base this spring with a new motor controller, I decided that it should also have a robotic arm, making it useful as a Mars rover - esque robot platform. The wheelchair base weights a hefty 100+ pounds, and I want this arm to be actually useful (ie, able to lift more than a tissue box). I have named it the Cow arm, as it is designed to be beefier than those crummy kit arms that use servos (Ok, well, it has to be called something).


Upper and Lower Arm

I designed this arm after seeing this Hackaday.io project which uses linear actuators to provide forces along the length of the arm, much like the muscles in our own arm. Many arm designs I have seen use very high torque gearmotors in the arm joints to provide torque on the arm, but I don't have the ability to make one and they are astronomically expensive. Meanwhile, these linear actuators cost just 10s of dollars. I picked up a couple for testing, and if they work, they should take care of the largest force sections of the arm straight away.

First design of the arm in GeoGebra. The blue lines are the linear actuators, which I can change the length of with the sliders. The red lines represent the arm segments themselves. The green line is just a distance measurement. Also note the grey vectors placed to help estimate what the max load of the arm will be.

I also began to design the geometry of the arm; for this I have used a free program called GeoGebra, which I had remembered from a class I took. This program is essentially the electronic version of a paper, compass and straightedge. More importantly, objects can be changed - for example, I can change the diameter of a circle - and the rest of the lines will instantly update themselves to the new position. I can even attach the size of a circle to a slider, and drag it around to see what changing the size does in real time. It doesn't have all the constraint features of a CAD package, but the dynamic updating ability is really powerful.

I constructed the basic arm design I wanted to use, and then adjusted the joints of the linear actuators of the arm around until I got the range of the arm about how I wanted. Also, GeoGebra supports vectors, so by using the maximum force listed by the linear actuators and some vector projection, I could estimate the max force I might expect to pick up at the end of the arm. Obviously, this varies depending on how far the arm is extended, just like our own arms. Neglecting the weight of the arm itself, I was quite impressed to realize the arm might be able to pick up 10-30 pounds quite easily.

At present, the arm design looks more like a crane or backhoe than an arm. GeoGebra files for this design: File:Cow-arm-lower-upper-v3-ggb.zip

Encoders

Software/The Math

There's one big difference between the arm I just designed and the one attached onto my shoulder - how do you control it? When we want to pick something up, we don't think about how our muscles need to move, we just move our arm towards the object. With this arm, ideally I don't want to manually control it by moving each actuator. I should be able to just specify a location, and the arm should go there.

We can do this with a concept called inverse kinematics. Inverse kinematics can tell us the angles of the arm joints that we need to get to any given points. This is a much harder process than forward kinematics, which is what we do if we have the angles of the arm and want to see where it will end up. Inverse kinematics can involve a lot of fancy and complicated math, with linear algebra and matrices involved, but for a simpler arm like mine, we can just use concepts from geometry and trig functions. Actually, we don't even need to do that, because a 2 link arm like mine is usually the first or second example in the book if you happen to search up "inverse kinematics" on Google. The derivation comes from law of sines and cosines, but at the end of the day we end up with the following formulas:

Verifying the inverse kinematics with the geogebra geometry model we made earlier.
q1 = pi-acos((x^2+y^2-a1^2-a2^2)/(2*a1*a2));
q2 = atan(y/x) + atan((a2*sin(-q1-pi))/(a1+a2*cos(-q1-pi)));

where q1 and q2 are the angles shown on the GeoGebra model. We also have the other parameters of the arm, like the lengths of the arm segments(a). Variables with a 2 after them are for the arm section, and ones with a 1 are for the forearm section. Our inputs are x and y, which assumes that point A is at the origin and we want to place the end of the arm (point H) at location (x,y).

The last step in this is to tell us how we need to extend our actuators to get the angles we just found, which is found from the law of cosines:

act1 = sqrt(l1^2+m1^2-2*l1*m1*cos(q1)); act2 = sqrt(l2^2+m2^2-2*l2*m2*cos(ng2*(pi/180)-q2));

Here, we need lengths along the arm segments where the actuators are mounted (l and m), which form the other 2 sides of the triangle we are calculating. Lastly, we need to add in the angle at which the arm mount is tipped up (ng), so we get the right position.

That's pretty much it. We can just feed those actuator lengths into the controller for our actuator and the arm will position itself to the point that we want. However, this won't necessarily be a straight line move, because the actuators will just go at their own speeds. To fix this, I broke up the move into a bunch of tiny segments, and we command the arm to move to the endpoints of each segment, in sequence. To do this properly, we might first want to know the initial position of the arm. I use forwards kinematics for this, by recalculating the angles given the position of the arm actuators, and then the position of the end of the arm.

q1b=acos((m1^2+l1^2-act1^2)/(2*m1*l1))
q2b=-acos((m2^2+l2^2-act2^2)/(2*m2*l2))+ng2*(pi/180)
x2=a1*cos(pi-q1b-q2b)+a2*cos(q2b)
y2=a1*sin(pi+q1b+q2b)+a2*sin(q2b)

x2 and y2 are the position of the end of the arm. The idea is that we get the arm position from the actual reporting of the encoders, and therefore have a better idea of where the arm is, rather than assume it's in the spot we commanded it to go last time, in case I do ever want to control the arm manually.