Addition of True X-Y Encoders

Technical Details
1

Hello All,
I am about 90% of the way through a mod where I am adding two encoders to the maslow system. these two encoders will provide true X-Y feedback. Here is an image of a secondary beam mounted below the top beam.

IMG_4513
IMG_4513.jpg4032×3024 2.23 MB

The beam has a drywall square that is attached to a linear guide rail along the length. The sled is prevented from rotating by a similar linear slide along the blade of the drywall square.

IMG_4514
IMG_4514.JPG3024×4032 3.09 MB

You can see that there is a top plate attached at the top of the drywall square that is ready to have the two encoders bolted on. I should have this completed in the next few days. It is my plan to use a 6mm GT2 timing belt on both the X and Y axis to cause the encoders to turn as the Sled moves.

While I haven’t yet added the encoders to the system, I am fairly pleased with the smoothness of the mechanical motion of the drywall square, so I have high hopes that I will be able to feedback a true X-Y signal.

So here is where I run into difficulties - I don’t really understand where I can insert this information into the code. I was originally planning to port over to the Due to allow for more interrupts First Post, but if I could stick with the Mega2560 I would do it. However, that would mean that instead of adding more encoders, I would need to remove the wires from the chain motor encoders and attach these instead. .

I would appreciate any thoughts about which way to go with this setup or where I should look to start modding the code. My coding skills are fairly weak, but I am nothing if not Tenacious! Is there a detailed write-up anywhere that documents how the kinematics work?
Thanks,
John

2 Likes
2

The current kinematics calculate how long the chain needs to be to move to a given point. The encoders on the motor provide feedback to the controller to know whether or not the chain length is correct. The encoders you are working on provide feedback as to whether the x,y is correct. However, this doesn’t really help the kinematics formulas. The formulas assume it’s a perfect representation of the actual setup and doesn’t use any feedback itself. Only the PID controller uses the encoder feedback, and as I said above, that’s just to determine if the amount of chain to be fed out is equal to the amount of chain that has been fed out.

With that said, I see a few options on how to use your encoders… all of which will require some programming. Others may have better ideas, this is just what comes to my mind…

First is in the calibration process, particularly with holey calibration. Instead of measuring distances between holes drilled, you can just use the x,y coordinates from the encoders. You could feasibly do many more points than holey calibration does and perhaps (or likely imo) get better results than with someone doing hand measurements.

Second is using the routines developed for optical calibration that allows the use of an error matrix. In optical calibration, a pattern of 0.6-inch squares, spaced 3-inches apart, is placed on the board and the machine is told to move to each of the squares and calculate what target value is required to be precisely over that square (uses a camera to figure out where it is). This produces an error matrix that the controller then can use to change target coordinates. It still uses the basic kinematics, just adjusts the target so the chain lengths that get calibrated put the sled to where it needs to be. With your encoders, you can eliminate the pattern and camera and just use the x,y encoders to provide the position feedback to develop the error matrix.

Finally, you could modify the PID controller to use x,y values instead of the chain length values. I don’t know how to do so, but it might entail doing forward-based kinematics to calculate chain lengths from the x,y coordinates. This might also required a faster processor than the mega. :man_shrugging:

All in all, I think you have a big task ahead of you. I think the first option is the simplest to implement, but neither the first nor the second would take advantage of the encoders after the calibration is complete. The third option is perhaps the best in the sense you will use the encoders continuously and you might get the best results with it, but I think it will be the most challenging to implement.

And lastly… Just realize that your are probably on your own with this project. I’d think many people would help, answer questions give feedback, suggest ideas, shoot down ideas, but they can’t really do any testing or much development themselves since they don’t have the setup. I fortunately had someone willing to get a pattern and camera to help me with optical calibration, but it wasn’t something nearly as involved as the additional encoders.

1 Like
3

This has been my intention from the start of the project. In a sense, I think the encoders may be able to simplify the process because I don’t need to correct for chain sag, chain angle, chain length, etc. Because I have real-time X-Y feedback, any small inaccuracy would feed into the next loop and be corrected out.

But I do like the idea of the forward based kinematics. For a particular X,Y position on the board, there should be an easily calculable mathematical solution for shifting from from the current X,Y position to the next X-Y position by adjusting chain lengths.

So the only scenario that I can come up with that would allow me to eliminate the chain motor feedback would work as follows:

  1. Transform the current local position into the global CS.
  2. Back-calculate the theoretical current chain length that at that point.
  3. Transform the next desired position into the Global CS
  4. Forward-calculate the desired chain length that would be needed to reach that point
  5. The difference between the two would be the amount of pulses to send down to the stepper motors.
  6. Next Loop.

Thoughts?

1 Like
4

Well, you’re out of my league with it (what’s the ‘global CS’?)…

I can say that we don’t have a solution to the inverse of the kinematics that doesn’t involve an iterative function (try something, doesn’t work, calculate error, make adjustments based upon error, try again and repeat). If you are close to start with (i.e., your initial guess isn’t far off the mark) then it should solve fairly quickly. However, ‘fairly quickly’ is a relative term and I think for your application, you need to do that during the 10ms PID cycle. I don’t know precisely how long it would take to do the forward kinematics calculation.

5

Are you thinking that simple trigonometry is adequate and just let the PID controller make up for the errors in the calculation? If so, then you should be able to find an inverse solution without using an iterative function like we currently do.

6

Global Coordinate System. I don’t know what it is called in the code. Perhaps absolute? To me, this is just where the tool tip is on the frame at any given time, as opposed to where the tool is relative to the local origin (home)

I think so. Can you see any holes in that logic? I think that the X,Y position of the tool as reported by the new encoders would have to be fairly close, or there would be constant error in position.

7

I’m by no means an expert… I’d say give it a shot. How accurate so you think the x,y encoders will be (what resolution do you expect)?

8

I am using a 20 tooth pulley, a GT2 timing belt with a pitch of 2mm, and a 2000 count / rev encoder. I think this will give a resolution of .00078 inches.

If the maslow is moving at 30 inches per minute, this means the machine would encounter about 635 encoder interrupts per second, per encoder channel. Since there are four channels overall, this would mean that the arduino would see up to 2540 interrupts per second.