Puma 560 simulation using pumakins
12 Oct 2015 13:32 #63713
by robottom
Replied by robottom on topic 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
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
Please Log in or Create an account to join the conversation.
12 Oct 2015 22:39 #63720
by andypugh
How many indexes are there?
It should be possible to use the potentiometer voltage to select the joint angle that each encoder index corresponds to.
What I can't immediately figure out is how to use that information. In an ideal world the axis home-switch position would be a HAL pin, and it could change on the fly as the potentiometer moved.
However, the home switch physical position is read from the INI file, and is not exported as a HAL pin.
If _could_ be a HAL pin with small changes here:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...6b0f9a7a16e4806#l640
To create pins for the home positons here:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...f3f35c0;hb=HEAD#l478
It is possible that a solution might be to have a HAL component that "lies" about the encoder position. This might only need to be a "sample-hold" feeding into an "offset" component and taking input from a "lincurve" that is controlled by the potentiometer.
However I think that this would result in a rapid to the home position at the end of homing, which is probably bad.
Replied by andypugh on topic Puma 560 simulation using pumakins
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.
How many indexes are there?
It should be possible to use the potentiometer voltage to select the joint angle that each encoder index corresponds to.
What I can't immediately figure out is how to use that information. In an ideal world the axis home-switch position would be a HAL pin, and it could change on the fly as the potentiometer moved.
However, the home switch physical position is read from the INI file, and is not exported as a HAL pin.
If _could_ be a HAL pin with small changes here:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...6b0f9a7a16e4806#l640
To create pins for the home positons here:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...f3f35c0;hb=HEAD#l478
It is possible that a solution might be to have a HAL component that "lies" about the encoder position. This might only need to be a "sample-hold" feeding into an "offset" component and taking input from a "lincurve" that is controlled by the potentiometer.
However I think that this would result in a rapid to the home position at the end of homing, which is probably bad.
Please Log in or Create an account to join the conversation.
12 Oct 2015 23:04 - 12 Oct 2015 23:09 #63721
by Askjerry
Replied by Askjerry on topic Puma 560 simulation using pumakins
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?![B) B)](/media/kunena/emoticons/cool.png)
Jerry
Addendum: You could also use white reflective tape instead of paint for the detection area.
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.
(Set G54 to ORIGIN with a ZERO degree angular offset.)
O <r01-zero-all> sub
M5 (Stop Spindle)
M9 (Stop Coolant)
G17 (Machine to XY Plane)
G20 (Inch Mode... change to metric G21 if not in the USA)
G40 (Cutter Compensation OFF)
G90 (Absolute Movement Mode)
G94 (Speed in Inches per minute)
G54 (Use Coordinate system P1 G54 Default)
G49 (Cancel any tool length compensation)
G91.1 (Arcs set to default units and method)
G10 L20 P1 X0 Y0 Z0 (Set current location to ZERO)
G10 L2 P1 R0 (Force Angular Rotation to 0 degrees.)
O <r01-zero-all> endsub
Thoughts?
![B) B)](/media/kunena/emoticons/cool.png)
Jerry
Addendum: You could also use white reflective tape instead of paint for the detection area.
Last edit: 12 Oct 2015 23:09 by Askjerry. Reason: Addendum
Please Log in or Create an account to join the conversation.
12 Oct 2015 23:36 - 12 Oct 2015 23:38 #63722
by andypugh
If you have a potentiometer then a comp in HAL or an actual comparator chip connected to a bit-input can do what you describe with no painting or fabrication required. Then enable index-homing in the INI and you are home and, err, homed.
Replied by andypugh on topic Puma 560 simulation using pumakins
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.
...
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...//
...
Thoughts?
If you have a potentiometer then a comp in HAL or an actual comparator chip connected to a bit-input can do what you describe with no painting or fabrication required. Then enable index-homing in the INI and you are home and, err, homed.
Last edit: 12 Oct 2015 23:38 by andypugh.
Please Log in or Create an account to join the conversation.
26 Oct 2015 19:44 #64287
by Askjerry
Replied by Askjerry on topic Puma 560 simulation using pumakins
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.
Please Log in or Create an account to join the conversation.
26 Oct 2015 19:52 #64288
by andypugh
I was suggesting using the analog voltage to synthesise a homing switch signal, but you would then actually home to the encoder index.
Conceptually you would home to potentiometer_within_range AND encoder_at_index. Though in practice index-homing happens in a slightly different way.
It would be much nicer to use the potentiometer to enable homing to _any_ index, but that sounds a little more difficult. Not impossible, though.
Replied by andypugh on topic Puma 560 simulation using pumakins
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 was suggesting using the analog voltage to synthesise a homing switch signal, but you would then actually home to the encoder index.
Conceptually you would home to potentiometer_within_range AND encoder_at_index. Though in practice index-homing happens in a slightly different way.
It would be much nicer to use the potentiometer to enable homing to _any_ index, but that sounds a little more difficult. Not impossible, though.
Please Log in or Create an account to join the conversation.
26 Oct 2015 20:54 - 26 Oct 2015 20:55 #64295
by Askjerry
Replied by Askjerry on topic Puma 560 simulation using pumakins
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.
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.
Last edit: 26 Oct 2015 20:55 by Askjerry.
Please Log in or Create an account to join the conversation.
26 Oct 2015 21:07 #64296
by Askjerry
Replied by Askjerry on topic Puma 560 simulation using pumakins
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
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
Please Log in or Create an account to join the conversation.
26 Oct 2015 21:45 #64300
by andypugh
I haven't thought about it very hard, but I think I would be looking at using the potentiometer to do lookup into a lincurve that stored the exact position of each encoder index.
LinuxCNC would do a simple home-to-index with the home switch set permanently to high (in HAL) and the lincurve output would be latched by a sample-hold and fed into a hal "offset" component.
This might not work, of course. It would be relatively easy if the HOME_OFFSET value could be updated live.
I think this might be possible by adding the offset to this code block
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...f0ce671ad4aff72#l630
Then the code here would need to copy the value across:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...f0ce671ad4aff72#l504
Replied by andypugh on topic Puma 560 simulation using pumakins
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.
I haven't thought about it very hard, but I think I would be looking at using the potentiometer to do lookup into a lincurve that stored the exact position of each encoder index.
LinuxCNC would do a simple home-to-index with the home switch set permanently to high (in HAL) and the lincurve output would be latched by a sample-hold and fed into a hal "offset" component.
This might not work, of course. It would be relatively easy if the HOME_OFFSET value could be updated live.
I think this might be possible by adding the offset to this code block
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...f0ce671ad4aff72#l630
Then the code here would need to copy the value across:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...f0ce671ad4aff72#l504
Please Log in or Create an account to join the conversation.
26 Oct 2015 22:10 #64303
by Askjerry
Replied by Askjerry on topic Puma 560 simulation using pumakins
Ok Andy... you are well over my head at this point.
Please Log in or Create an account to join the conversation.
Time to create page: 0.125 seconds