2017-03-02 21:47 GMT+02:00 Charles Steinkuehler:
> Thanks for the hints, it would have taken me quite a while to figure
> all that out. Now I'll start plugging in numbers and toggling between
> world and joint coordinates to see what's happening.
>
Well, I think I missed the fact that genser_kin
On 3/2/2017 1:26 PM, Andrew wrote:
> What this means for genserkins: everything is defined in genser_kin_fwd.
> Tweaking it will tweak both forward and inverse kins.
>
> OK, first it uses go_link_joint_set for each joint and then
> go_link_pose_build to get the robot pose... which uses go_pose_pos
2017-03-02 18:01 GMT+02:00 Charles Steinkuehler:
> Hmm...I see your point, but commanding an AB orientation in world
> space via gcode would then require knowing the position of the first
> joint (the base rotation of the whole arm), which is generated from
> the commanded position via kinematics.
On 3/1/2017 12:09 PM, Andrew wrote:
> 2017-02-25 23:46 GMT+02:00 Charles Steinkuehler:
>
>> Is anyone else doing 5-axis machining with genserkins?
>>
>
> Not exactly machining... but I'm building a 3D printed stepper driven
> 6-axis robot arm. So I hope that I'm going to need genserkins soon.
>
2017-02-25 23:46 GMT+02:00 Charles Steinkuehler:
> Is anyone else doing 5-axis machining with genserkins?
>
Not exactly machining... but I'm building a 3D printed stepper driven
6-axis robot arm. So I hope that I'm going to need genserkins soon.
The AB behavior you describe (if I get it correct)
The kinematics in the control have very little or nothing to do with the
code interpretation. It is only used to tie the machine components together
with the control.
The kinematics in the post processor (CAM System) have very little or
nothing to do with the control nor the kinematics in the contr
i think...
On 03/01/17 09:16, Charles Steinkuehler wrote:
> On 2/28/2017 5:52 PM, andy pugh wrote:
>> On 26 February 2017 at 22:46, Charles Steinkuehler
>> wrote:
>>> The A and B Axis has no
>>> dependency on the rotation of the base of the robot arm (joint-0).
>>>
>>> Is this the expected behavi
Maybe I can help a little on this subject.
In 5-axis machining the 4th and 5th axes are controlled in coordinated
moves with the x, y, and z axes.
For both configurations, tilting and rotating spindle or tilting and
rotating tables, the CAM program must create the correct GCODE for all the
axes i
On 1 March 2017 at 02:16, Charles Steinkuehler wrote:
>
> Perhaps a different way of asking my question:
>
> Given two types of 5-axis machine, one with A and B pivots on the
> spindle, and one with A and B pivots on the table, would identical
> gcode be expected to produce identical results on th
The method used to generate the gcode program almost always needs to have
knowledge of the kinematics and use that knowledge to calculate the numbers
in the gcode program.
On Feb 28, 2017 8:20 PM, "Charles Steinkuehler"
wrote:
> On 2/28/2017 5:52 PM, andy pugh wrote:
> > On 26 February 2017 at 2
On 2/28/2017 5:52 PM, andy pugh wrote:
> On 26 February 2017 at 22:46, Charles Steinkuehler
> wrote:
>> The A and B Axis has no
>> dependency on the rotation of the base of the robot arm (joint-0).
>>
>> Is this the expected behavior?
>
> I don't know.
>
> I did notice that the C axis value chan
On 26 February 2017 at 22:46, Charles Steinkuehler
wrote:
> The A and B Axis has no
> dependency on the rotation of the base of the robot arm (joint-0).
>
> Is this the expected behavior?
I don't know.
I did notice that the C axis value changes when you rotate the base.
Have you seen http://lin
On 2/25/2017 3:46 PM, Charles Steinkuehler wrote:
>
> Further investigation shows that the A and B coordinates are being
> applied to something relative to the end of the robot arm. Regardless
> of the XYZ position of the arm, A and B moves always do the same thing
> relative to the robot arm. I
I am having some issues with genserkins running a robot arm (this is
the ST R-17 I brought with me to Wichita running LinuxCNC with
joints-axis running on Debian Wheezy with RTAI).
Coordinated moves in XYZ seem to work as expected. All the joints
working together to keep the end of the arm moving
Andy pugh wrote:
>I might still be tempted to "tune" them. (ie, forget the science, just
>make small changes and see what happens).
>How far out are the distances?
The distances are far5 or 6 cm more on z and 4 or 5 cm less on x and y!!
And then the movement aren't linearfor example the
On 6 December 2011 12:48, Francesca Sca wrote:
> I checked the d-h parameters many many times and they should be correct.
I might still be tempted to "tune" them. (ie, forget the science, just
make small changes and see what happens).
How far out are the distances?
> Also if I don't understand
andy pugh wrote:
>It may be that the joint lengths in the DH parameters are slightly
>wrong. It is less likely to be the stepgen scales, but that would have
>a similar effect.
I checked the d-h parameters many many times and they should be correct. Also
if I don't understand why in world mode t
On 5 December 2011 14:34, Francesca Sca wrote:
> I would like to ask you some help with the my last problem. When I use the
> world mode (inverse kinematics) my robot isn't accurate. For example if I
> write G01 z100, the robot doesn't move 100mm on z but every time more mm. The
> same thing h
>You might need two scale functions, then, combined with inverting the
>stepper directions you have 16 combinations to play with. One of them
>ought to work :-)
I have changed the command how you suggest me and I have got what I wanted with
the first combination!! I'm very lucky!!! :p
I would
On 5 December 2011 13:51, Francesca Sca wrote:
> add scale.0 servo-thread
"addf"
> net elevation axis.4.motor-pos-cmd => scale.0.in
> net scal scale.0.out => offset.0.in offset.1.offset
That has the same effect as inverting axis.4. I think you need to
break the symmetry, so
> net elevation axi
Andy pugh wrote:
>> How I should write the commands and then link to the function
>> offset?
>Just like any other HAL function, loadrt / addf / net.
>http://www.linuxcnc.org/docview/html/hal_basic_hal.html
ok I tried with these lines for see what happen:
loadrt scale count=1
loadrt offset co
Andy pugh wrote:
>The problem is that I didn't explain properly. I was meaning that you
>might need to pass one or both the position signals though a HAL
>"scale" function with a value of -1 to get the required effect (this
>means that the "offset" becomes "subtract" rather than "add")
>http:
On 5 December 2011 09:38, Francesca Sca wrote:
> I set the offset function like you have suggested me and I tried every
> combinations of signals (parport.0.pin-X-out-invert) but I have always 2
> rotation or 2 elevation and ever 1 rotation and 1 elevation. I tried also to
> set -1 in the sect
Andy pugh wrote:
>I think the HAL will work, I don't know if the function of that code
>is correct.
>If it doesn't work, then what it needs is some of the signals
>inverting (scale by -1) before going in to the offset function.
I set the offset function like you have suggested me and I tried
On 3 December 2011 21:39, Viesturs Lācis wrote:
> With all due respect to Andy, I did not have time to go through his
> suggested solution in HAL. AFAIK he knows HAL very well, so that
> solution should work well.
I think the HAL will work, I don't know if the function of that code
is correct.
2011/12/3 Francesca Sca :
>
>
>>Or:
>>Motor.4-cmd = joint.4-cmd + joint.5-cmd
>>Motor.5-cmd = joint.4-cmd - joint.5-cmd
>
>>To get correct feedback value, use last 2 equations and derive
>>feedback positions:
>>joint.4-fb = (motor.4-fb + motor.5-fb) / 2
>>joint.5-fb = (motor.4-fb - motor.5-fb) / 2
>Or:
>Motor.4-cmd = joint.4-cmd + joint.5-cmd
>Motor.5-cmd = joint.4-cmd - joint.5-cmd
>To get correct feedback value, use last 2 equations and derive
>feedback positions:
>joint.4-fb = (motor.4-fb + motor.5-fb) / 2
>joint.5-fb = (motor.4-fb - motor.5-fb) / 2
>I think that this can easily be d
On 3 December 2011 12:40, Francesca Sca wrote:
>>loadrt offset count=2
> So, I should just add these command to my file .hal? Right? Or I should
> compilate a particular module?
That is something to try in the HAL file.
It sounds like you are not 100% familiar with HAL yet, and I think you
are
Andy pugh wrote:
>I think that needs a custom HAL component, using comp.
>Part of the problem is that you need to get the feedback back the other way.
>It is just possible that you might be able to do it all with two
>"offset" functions:
> http://www.linuxcnc.org/docview/html/man/man9/offset.9.h
2011/12/2 andy pugh :
> On 2 December 2011 17:35, Francesca Sca wrote:
>
>> Infact I don't want loose a DOF. I would like to find a solution for have in
>> the joint mode both the rotation of the wirst and the up and down, setting
>> in the right way stepgen and pins. There are this solution?
On 2 December 2011 17:35, Francesca Sca wrote:
> Infact I don't want loose a DOF. I would like to find a solution for have in
> the joint mode both the rotation of the wirst and the up and down, setting
> in the right way stepgen and pins. There are this solution? Or I should
> create some p
Andy pugh wrote:
>I still think it seems a shame not to use all the degrees of freedom though.
Infact I don't want loose a DOF. I would like to find a solution for have in
the joint mode both the rotation of the wirst and the up and down, setting in
the right way stepgen and pins. There are
On 2 December 2011 16:33, Francesca Sca wrote:
> When I looking at stepgen-pos-cmd pins in "Show HAL config", I see only a
> series of numbers.
Yes. What did you expect to see?
> So I can link each stepgen to only one step and one direction pin.
No, you can link each stepgen to as many pa
Andy pugh wrote:
>It isn't any harder than other things you have already done. The first
>thing to work out is how the two stepgen positions correlate to wrist
>positions. You can figure that out by jogging in joint mode while
>looking at the stepgen-pos-cmd pins in Machine->Show HAL config (use
On 2 December 2011 13:52, Francesca Sca wrote:
> Hmm...I don't understand very well what this means. You suggest me to create
> an HAL component or some maths in HAL to pass the Joints pos values
> (calculated by genserkins?) to stepgen 4 and 5. Right?
Yes. Genserkins rather assumes that the m
>Hmm, yes. I see the problem.
>It's quite a neat mechanism, you turn both gears the same direction
>for up-down and in different directions for rotate.
>The solution is probably to abstract the two movements into basic
>angles as far as the DH parameters go, so that you have an elevation
>and a r
On 2 December 2011 11:21, Francesca Sca wrote:
> http://mecatronicaeajm.blogspot.com/2010_05_01_archive.html
>
> For the roll of the wirst, the two side gears must move in opposite direction
> and this is realized by the moviment of two motors. For the "pitch" just the
> moviment of a motor and
Andy pugh wrote:
>Do you have a picture/diagram? I can imagine designs where two motors
>in parallel drive a wrist joint, in which case you do not have a
>serial kinematics, but a part-serial, part-parallel one.
http://mecatronicaeajm.blogspot.com/2010_05_01_archive.html
For the roll of the wir
On 2 December 2011 10:16, Francesca Sca wrote:
> I don't konw. I said that because the combination of two motors should give
> the rotation of wirst:
Do you have a picture/diagram? I can imagine designs where two motors
in parallel drive a wrist joint, in which case you do not have a
serial kin
2011/12/1 Francesca Sca :
> Viesturs wrote:
>
>
>>It is more than just simple: put 2 stepgens in the receiving end of signal.
>>net J0pos-cmd axis.0.motor-pos-cmd => stepgen.0.position-cmd
>>stepgen.1.position-cmd
>
> Ok, I can do in this way, But I should change something also
> to stepgen.0.st
2011/12/1 Francesca Sca :
> Viesturs wrote:
>
>
>>It is more than just simple: put 2 stepgens in the receiving end of signal.
>>net J0pos-cmd axis.0.motor-pos-cmd => stepgen.0.position-cmd
>>stepgen.1.position-cmd
>
> Ok, I can do in this way, But I should change something also
> to stepgen.0.step
Viesturs wrote:
>It is more than just simple: put 2 stepgens in the receiving end of signal.
>net J0pos-cmd axis.0.motor-pos-cmd => stepgen.0.position-cmd
>stepgen.1.position-cmd
Ok, I can do in this way, But I should change something also to stepgen.0.step
or stepgen.0.dir?
---
2011/12/1 Francesca Sca :
>
>
> How I can pass a joint-pos-cmd value to stepgen and so to two different
> motors?
It is more than just simple: put 2 stepgens in the receiving end of signal.
net J0pos-cmd axis.0.motor-pos-cmd => stepgen.0.position-cmd
stepgen.1.position-cmd
Viesturs
Andy Pugh wrote:
>However, you are more of an expert than me on Genserkins, you are
>actually using it...
I am not so expert
>Possibly a bit of both. The joints are numbered from the base to the
>tip, in the physical sequence of the robot. However, you can pass the
>joint-pos-cmd value in H
2011/12/1 Francesca Sca :
> Andy pugh wrote:
>
>
>
>>What errors?
>
> the same error of this user
> http://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg03964.html
>
It turned out that genserkins was too complicated for comp, so that
is why it is complaining about these errors.
You
On 1 December 2011 16:59, Francesca Sca wrote:
> You can explain me better this? To the rotation of wirst should corrispond to
> the moviment of 2 stepper motor. This doesn't create problem with the inverse
> kinematics of genserkins?
As long as it is a true serial kinematics, and is correctly
Andy pugh wrote:
>Possibly a bit of both. The joints are numbered from the base to the
>tip, in the physical sequence of the robot. However, you can pass the
>joint-pos-cmd value in HAL to any stepgen or PWM that you want to,
>though that is an easy route to confusion.
You can explain me bette
On 1 December 2011 15:33, Francesca Sca wrote:
> the same error of this user
> http://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg03964.html
I take it that the changes don't work? Those are all warnings, and the
new version of the kensrkins module is created and installed (cp
ge
Andy pugh wrote:
>What errors?
the same error of this user
http://www.mail-archive.com/emc-developers@lists.sourceforge.net/msg03964.html
>A, B and C control the angle of the end-effector, you don't have an "A
>motor", you have joint motors with numerical indices. (joint.7 for
>example)
>Ge
On 1 December 2011 14:58, Francesca Sca wrote:
> I tried to do how you have suggest me but when i recompiled genserkins.c many
> errors appear!
What errors?
> I have another problem with axis and joints. In the puma configuration the
> wirst can rotate and go up and down. Two different motor
Andy pugh wrote:
>What I was suggesting was adding:
>world->u = joint[6];
>world->v = joint[7];
>world->w = joint[8];
>In the forward kins, and
>joint[6] = world->u;
>joint[7] = world->v;
>joint[8] = world->w;
>In the inverse kins. and then controlling the gripper with U, V or W
>in the G-code
On 18 November 2011 10:51, Francesca Sca wrote:
>>I think that the easiest solution might be to use M67 to send position
>>commands out of the G-code to a HAL pin, and link that direct to a
>>stepgen in HAL.
>
> I have the version 2.4.6. This could be a problem with that command?
Yes, it doesn't
2011/11/18 Francesca Sca :
>
> I have the version 2.4.6. This could be a problem with that command? However
> the command is
>
> M67 E Q . You can me explain better what are E and Q?
http://www.linuxcnc.org/docview/html/gcode_main.html#sec:M67-Analog-Output
> You mean that for example if I want
Andy pugh wrote:
>I think that the easiest solution might be to use M67 to send position
>commands out of the G-code to a HAL pin, and link that direct to a
>stepgen in HAL.
I have the version 2.4.6. This could be a problem with that command? However
the command is
M67 E Q . You can me explai
2011/11/17 Francesca Sca :
> Viesturs wrote:
>
>
>>Then there is very nice way to solve it:
>>Use mux2 and limit3 components:
>>Mux2.sel pin should be the open/close command (can be driven from
>>g-code, if linked to spindle or coolant on/off HAL pins), mux2.in0 and
>>mux2.in1 should be stepgen pos
On 17 November 2011 09:59, Francesca Sca wrote:
>>Yes, that is correct. Genserkins does calcs for 6 joints. If the
>>actual robot has fewer, then dummy joints need to be defined to make
>>up 6 joints for genserkins.
> How I can make an axis dummy? for example the C one?
This is one of those sit
Viesturs wrote:
>Then there is very nice way to solve it:
>Use mux2 and limit3 components:
>Mux2.sel pin should be the open/close command (can be driven from
>g-code, if linked to spindle or coolant on/off HAL pins), mux2.in0 and
>mux2.in1 should be stepgen positions, when gripper is closed and o
2011/11/17 Francesca Sca :
>
>
> Viesturs wrote:
>
>>Yes, that is correct. Genserkins does calcs for 6 joints. If the
>>actual robot has fewer, then dummy joints need to be defined to make
>>up 6 joints for genserkins.
>
>
> How I can make an axis dummy? for example the C one?
I think - define DH
Viesturs wrote:
>Yes, that is correct. Genserkins does calcs for 6 joints. If the
>actual robot has fewer, then dummy joints need to be defined to make
>up 6 joints for genserkins.
How I can make an axis dummy? for example the C one?
>If You need some extra joint, then it has to be added sep
2011/11/17 Francesca Sca :
> Viesturs wrote:
>
>
>>Genserkins will treat C as a rotary axis. It is binded into all those
>>matrix conversions, jacobian functions and other stuff that I do not
>>fully understand.
>>IMHO, if You want to control the gripper, it should be anything but XYZABC.
>>I agree
Viesturs wrote:
>Genserkins will treat C as a rotary axis. It is binded into all those
>matrix conversions, jacobian functions and other stuff that I do not
>fully understand.
>IMHO, if You want to control the gripper, it should be anything but XYZABC.
>I agree with Andrew that adding U, V or W m
2011/11/16 Francesca Sca :
>
>
> Andrew wrote:
>
>>If you want to completely control the fingers angle, you can assign another
>>axis for them. It might be W if >you already have XYZABC.
>>I guess, you should add the axis to your HAL file and genserkins. It
> requires no kinematic transformation,
Andrew wrote:
>If you want to completely control the fingers angle, you can assign another
>axis for them. It might be W if >you already have XYZABC.
>I guess, you should add the axis to your HAL file and genserkins. It
requires no kinematic transformation, >just add the direct
connection.
2011/11/16 Francesca Sca
> I solved the problem with the world mode when I'm using genserkins module.
> The main problems were the latency of my computer and some home setting
> wrong. But now I have another problem. I have set the D-H parameters of my
> robot but unlike Puma my robot has a hand
I solved the problem with the world mode when I'm using genserkins module. The
main problems were the latency of my computer and some home setting wrong. But
now I have another problem. I have set the D-H parameters of my robot but
unlike Puma my robot has a hand and a stepper motor that control
are there any quite simple objective premises that form a basis for evaluating
statements?
--- On Wed, 11/9/11, andy pugh wrote:
From: andy pugh
Subject: Re: [Emc-users] problem with genserkins
To: "Francesca Sca" , "Enhanced Machine Controller (EMC)"
Date: Wednesday,
On 9 November 2011 09:44, Francesca Sca wrote:
> I don't find the parameter genserkin.max-iterations in Hal Config.
It should be under "parameters" is that where you looked?
> If I put this line "setp ganserkin.max-iterations 100" in hal file, Emc2
> gives an error because It isn't found this
Viesturs Lacis wrote:
>Hello, Franscesca!
>I have a question about genserkins that is unrelated to Your problem:
>The thing is that I tried to add also linear joints in it, but it
>seems that it is not working correctly.
>Please let me know, if You have a chance and spare time to test it -
>eithe
On 8 November 2011 09:44, Francesca Sca wrote:
> could be mean that I didn't set the number of iterations that were used to
> compute the inverse kinematics. The genserkins module request a pin for this.
> It is correct? How I can set this?
It looks like a parameter is created to set the max i
andy pugh wrote:
> ERR kI - compute_jinv (joints: %f %f %f %f %f %f), (iterations=0)
>Looking at the source-code that error indicates that the inversion of
>the matrix has failed.
>It might mean that your DH parameters are in some way
inconsistent, or
>possibly just that the motor position is a
On Oct 7, 2011, at 09:35 , Francesca Sca wrote:
> andy pugh wrote:
>
>> Odd.
>
>> Seb tried the 560 config in a Sim version and got a number of errors
>> but none in a realtime installation. This is odd, as things are
>> expected to work just the same.
>> Was this a fresh install from the LiveC
andy pugh wrote:
>Odd.
>Seb tried the 560 config in a Sim version and got a number of errors
>but none in a realtime installation. This is odd, as things are
>expected to work just the same.
>Was this a fresh install from the LiveCD?
My LiveCD is the version 2.4.3. I tried to run EMC2 from Liv
On 6 October 2011 19:02, Francesca Sca wrote:
>>I tried the puma560 config and it appeared to work for me.
>>Are you running in a sim or a realtime installation? What version of EMC2?
>
> I have a realtime installation and the version of EMC2 is 2.4.6
Odd.
Seb tried the 560 config in a Sim vers
andy pugh wrote:
>I tried the puma560 config and it appeared to work for me.
>Are you running in a sim or a realtime installation? What version of EMC2?
I have a realtime installation and the version of EMC2 is 2.4.6
--
A
On 5 October 2011 10:59, Francesca Sca wrote:
> I don't know if this is the actual error. I have the same problem also with
> puma560 configuration that uses genserkins! In puma example the d-h
> parameters are correct then I don't think that the parameters are the
> problem. What else could b
andy pugh wrote:
>Looking at the source-code that error indicates that the inversion of
>the matrix has failed.
>It might mean that your DH parameters are in some way inconsistent, or
>possibly just that the motor position is ambiguous.
>Is that the actual error message? All those "%f" entries
On 3 October 2011 10:00, Francesca Sca wrote:
> ERR kI - compute_jinv (joints: %f %f %f %f %f %f), (iterations=0)
Looking at the source-code that error indicates that the inversion of
the matrix has failed.
It might mean that your DH parameters are in some way inconsistent, or
possibly just that
Hi Emc users,
I have a 6dof robot and I would like to use genserkins module for the
kinematics of my robot. I set up the D-H parameters but the robot doesn't work
in world mode. Also the puma 560 configuration (that uses genserkins module)
doesn't work while I have no problem with puma configura
78 matches
Mail list logo
