Configuration decisions and tuning

More
12 Mar 2015 03:53 #56713 by sliptonic
I'm in the process of retrofitting an old IBM 7575 SCARA robot. I picked the thing up surplus and it was missing the controller and servo amps which was fine with me.

I've replaced the amps with four AMC 30A8Ts. For control, I'm using a 5i25/7i77 plug-n-go kit. I used this on the retrofit of my milling machine so I'm not completely unfamilar with the configuration and tuning process but I'm not an engineer so forgive me if I ask silly questions. :)

My first point of confusion is whether I should be setting up the amps for voltage or current mode. I assume this is the same as velocity and torque mode respectively. My mill was configured for velocity mode but the motors had tachs and the ones on the robot do not. They're minertia motors RM series.

I have a linuxcnc configuration working with scarakins and I believe I have all the scale values correct now. Other than that, I haven't done anything to tune the servo loops. I can move the arms by hand and see encoder counts changing appropriately. However, when I try to move the joints from linuxcnc, I get following errors even with the FERROR/MIN_FERROR set to an absurdly large numbers.

I'm looking for advice and guidance on how I verify the configuration of the amps and then get ready for the more detailed tuning of the loops.

thanks.

Please Log in or Create an account to join the conversation.

More
12 Mar 2015 06:06 #56720 by andypugh

I get following errors even with the FERROR/MIN_FERROR set to an absurdly large numbers.


How absurdly large?

Do the joints work in degrees 0-360 for a full turn, or 0-1 ?

If the encoders are scaled 1:1 then your absurdly large might be nowhere near absurdly large enough :-)

Please Log in or Create an account to join the conversation.

More
12 Mar 2015 06:20 #56721 by sliptonic
O.k. Looking at just one axis,
Machine angular units is set to degrees
The ENCODER_SCALE = -333.333
FERROR is 50000.

Please Log in or Create an account to join the conversation.

More
12 Mar 2015 06:43 #56722 by andypugh
I am puzzled, then. It is hard to see how the f-error can ever be tripped with those numbers.

Is this in joint mode or world mode? (I assume joint-mode)

I can see that you could get weird results from singularities in the kinematics in world mode (though you would expect scarakins to be robust enough by now)

Please Log in or Create an account to join the conversation.

More
12 Mar 2015 07:37 #56723 by sliptonic
This is in joint mode.

When testing with the pot on the amp, or feeding it a couple volts with a battery, everything moves very smooth, fast, and strong (like tear your arm off, robot uprising strong) but when I enable it in linuxcnc and it's sitting idle, it barely resists any force against the arm before tripping a following error.

Perhaps I have something configured incorrectly through pncconf. I'll look at that next.

Please Log in or Create an account to join the conversation.

More
12 Mar 2015 17:00 #56734 by andypugh

when I enable it in linuxcnc and it's sitting idle, it barely resists any force against the arm before tripping a following error.


This sounds like the PIDs are not active, or have zero gains.

But before you fix that, make sure that you have the following errors set correctly as a misconfiguration could lead to runaway, and that's more "Robot self-harm" than "Robot uprising"

Compare the values of axis.N.motor-position-cmd and axis.N.motor-position-fb. That difference is the following error. I can't see how that could be 5000 if that is still your FERROR. So check your command and feedback units.

How is homing set up? Do you have absolute encoders or does it use switches? Getting the position and feedback to agree without one or the other of these is hard.

Once you have that right, set the PID max output to a small value so that the motor force is limited to a safe valie, then try a small amount of Pgain to see if the robot starts to try to control itself, or if it tries to run-away.
The following user(s) said Thank You: sliptonic

Please Log in or Create an account to join the conversation.

More
14 Mar 2015 22:10 #56810 by sliptonic
Cool. That was helpful. I tracked down a couple problems including a loose wire.

The big problem with Following error was my own stupidity. :blush: I had cranked up the FERROR on the axis I was testing but one of the other axis was still low. The moving joint would jiggle the stationary one enough to cause the following error. Duh.

All the joints except the roll -- I'll get to that later -- are moving pretty well now. Limit switches and homing are working correctly and I can switch into world mode. Things are looking good.

Now I'm turning my attention to really tuning the loops and I have a rookie question:

With steppers, I can tell when the velocity or acceleration is too high. The sound of missed steps is obvious. The servo tuning loop discussions in the wiki focus on the PID/FFn values but seem to assume that velocity and acceleration are already set right. How do I get into the right ballpark with those? What does it look like if those are too high/low?

Please Log in or Create an account to join the conversation.

More
14 Mar 2015 22:57 #56812 by PCW
Easiest way to check your velocity and acceleration limits is to use halscope
and look at the following error as you increase velocity and acceleration

For example first set acceleration quite low and increase jog velocity until
you get a sudden large increase in following error.
This happens because you have exceeded the maximum speed of the motor
LinuxCNCs velocity setting should be perhaps 20 or 30% less than this value
to allow headroom for voltage and motor variations


Next the acceleration limits are tested, These are set in a similar manor as velocity
but with perhaps more headroom (maybe 50% or more), depending on what additional
inertial load is added (end effector) or perhaps cutting loads.

Please Log in or Create an account to join the conversation.

More
28 Sep 2015 04:02 - 28 Sep 2015 04:03 #63089 by Askjerry
I am wanting to build a small SCARA robot arm for our robotics group. I have been searching through the archives, looking for SCARA related files, etc. I found one SIM set of files... but it comes up with errors... all this before I even start to wrap my head around doing all the DT data, etc.

My thought was to configure a parallel port... and from what it looks like in the documentation I did read/understand...

X Y Z C would be the configuration.

X - Shoulder
Y - Forarm
Z - Up/Down
C - Gripper Rotation

So the PARPORT could be set up very similar to a standard XYZA, with the A replaced by C...

paraport.0.02-out = X-STEP
paraport.0.03-out = X-DIRECTION
paraport.0.04-out = Y-STEP
paraport.0.05-out = Y-DIRECTION
paraport.0.06-out = Z-STEP
paraport.0.07-out = Z-DIRECTION
paraport.0.08-out = C-STEP
paraport.0.08-out = C-DIRECTION

I get that... I get that I need to use SCARAKINS... and then I kinda loose the train...

Reading through the forum... there seem to be others wanting to do this as well... so any help or guidance would be fantastic.

I have a pile of stepper motors, 4 stepper drivers, plywood and a laser engraver... so I'd love to get something operational that others could duplicate and evolve.

Thanks,
Jerry
Last edit: 28 Sep 2015 04:03 by Askjerry.

Please Log in or Create an account to join the conversation.

More
29 Sep 2015 16:55 #63194 by andypugh

My thought was to configure a parallel port... and from what it looks like in the documentation I did read/understand...

X Y Z C would be the configuration.

X - Shoulder
Y - Forarm
Z - Up/Down
C - Gripper Rotation


It's probably better to forget about XYZ and think in terms of 0,1,2,3

axis.0.motor-position-cmd => Shoulder Motor etc.
The following user(s) said Thank You: Askjerry

Please Log in or Create an account to join the conversation.

Time to create page: 0.129 seconds
Powered by Kunena Forum