Draw-Wire Calibration/Positioning System

Draw-wire sensors are a low-cost, low-complexity, high accuracy method to measure distance and triangulate x/y position.

A current kickstarted CNC project called “Goliath” uses this system to achieve 0.1 mm accuracy. I propose developing a similar system for MaslowCNC.

I have written to a company (Micro-Epsilon) to inquire about suitability and cost of their sensors (MK88 or MK120). I provided the following guidelines:
———————
Goal: triangulate x/y position
Working area: 4 x 8 feet
Distance needed: approx 9 ft (2800 mm)
Desired accuracy: 1 mm or less
Speed of router: 600-800 SFM
Frequency of reading: 50 Hz or more (to provide feedback to the cutter)
Output: digital or analog
Cost: $200 or less
———————
I welcome any/all ideas/guidance on this proposal!

  • Jonathan
6 Likes

I think draw wires are a great way to go! Ultimately I would love to see the chains replaced by cables which both move the machine and work as draw wires.

I wouldn’t rely to much on Goliath as an example they are well over a year behind their kickstarter schedule and as far as I know they don’t have a working machine :slightly_frowning_face:

Goliath’s campaign called for August 2018 delivery, so only a couple months overdue. In many KS projects that’s way ahead of schedule.

However, if you read the comments the natives are restless and the pitchforks and screams of lawyers and refunds abound. Those, obviously, are from backers who never read the actual backer agreement and likely think it’s a slow delivery Amazon. The updates are backer only, but the comments imply they’ve changed the scope (whatever that means) of the project and seem to be having some big issues.

I did a quick review of the Micro-Epsilon MK88’s datasheet. It’s a potentiometer with a string (well, wire, but you get the idea). They say it’s a +/- 10% tolerance 1K ohm pot (i’d guess that’s a typo, since I found a 0.1% linearity 10 turn for under $20usd, linearity is more important than actual ohm tolerance for this). Seems like it wouldn’t be super hard to DIY one for a whole lot less - but it’ll still have cable sag (in the sensor cable, not the chain) issues. The examples in the Micro-Epsilon data sheet had the cables vertical, other than a fixed length horizontal section, meaning cable sag isn’t a factor in the example. I’m not sure what one of these gadgets would do for us, other and eliminate chain stretch as a factor. Seems they’re still susceptible to sled stick and cable sag, but I’m just a moose.

2 Likes

That sag would depend on the tension on the cable, and it could be much less than that of an equivalent length of chain.

If the wires/strings are providing the measurements that locate the router bit, do they have to originate from the same positions as the centers of the motor axles? It seems that the kinematics would need to be altered to work with a separate measurement device, and that might simplify things.

1 Like

glad you found out what goliath uses.I had asked a few weeks ago with no response. the draw wire looks cool. Someone needs to splice the DNA of a gear motor into it, then we would have the perfect solution something that can measure AND move the sled. .

Not sure how usefull draw wire sensor is in itself. It can tell the maslow cnc that the location is either correct or incorrect, but if the gear motors can’t correct position you still end up with a piece that is not as precise.

1 Like

I believe that the sensor wires on the Goliath only provide feedback on where the Goliath “is” on the cutting board. The driven movement of the Goliath comes from the drive on the triple sets of wheels. Getting feedback on the exact location makes the control a “closed loop control system”. The wheels are told where to go, the wires give feed back where it is, the control corrects the wheels for any slip or mis-location.

Here is a excerpt from one of their communications:

Goliath CNC positioning system
During the campaign, we showed you our sensor system necessary to triangulate the position of the robot and define the work area. The sensors you saw were prototypes, and what we did in these weeks is make them a fully finished, working and accurate product.

The main job has been redesigning the mechanical system inside the sensor to increase the accuracy of the wire length measurement. We cannot show the details for patent reasons, but we can say that we enhanced wire winding system and the electronic components.

The tests
We run some tests, and the results were great: with the old internal configuration of the sensor, we registered an error of 30 mm on a distance traveled of 300 meters, thanks to the redesign of the wire winding system you can see that the error registered is today between 0 and 0,1 mm .

Here the old and new sensors’ configurations compared

After this validation, we are now redesigning the sensor to give it a better usability and manufacturability . Here some sketches and mock-up of the design both of the sensors and their basement. We will give you more details soon!

The next few weeks will be full of news about both the software and the wheels . Regarding the software, we will meet a potential partner with a strong experience in the CAD/CAM software for the woodworking industry, which is very interested in support Goliath CNC project. And the new design of the wheels is going to be prototyped in the next days!

We really cannot express how excited we are to see every part of Goliath CNC taking shape, and we cannot wait to share everything with you!

End of excerpt.

