PUMA 200 Robotarm and some Hal/INI issues

Hi guys!

I have gere a puma 200 robot arm from unimation.

All joints working
All brakes working
All encoders working
All ratios of the gears fit to encoder and measured angles anglea digital angle measurement tool.

After all this i change my kinematic to GENSERKINS

In joint mode all works.
In world mode i have issues.

There is one thing what make me headache... the TCP is upside down.

If i look to the puma560 vismach genserkins simulation.. its the same.

I set up the DH parameters.. i look to the puma 560 dh parameters in the simulation config and adapt them to my puma 200 parameters i get from the drawings.


In world mode Z looks ok... x y small radius?
But if i start the linux example i get errors of limits and kinematic errors.


Has someone the knowledge to look to it?

Thanks
Could someone help me please?

 

Not much to go on. Please post your hal and ini files.

hi aciera!

i attached the ini hal and a second hal for the dh paramters.

possible i see somethnig not.. but genserkins with the MDH made me crazy .. hope i can fix it with the help of the forum!


Thanks for the quick answer!

Not sure but it seems a bit odd to me that you have a negative 'D-5' value and asymmetric angles for ALPHA-{3,4,5}:

When the example 'puma560_dh.hal' has:

and the melfa example has:

linuxcnc.org/docs/stable/html/motion/dh-parameters.html

i will try it.. what i found in my ini... ich have - sign on some scales and outputs... i wired all up + to + and - to -.... but if you look into the pum560 sim file.. you will see that the TCP is upside down.. or is something wrong on my sim file??? thanks

Ah, I see what you mean, the A value being 180° because the tool coordinate frame is pointing away from the flange. You are rotating the tool frame in the kinematics. Ok that shouldn't be the problem then.
Can you post a screenshot of the situation when you start the example program?

this is how it looks when i start the genserkins example 


could it be a problem that i change the signs on m joint  1,3 and 4 (linuxcnc joints!).. there have minus sign... please look at the ini you will see what i mean.

i attached 2 screenshots.. mygui is what i have after homing. i changed in the homing: homeoffset und home to 0. i move befor homeing in a extra osition.. form this position i hit home... then all 6 motors turn until the Z index of the encoder is reached.

i attached form this a picture.. pumaafterhoming.... thats the "ready position" but the in Wolrd Z moves are "ok" but in x and y it makes stuff wit the hand joints and get failure.. i attached again the used ini with editi to home and home offset 0.. to talk about the NOW situation.

i thank you!


aah befor i forget... there is a difference between puma 560 and puma 200... the shoulder of the puma 200 is of the opposite then on the puma 560. thats why i have on D1 a positiv value.. this value i got from stäubli via email. i measured.. and yes this values are correct... its from red green to green in the drawing i attached. i add then the puma560geo.png to the attached files that you see what i mean what is the difference... 

pum200geo


puma560geo
 

puma200afterhoming
   
puma200gui after homing



exampleguipuma560
 

could it be a problem that i change the signs on m joint 1,3 and 4 (linuxcnc joints!).. there have minus sign... please look at the ini you will see what i mean.

If you mean the 'SCALE_PWM' then that is not necessarily wrong as long as the joints rotate in the correct directions when you are jogging.

but the in Wolrd Z moves are "ok" but in x and y it makes stuff wit the hand joints and get failure

That sounds like you may be getting close to a singularity. Try setting the B joint to something that is not so close to having it point along the arm because if the wrist is collinear with the lower arm the C axis and the A axis are collinear which is a singular pose.
Sim configs CAN rapidly change the orientation of a wrist joint when approaching a singular pose, doing this with real hardware will trigger joint following errors and the kinematic will eventually fail.


 

for more on singularities in 6 axis manipulators:
mecademic.com/insights/academic-tutorial...es-6-axis-robot-arm/

Try it with a pose more like this:

Ok!

But what about the tcp in the simulation and my config?
Could you olease check if you have the phenomen with your sim config?

Ok a negative sign on pwm scale and encoder scale is not the issue?

Could you please explain me what are the correct direction of turn + - joint 1 2 3 4 5 6?

Possible that there is something wrong... i dont understand the MDH with flipping the coordinate system correct possible.. thats why alpha 0 to 5 has this values.

Possible my length and side shifts are not correct because the puma200 and puma560 are different on which side is shoulder to upper arm and upper arm to lower arm.

Thanks for your help... is it possible we can meet us in a teamview or zoom call or something? I am from germany.. timeshift... but if you can help me it would be so nice.

Thanks

But what about the tcp in the simulation and my config?
Could you olease check if you have the phenomen with your sim config?

Could you please explain me what are the correct direction of turn + - joint 1 2 3 4 5 6?

That is a result of how the modified DH parameters are derived, see the tutorial I linked in my post above forum.linuxcnc.org/10-advanced-configura...al-ini-issues#348232

As a matter of fact I'm not even sure that having the Tool Coordinates pointing down is even a problem. Or if it is more a question of cosmetics. (ie having the A axis value '0' in the home position rather than '+-180 and thus having the tool cone in the preview in the usual orientation')

In the 'melfa-sim' config a workpiece offset is used to have the preview cone pointing the usual way. (eg 'G10 L2 P7 X0 Y0 Z0 A-180 B0 C0' in '428remap.ngc').

However your method of inverting the last rotation _might_ actually be the better solution. I just tried it in melfa-sim and it seems to make the offset shift for the A-axis unnecessary.
So I don't think that doing it your way would cause you trouble.

Thanks for your help... is it possible we can meet us in a teamview or zoom call or something? I am from germany.. timeshift... but if you can help me it would be so nice.

I can only work on stuff like this a little bit here and there so lets just keep going like this, it suits me better than having to allocate a chunk of time.


Generally speaking these kinematics are largely experimental so we should not assume that the examples are necessarily doing everything _right_.