unwanted orientation change?!

behnam

I faced with a problem in RS. When you try to do some shifting of targets with VB/API, the orientation of targets changes strangely.

To observe this problem, you can run the attached code.
In this code it was tried to use the most logical way of shifting a target, however, you can observe that after small shifting the orientation of second target changes from (-90,90,0) to (0,90,0) very strangely! (if I use other methods, the error will be more chaotic.)

I tried to remove this error by using the below lines immidiately before and after the shifting. This solves the problem in this special case, however, for a general program it doesn't work and the problem still exists even if we try to keep the orientation constant with these lines:

Set orien = trfTargetRef.Target.transform.Orientation (before shifting)

trfTargetRef.Target.transform.Orientation = orien (after shifting)

My question is how can eliminate this problem??

BR, /Behnam

showError.zip

Administrator37896,4805787037

John Wiberg

Hi Benham,

After going through your code I find it difficult to understand what it is that you are trying to do.

You are adding 1/2^1 to 1/2^20 to a position. These are the values of those shifting(1 to 3) doubles:
0,5
0,25
0,125
0,0625
0,03125
0,015625
0,0078125
0,00390625
0,001953125
0,0009765625
0,00048828125
0,000244140625
0,0001220703125
0,00006103515625
0,000030517578125
0,0000152587890625
0,00000762939453125
0,000003814697265625
0,0000019073486328125
0,00000095367431640625
As you can see the last value is talking about zeptometers (10^-21), that is alot smaller than nanometers (10^-9) which are used for measuring atoms. I hope that this is not your intention. My suggestion would be to do this instead:
shifting(1) = Round((shifting(1) / 2), 5)
Which would round it to tens of micrometers, one decimal below what the robot controller can handle.

But regarding your problem, I've located the error to be when you get a graphical position and then add it to iself (transform.x=transform.x+n) while you have two orientations close to a singularity, like your -90 & 90.  This is due to the fact that RS gfx are in degrees, VBA are in radiants and the robot controller counts in quaternions. 
So it's a combination of unlucky parameters. If you had one less orientation value you'd be home safe.

To get around this conversion error I suggest that you use round(x,5) for  every data that comes from the gfx. Like this:
transform.x=round((transform.x+n),5)

behnam

Hi John,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Thanks for considering my question. I'm agree with what you talked about principally; however, after applying your suggestion regarding rounding the shifting value and data which coming from gfx, the problem still exists. Even it becomes more chaotic (bigger changes). You can see and test the attached code.

If you had a solution by rounding or other means, I'd appreciate to know that.

BR /Behnam

showError2.zip

Administrator37896,4808796296

John Wiberg

Hmm, strange.

We need to check this on a machine with the sourcecode on. Probably we can check into it tomorrow.

In the meantime, I rewrote your code so that it makes sense to me.
If you look at it you can see that I use a new transform which gets the calculation and then give that transform back, like this:

        Dim tfmT As New Transform
        tfmT.x = Round(tgt1.Transform.x + dbX, 5)
        tfmT.y = Round(tgt1.Transform.y + dbX, 5)
        tfmT.z = Round(tgt1.Transform.z + dbX, 5)
        tfmT.x = Round(tgt1.Transform.x + dbX, 5)
        tfmT.y = Round(tgt1.Transform.y + dbX, 5)
        tfmT.z = Round(tgt1.Transform.z + dbX, 5)
        tfmT.x = Round(tgt1.Transform.x + dbX, 5)
        tfmT.y = Round(tgt1.Transform.y + dbX, 5)
        tfmT.z = Round(tgt1.Transform.z + dbX, 5)
        tgt3.Transform.position = tfmT.position

This goes around the problem totally ...

2DZ_Module1.zip

Administrator37896,4817013889

behnam

Yes, strange!

To explain my case, I have a bigger code which the current code is a part of that.

I want to read the data of all targets from the path instruction and then shifting and/or changing the orientation of the targets with a certain amount.  

I used the same methodology that you suggested in the attached code, but you see the problem still exist. After several weeks of pain, I'd certainly be glad and thankful to go around the problem.

BR., /behnam

showError3.zip

Administrator37896,4813194444

John Wiberg

Hi again Behnam

OK MaGu checked it out. He found a round off bug that will be fixed with the next sevice pack. Now that round off bug only occurs with the -90 orientation. So I rewrote part of your code so that when performing the calculation we have rx,ry,rz=0 then change it back to whatever you had before.

Here you go:

2CC_ModuleFix.zip

Administrator37896,482037037

John Wiberg

Behnam,

Did it solve your problem

John

behnam

Hi John!

Well, the trick you mentioned works for 3 cases that I tested. the thing that really ease was to know that that is a bug and not a normal rounding problem.

What I couldn't understand before was a normal rounding problem should not cause a 90 degrees change in orientation. I had tested a similar idea of keeping the orientation (mentioned in the first message) which was not always successful.

Thanks for your discussion and time. I think it can improve much the next version of the software.

BR, /Behnam 

behnam37887,3220023148