So for what its worth, I do not think it is a dead project, but rather a complicated one taking a while to get commercialized. Looks like they have made SIGNIFICANT progress with the sensors, even applying for some patents.

I waited an extra year for the Shaper Origin, and even at release it did not have all of the software features promised/shown at shows. Now just 9 months later it has had multiple software upgrades and is a very useful and easy to use and precise and accurate tool. I just don’t like to use it to cut large sheets down as I don’t like hanging on to it that long.

Ed

1 Like

I have written to a company (Micro-Epsilon) to inquire about suitability and cost of their sensors (MK88 or MK120). I provided the following guidelines:
———————
Goal: triangulate x/y position
Working area: 4 x 8 feet
Distance needed: approx 9 ft (2800 mm)

closer to 11’ if you are going to have the sensors near the motors

Desired accuracy: 1 mm or less

0.5mm is what we are aiming for with the maslow, the sensors need to beat this
by at least 2x as we are moving in reaction to the sensor

Speed of router: 600-800 SFM

actually, it’s under 50 inches per minute

Frequency of reading: 50 Hz or more (to provide feedback to the cutter)

I think currently we are trying to check our position at ~20Hz, 50 would be
fantastic

Output: digital or analog

output needs to be digital, analog introduces too much variation (the resistance
of cables connecting it matters, exact voltage levels matter, resulting in the
need to calibrate the sensor)

Cost: $200 or less

first find what’s possible, then worry about the cost. But on the note of cost,
are you meaning $200 per sensor or $200 per pair ($100 per sensor)? With the
maslow costing ~$600, adding $200 is a major cost, only justified if it really
does increase the accuracy drastically.

As noted, there will be chain sag on the sensor (hopefully not much due to the
light sensor wire, but it’s got low tension as well)

The good thing is that the position detection and the motor control are already
separate in the Maslow, this makes it much easier to replace one without
affecting the other. We should do some work to make them more clearly
independent.

David Lang

This does not bode well for anyone else trying to do the same thing (unless they
decide to sell their redesigned sensor)

David Lang

The PID loops run every 10mS, so we might want 100Hz or better.

No, it doesn’t. But I do think it does point out that they too have required a “closed loop” control system to get the accuracy and preciseness. Shaper uses the “dominoes”, and Goliath the “sensor” feed back.

From my “laymans” position, I think that effort in getting Maslow some type of control system like this would be a good bet. We would not need to calculate all of the sags, stretches, weights, calibration procedures, and only you guys know how much other stuff, and let the “feedback system” tell the control where it is.

Easier said than done, I know, but closed loop controls are not a new thing. I was down at Axiom CNC headquarters (here in Columbus) last weekend for their expo. Their low end machines are open loop steppers, but their high accuracy machines have closed loop controls. Somehow they get that feedback from the motor itself, as the screw shafts need to break to not be accurate.

Anyway that I can help I will.

Ed

Except it looks like the sensor is just a potentiometer connected to a spool connected to a wire, likely with a constant tension spring in there somewhere, shouldn’t be too hard to duplicate for a lot less than $200usd (or, if you prefer, a couple Benjamins or C-notes). You determine the length by connecting both ends of the pot to (say) 0 and 5V, then measure the voltage at the wiper. That’s why it needs a highly linear pot, otherwise you’re back to not knowing how far the wire is pulled out very accurately.

If we’re not getting an accurate measurement of sprocket position that needs to be addressed (has anybody actually measured the encoder’s accuracy?). Next that needs to accurately be turned into chain length (stretch will alter this, can it be quantified?). Then chain length needs to be adjusted to remove any sag, then finally accurate sled motion (i.e. friction and similar, either removed or compensated for) need to be sorted out. Won’t that give an accurate sled position?

@madgrizzle and @johnboiles are pretty close, if not already at, having an accurate way to determine where the bit hits the wood, Wouldn’t it be better to try and figure out what’s not working in the current hardware/firmware rather than adding a band-aid. Run what we brung?

1 Like

