Puma 560 simulation using pumakins

Hi Jerry,

don't worry about your encoders. Basically they all work the same and I'm pretty sure that you can use them with UHU servo or Geko 320. Only the resolution differs - but this is just a parameter change in the LinuxCNC .ini file.
I would not create completely new software using STEP/DIR but use at least the hardware abstraction layer HAL of LinuxCNC. I'm also planning to extend the LinuxCNC maybe by reusing also things like the AXIS GUI. Let's see - still some way to go. I'm currenly not sure if I really spend the effort to go for an own homing procedure with a calibration. End switches does not seem to be a good solution since it is not a cartesian machine where all the axis can move independent to an end position. If you do this with a robot you are going to crash something in the workspace or the robot arm itself. The only way seems to be the original solution with the encoder index signals and potentiometer + the calibration procedure. The effort for this might be in the same order of magnitude than the controller itself - only the parts you need are inexpensive if you use eg. the A/D converter of the audio input. Homing via scribe marks is also not causing any effort if you always put the robot in a definite position via manual G-code commands before switching of the power (this is what I'm currently doing).

Thomas

I don't think homing would really be that difficult if approached correctly. There are 6 AXIS to deal with, and the safest way to handle them is to start at Axis-6 and work your way down to Axis-1. (6 Is gripper rotation, 1 is column rotation... I also have a PUMA.)

Consider how a standard coordinate homing works... X-Axis for example... if the home switch is NOT pressed, it moves in one direction until it IS pressed... then it backs off and continues the routine. If on the other hand the switch IS pressed, then the axis moves the OPPOSITE way until the switch is NOT pressed... and the homing process continues.

When you first turn on the arm, it does not know if it is past the home switch or not... it does not know which direction to travel... and that is the issue. They originally solved it with potentiometers and used the A/D to figure it out. This is actually a poor way to accomplish this. I worked on a Bosch SCARA robot... and they had a very simple and very accurate way of dealing with this... on the column, 1/2 was painted flat black. 1/2 was painted white. They had an optical sensor. The arm only rotated 270 degrees, not a full 360... similar to the PUMA. So when the robot was commanded to HOME... it checked it's optical sensor... if white, it rotated CW, if Black, it rotated CCW. When it got to the point where the paint changed from black to white, or vice versa... it knew it was at the HOME point, and continued normal homing.

this would be very easy to implement in the puma... adding a sensor and painting the axis to match. When I design my SCARA, I'll make a metallic 1/2 cylinder with a proximity sensor... this would also work, albeit with some fabrication needed. Once the 6 sensors were added to the robot arm... it would not be too difficult to effect the homing. And... I don't think you would even need to rewrite the homing routines... just be sure that they went in the sequence 6,5,4,3,2,1 to avoid hitting stuff.

6 - Gripper rotates in place until homed.
5 - Wrist moves to central location.
4 - Wrist rotates to home position... at this point, the arm has not moved...
3 - Forearm rotates upward to home position. (Clearing the work-space.)
2 - Shoulder rotates upward to home position
1 - Main column rotates to home position

The arm is now in the same READY position as it would be during a VAL Commanded "DO READY" (home) maneuver. From there... a script can be run to drive the joints to the following...

3 - down 45 degrees.
2 - down 45 degrees.
5 - up 45 degrees.

Then do a G-Code to set this as the new HOME position. (This is a location I use as my default home all the time... gripper horizontal with the table, straight out.) On my current CNC machines, I have a button called "GO HOME" which runs a routine... that routine sets the home... this could be modified for the additional axes I believe.
Thoughts?
Jerry

Addendum: You could also use white reflective tape instead of paint for the detection area.

True... take the analog out and when it reaches a certain point, call it home. Not sure it would be accurate enough... levels fluctuate... would be worth looking into however. I still prefer a fixed point... but that could be just my opinion.

I get what you are saying... swing the arm CW or CCW depending on the potentiometer... via the comparator signal... and use the result of the comparator AND the index as the exact home. I'm not sure how to wire/program that into HAL however.

Two separate inputs... one denoting the need to go forward (CW) or back (CCW) comparator and one giving periodic pulses once per revolution, index.

It seems like you would need TWO inputs to HAL and a custom home sequence... currently if the comparator and index were tied together via an AND gate for example... HAL would detect either a 0 or a 1 and start the movement of the arm... at the first pulse of the index... which still may be several iterations from actual home... it would start the standard homing sequence because it thinks the home switch was triggered.

You would need a custom routine to do the following...

1) Evaluate the comparator ONLY, move the arm in the position to where the signal reads logic 0.
2) Move the arm until BOTH the comparator and the index read as logic 0. (I.E. NOT INDEX)
3) Combine (AND) the signals... this output will be read as the HOME SWITCH signal.
4) Hand-off to normal HOME routine... HAL will begin to move the arm until the comparator AND the INDEX read logic 1... the HOME circuit detects the output as a HOME SWITCH signal.
5) HAL will run it's normal course of moving off, then back to this spot... an exact point.
6) Repeat for next axis.

It seems to me that a custom routine would be needed to home the entire sequence, then handed off to HAL. Or... the human would have to get it "close enough" so that the comparator and index both read as logic 0... within one pulse of the index... then handed it off to a normal HAL home sequence.

Thinking about it... there is another low-tech way of doing it...

Run the HOME sequence with the comparators only... that gets you in the ballpark...
Flip a switch that now combines the comparators and the index outputs via an AND gate... then run the home sequence again to lock it to the exact index spot.

Two step process... but exactly one spot all the time... very accurate.

thoughts?
Jerry

Ok Andy... you are well over my head at this point.