I have 6 DOF lynx arm. Recently I have written inverse kinematics software for my arm. In my movement there is %6,8 deviation. While distance of arm from base increases, height of arm from base decreases. With total distance of 34,5 cm height deviates 2,5 cm. Is that type of deviation normal?. If so what can be the problem, is it a mechanical issue?. I am working to develop correction routines to make this deviation minimum. On my working progress any help or comment would be very valuable.
I’m having difficulty imagining how this could occur.
Have you been making true physical measurements or have you been getting these measurements from the IK?
If you’re measuring it with a ruler, then have you been measuring to the middle of one servo screw to the other (those are the points at which the joints rotate about).
If you can take pictures of the two different possitions that cause this discrepancy and post them, that would be helpful.
You can upload images at www.putfile.com
Even if we can’t see the differences in length in the picture, it will at least give us much better idea of what positions cause these errors.
Let me clarify the situation a bit more. We have measured by the help of a meter. You can find an excel file and graphics here (yaskil.tripod.com/kitap11.xls) which shows our measurements. Also we have taken two pictures. Picture 1 and Picture 2 of two different positions in same movement line. When we first encounter that situation (deviation) the first thing we think is “have we written ik formulas correctly”. Then we have compare outputs of our software and laurent gay’s excel file. They were exactly same. Also we tried to use RIOS software in order to check whether is it working correctly. It does the same thing. After that we started to think there might be mechanical issue.
The pictures and datas related to these pictures as follow:
For Picture 1
IK Values Measured values (in cm's)
Height 3,3 2,5
Length 7,8 7
Angles (in degrees)
Base 0
Shoulder 20,10
Elbow -28,11
Wrist -82,00
Grip 0
Wrist rot. 0
Wrist relative
to ground -90
For Picture 2
IK Values Measured values (in cm's)
Height 3,3 0,7
Length 25,8 26,5
Angles (in degrees)
Base 0
Shoulder -25,44
Elbow 0,97
Wrist -22,98
Grip 0
Wrist rot. 0
Wrist relative
to ground -90
Logically the height values must be same for these two positions. Also in excel and in our program they are logically same. But physically there is deviation in height value. That is our problem.
Ahh… I think I now understand.
So, you start with the foot at a certain distance above the ground, close to the bot.
Then you extend the foot out, attempting to skate over the surface while remaining at the original height.
As the foot extends, the height of the end effector decreases.
Does that sound right?
If so, then I can think of a physical reason of why this would be.
If you envision the system as a mechanical lever, things become more clear.
As the foot extends, the lenght of the lever increases, giving gravity a much easier job of pushing down and the bum at the fulcrum (the “hip” servo, in this case) a much harder time holding it up.
Both analog and digital servos have a deadband (a.k.a. backlash, if you’re familiar with gears).
Analog servos express this much more greatly than digital servos.
What you’re experiencing is the difference between where your servo asked the servos to go to and where the servos were actually able to get to.
Good news and bad news:
First the bad:
Simply hacking open the servo and tapping into the pot to get your own feedback has already been proven to not be worth the effort.
It’s not accurate enough to bother.
The good:
OpenServo is out there to both convert analog servos to digital AND give your micro a large amount of feedback.
And, to boot, there’s I2C that would allow you to daisey-chain your servos.
So why isn’t everyone else jumping aboard?
Well, it’s rather new and (AFAIK) yet to be proven.
Given time, though, I’m sure we’ll all be looking towards it.
There is the built in dead band in the servo to keep it from constantly “hunting”, gear slop, gear flex in plastic gears and splines, flex in materials and joints in the arm. Any flex at the base is magnified at the end of the arm many times. In the real world these short commings are countered by designing software that takes into account the flex and slop to keep the gripper at the desired position. If you have the arm extended and you add some weight to the gripper like it is holding something, it will probably sag even more. Trying to use feedback from a servo to get a current position is subject to the same issues. I’d take some actual positioning data and use it in the position formula to correct for the sag.
Thank you guys your comments helped so much. We have thought same things but we wanted to be sure really what could be the problem is.
Nick thanks for the advise. Hacking open the servo method might be useful but as I understand it needs mechanical and electronical experience. For our situation as I said in my first post and also zoomkat indicated that some kind of correction routines might work properly. What do you think about that type of correction routines/algorithms?.
Also we have clearly specified that deviation in height value mostly caused by gravity. But what about deviation in length. If you take a look at the excel file in my previous post (yaskil.tripod.com/kitap11.xls) there is a distance deviation tab. When length of end effector from base increases, physical value of distance in world coordinates decreases constantly. What do you think about that?. The measurement data is inside the above mentioned excel file.
I have promissed to fund a build of the open servo boards. I hope to do this early next year. The problems I see with the concept are, lots of the people interested in doing this plan to use standard cheap servos like the Hitec HS-322 or the Futaba S148. This will not work because these servos are not designed to withstand the extra power an FET control board will provide. Gear breakage is going to be the result. My efforts to get HS-645’s without electronics from Hitec was dissapointing. They knocked like $2.00 off my cost. The reason I am still interested in making a batch of these boards is they can be used with gearhead motors.
Back to the current subject. The software we use to control the arms (RIOS) has a feature called gravity compensate. This automatically adjusts for the effects of gravity and for the weight of the lifted item.
I’m not sure what “world coordinates” are, but length measurements might should be from the centerline of the spline of the base servo to the tip of the arm. The arm will tend to rotate some from around this axis due to gravity caused flex/sag. If this is what is causing the length difference, then this could be factored into the control software based on the expected arm length and the current spline angle of the base servo. As for gear head based servos, a cheap servo could probably be used to control the gear head motor and its H-bridge after some tinkering.
Nah, cheap servos have cheap electronics as well. Like bipolar transistors instead of FET’s, and the motor voltage refresh is way too slow. Why cripple a good gearhead motor with whimpy electronics.
Btw, I believe that “world coordinates” are referring to the pixelated coordinates of a graphics display.
In QBASIC, there’s some world coordinate functions that allow you to set your own values to the display coordinates, which helps a lot when programming cute MSDOS visuals.
The world coordinate is physical (x,y,z) coordinates of fingers (grip) in centimeters. Our coordinate system assumes that the arm is at the origin of it at r(0,0,0) point. The x is (length of fingers from base)*cos(θ) and y is (length of fingers from base)*sin(θ) where θ is rotation degree of base in radians and z is (height of the fingers) from base. In short terms our world coordinate is the projected (x,y,z) values of the position vector of the fingers (grip). When we supply those coordinates to our inverse kinematics function we want to be sure that the software will position the arm exactly to these coordinates. So that we can relocate the arm in any point of its working space (a half sphere whose half radius is equal to the length of the arm)
I think I have realized the deviation factor well. I want to ask is there any limit point when a servo produces geardown effect. For instance can we say geardown effect will occur after applied specific force or after some specific torque. Is there that type of specific point or it depends on and changes. I want to exactly simulate the deviation in order to produce very accurate positioning that is why I need these limits. Also I wonder how does gravity compansate of RIOS handles this. Is there any algorithm or a specific subject shall I investigate? or handling that type or problems are limited with the imagination of the developer. If so I think we are to develop our own software routines.
I wouldn’t know, but the person to ask is Laurent.
He wrote the Rios software.
Maybe he’ll be willing to help you out (though there might be copyright problems there, since I believe that Lynxmotion owns the software…).
My point is why spend $115 when $10 might be adequate for the job. A moderate size gear head motor will need its own high current H-bridge independent of what the servo has. I did some simple testing with a cheap tower hobbies servo and it was capable of 0.5 deg resolution, which may well be adequate for most gearhead applications. The gearing and bearings don’t have to be heavy duty as they would have very little load on them, especially when the motor is removed from the gearing. Attach a shaft where the motor shaft goes and attach to multi turn devices like linear actuators to control them.
Taking a guess…
I think zoom was saying that, while the actual drive components (transistors) might not work for gearheads, that it would still probably be much cheaper to modify the servo internals for FETs.
Or, at least use most of what’s already in there (PID controller & potentiometer).
That’s just a guess, though, since I have no idea how one would go about doing that…
That’s the picture. I don’t know how accessable the appropate points are on the servo circuit board to be able to tap the control chip outputs to the H-bridge. If somebody has an inexpensive servo, it might make an intersting project to open it up and see what can be done with the internals.
Good idea.
I’ll be ripping out the control boards in two el cheapo servos for that digital sumo project of mine, so I’ll have a pair to play with.
No promises on how long that will take, though.
why could,nt u use gearheads with pots,how accurate can a h-bridge be,? how accurate is the pot?and if u atached the pot directly to the joint would it be more accurate? cuold u use both internal an external pots and get feedback from the difference in the 2,!?? i see a huge leap in hobby robotics comin soon
The reason I am still interested in making a batch of these boards is they can be used with gearhead motors.
