jPosition error using fastin (getLatch(jPosition))???

[marcneedshelp]

As a reminder for our application:

 

- We have a Staubli RX160L mounted on a linear slide (7th axis) with a SICK camera/laser mounted to the end of it.
- We are scanning pallets and inspecting for defects.
- The camera, robot and 7th axis drive are all electronically latched to record a position simultaneously. This “pos data”        is called in the VAL3 program and written to a PC.
- The latch fastout0  output is used as the latching signal, this feeds back to the fastin0 on the CS8C J111, the FASTLATCH input on the Baldor MintDrvie II input, and the camera input.
- The J111 output is isolated by optical relays between the Baldor drive, and camera.
- The jPostion read from <<b_lLatch=watch(getlatch(jPosition,0.1)>> in the VAL3 program; approximately every 0.022 seconds.
- The joint jPosition is converted to a point using <<pDataPoint=jointtopoint(tlCamera[1], world, jPosition)>>  in the same VAL3 program.
- pDataPoint is decomposed using <<tostring(pDataPoint.tsrf.x)>>  for each of the 6 descriptors.
- This pos data is then used to align the camera capture buffer and recreate the image in 3D.
 

We have ran a test where half of the pallet was scanned with keeping the robot fixed and moving only the linear slide (7th axis), then the second half was scanned keeping the slide fixed and moving only the robot. Both were scan in a forward and reverse direction, without changing the camera orientation.
 

What we know:

- The slide only scan will provide a well aligned image.
- The robot only scan consistently has approximately a 50mm misalignment.
- The misalignment seems to be worse at the near side (closest to the robot) and is progressive. By progressive, I mean to say it gets progressively worse on the reverse scan, and progressively better on the forward scan. Forward direction is when the robot is extending.
- We tried different scan speeds, and the misalignment in the forward direction can be eliminated when the speed on the pendant is reduced to 25%. However this same speed in the reverse scan will still produce a misalignment of about 30mm.
- We know we are getting the latch signal since the count of “markers” in the camera matches the count of  latches in the VAL3 program.
- We can find the same edge of the pallet in the camera buffer, then we look at the pos data written by the robot, we see the X position for the robot only scan does not match the X position of the slide only scan for that same edge.
- we tried using herej calls but the error seemed to be larger.

What can cause this error in the X direction? I am assuming that the position written to the getLatch is encoder not commanded?

Please advise, would be willing to pay for travel and time if anyone can come to Orlando next week for a day or two?

[Jim C]

The getLatch does return the feedback position from the encoders, not the command position sent to the servos. This is updated every 0.2 milliseconds (200 microseconds).

The position for the herej function is base on the commanded servo position and the position is only updated every 4 milliseconds at best. I would not use the herej for your application.

A couple of things you can try. First, the fastOut signal needs to be turned on and remain on for at least 0.2 milliseconds. if it is on for less the 0.2 milliseconds, the latch function may not work.

You need to do a setLatch instruction before each use of getlatch. Put a delay(0) instruction after each setLatch to end the program cycle before trying to read the getLatch in the next cycle. If you don't do this you maybe get the last position latch and not the current one.

In your motion descriptor (mdesc) variable for the arm moves, use the tvel (translational velocity) setting keep the motion at a constant speed. If you are using just the vel (velocity) setting to control speed, the speed will change as the arm extends.

[marcneedshelp]

Jim,

I do have the setLatch and respective delay(0) commands in the code. I have analyzed the signal on a scope to confirm it stays high longer than 0.2ms; actual duration is 2-5ms. Also, looking at the pos data file written to the PC, I can confirm I am not reading the same jPosition twice.

Regarding the tvel versus vel, here is a typical mdesc I use for scan segments. However to syncronize the robot motion to the slide, some scan segments vary.  Here is the mdesc for the test I did:

accel=100, vel=50, decel=100, tvel=60960, rvel=20, joint, 10, 10

How do I determine if vel or tvel is being used?

I appreciate your response!!

[Jim C]

Your mdesc variable has the speed being controlled by the "vel" set to 50% of nominal joint speeds. The "tvel units are in mm so you have 60.960 meters per second set. Any time you are above 1 or 2 meters (1000 to 2000 mm in tvel) per second it usually be "vel" that is controlling speed.