Closed loop controls are called servos, been around for quite a while (1931 for numerical control, earlier for big gun positioning, from Wikipedia. I didn’t really dig into the difference between servos and selsyns, but (to sorta quote the x-files it’s out there).

The stepper vs servo war has been around longer than I’ve been learning about CNC. I see lmgtfy has added DuckDuckGo (rather than the clearly superior name DuckDuckMoose), click here . You’re on your own deciding if it’s cute or snarky

1 Like

The Maslow is a closed loop system, that’s how we are able to use DC motors
rather than steppers.

The question is what the measurement is that closes the loop. On the Maslow,
this is the position of the sprocket (i.e. how much chain have we let out)

Because of this, it’s not that big a deal to replace the ‘where are we’ that
calculates the current position from the chain lengths with one that returns the
current position from measurements.

David Lang

Wow, that is really great news to me. Now we need a great brainstorm from someone on what that new measurement can be… Thanks for the enlightenment.

Except it looks like the sensor is just a potentiometer connected to a spool
connected to a wire, likely with a constant tension spring in there somewhere,
shouldn’t be too hard to duplicate for a lot less than $200usd (or, if you
prefer, a couple Benjamins or C-notes). You determine the length by
connecting both ends of the pot to (say) 0 and 5V, then measure the voltage at
the wiper. That’s why it needs a highly linear pot, otherwise you’re back to
not knowing how far the wire is pulled out very accurately.

The current position is one step per 0.0003" or one pulse per 0.008mm

since this is over a 3m+ range, this is an accuacy of about one part in 400,000
or ± 0.00025%

there is no pot in the world, even if you spend thousands of dollars on it that
can measure to this accuracy

If we’re not getting an accurate measurement of sprocket position that needs
to be addressed (has anybody actually measured the encoder’s accuracy?).

we have measured that the encoder is producing the right number of pulses/rev (a
bit obove 8000, we have not validated beyond that. As I said in an earlier post,
if the encoder was horribly bad and had encoder pulses off by 30%, that would
translate into an error of 1/10,000 of an inch. This isn’t something we need to
worry about.

Next that needs to accurately be turned into chain length (stretch will alter
this, can it be quantified?). Then chain length needs to be adjusted to
remove any sag, then finally accurate sled motion (i.e. friction and similar,
either removed or compensated for) need to be sorted out. Won’t that give an
accurate sled position?

that is what we are working to do. The chain stretch and sag are what we are
trying to figure out how to compensate for.

@madgrizzle and @johnboiles are pretty close, if not already at, having an
accurate way to determine where the bit hits the wood, Wouldn’t it be better
to try and figure out what’s not working in the current hardware/firmware
rather than adding a band-aid. Run what we brung?

we want to have @madgrizzle and @johnboiles be able to use their cameras to
test the results of the improvements we make in the current code.

We know that the current calibration routine is doing the wrong thing, and we
know there are errors in our current math. We should be looking at those as
well. But the math is very hard and not many people are willing to dive into it.

David Lang

I’ve been looking at these absolute encoders. They keep track of how many turns a shaft has taken (12 or 14 bits) as well as the current orientation of the shaft (another 12 or 14 bits). That’s some pretty tempting resolution… They would need some imagination to use them in the draw-wire manner, maybe something like the way the tuning capacitor is driven on an old radio set?

Why don’t you just hook a spool to the end of the gearbox of the current motor? You don’t need much wire to move 10-12 feet and probably could wrap it around a spool without overlap. Just vary the diameter of the spool along the vertical with an eyelet at the middle to ensure that the same amount wire is feed out per revolution.

So I’m trying to think about how to mount these things. Would you place them at the same location as the center of the motor shafts, with some kind of mounting bracket, and then attach them to the top center of the router motor, again with some kind of mounting bracket? That would try to measure the chain length, except for the wrap on the sprocket. We know that triangle. One is the hypotenuse, (center to center) and the other is derived from that and the “angle” from horizontal from the bit center to the sprocket center.

A great idea, but we would have to think about the router motor’s z-axis movement.

One problem with them is that they need to be zeroed when they power up, and I haven’t found a way to send a saved value to them. That might not be too bad if the moving end can be disconnected and allowed to retract all the way before zeroing, then re-attached to ‘measure’ the sled’s location when you power up for a session. Otherwise providing ~10mA of 5V to the sensor when not in use would maintain its readings.

I’ve been looking at those as well and picked up a pack of RS422 driver chips. I
hope to get @bee to make me up a new driver board that has one of these hooked
up. I haven’t talked to him about this yet :slight_smile:

Hooking one up to the existing motor output shaft instead of using the current
encoder would be interesting.

Since it will return absolute position, you may not need a real-time system and
be able to drive this from a Linux system (as long as it has reasonable PWM
output), just query the encoder position each cycle through the PIC loop.

Now, this does loose the turn count on a power cycle, but it would be able to
have you remove the chains, turn the sprockets to a specific pin at 12 o’clock
and then you hook the marked link over that sprocket and are good to go.

note that the current encoder is the equivalent of 13 bits (8k steps/rev)

Trying to use something else to hook the encoder to is an interesting problem.
Assuming that you use a line on a spool
You have to deal with:

  1. Tension/sag/stretch on the line you use
  2. What do you do with the ‘extra’ of whatever (if you spool it up, your spool
    diameter increases as you take in line)
  3. You have to account for different angles of the line leaving the spool

The speed feedback from the motors will suffer a bit, but I think we can
probably still make it work.

David Lang