ConceptFORGE

If you have a question or a comment that doesn't fit anywhere then start a topic here. As we get this forum up and running we will be adding more categories and liberally moving topics to the appropriate place.

Glad you are thinking about this. I have thought about these things for 30 or so years, off and on. Way back then, the processing power was not available to do this for low cost.

Here is what I might experiment with. Rather than try to bounce a signal off the effector and measure the time like Radar, place a speaker (Piezo) on the effector and two microphones (same Piezo) widely separated at fixed locations (this is really better suited for Wally X,Y). The electronics knows when a tone pulse was generated, and can measure when that tone was received by the mic. Take the difference in time to the mics and triangulate the position of the speaker. Actually I would measure the time from when the tone stop being sent. Much more reliable. The precision will be based on the timer resolution. The update rate will be based on the tone frequency. Reflections could pose a problem if they are strong, so a surface treatment for things (like a Wally backboard) might need to be made. You would want updates to be faster than the fastest "step rate". Do some math. What clock rate would be needed in the timer for the speed of sound and 5 micron position resolution?What could you do with a 20KHz tone? How much would the Doppler effect the received tone when moving at full speed?

see3d wrote:Rather than try to bounce a signal off the effector and measure the time like Radar, place a speaker (Piezo) on the effector and two microphones (same Piezo) widely separated at fixed locations (this is really better suited for Wally X,Y).

Actually, I was thinking about multiple emitters placed at known locations on the bed, and receiver(s) placed on the effector (although these could be reversed if it makes things simpler). If the signals were crafted properly, it might be possible to use a simple low-pass of the microphone(s) to generate an error feedback signal for the motors. I'm also not thinking so much about using impulses and timers as frequencies or Soliton pulses (then post-processing the standing waves or locating the center of the pulse). I'll have to figure out what is easiest to generate and process given the available hardware, and what provides the best bandwidth and resolution.

With stereo 24-bit 192 KHz ADC/DAC chips costing less than $1, it ought to be possible to direct synthesize and analyze some pretty complex waveforms for not much money, as long as the latency of the delta-sigma converters can be dealt with.

It depends on if you want relative or absolute position feedback also. I was only looking at absolute position.

Frequency detectors are a simple bandpass filter. Timers are in every chip made in the world today. Why make it any harder than that, if it turns out to be good enough?

Let's see, it would take a 14 MHz clock counter to resolve distance to 25 micron resolution. That is in the practical realm. A 16 bit counter would have a 1.5 meter max distance at that resolution.

If the effector was traveling at 1 meter/S, we would need to get updates at 40 KHz to see every 25 micron position change. That does not seem to be good for 20 KHz tone. The 20 KHz tone should be bumped up as much as practical.

We would have a lag based on absolute speed of movement. That could be dealt with, since inertia would not allow the speed to change that quickly, and acceleration can be controlled.

This is good stuff guys! I have been wanting to do the RF, sound, etc trick for a long time. I want to make this happen and I am willing to throw some money at R&D.

That said there are two ways you can use something like this. (well more but 2 that I will talk about) 1) Mapping the work envelope of an arbitrary robot that has good repetability but is a calibration challenge. (Wally) 2) Real time positioning of an arbitrary robot that might not even have good repetability. (DC motor Wally)

In the first scenario the latency doesn't matter. In the second, you guys have already talked about the limitations.

Jason Fisher wrote:http://www.stellamove.com/#!pump-board/c2piMore pictures of their "PUMP Board" DC motor controller. Are they only using one of these or one per motor?

I did get some more information about this. The Servomotor is a DC brush motor with an incremental encoder built in. This means that it is functionally the same thing as a stepper motor as long as the proper control electronics are supplied.

The disadvantage is it is a brush motor, which will wear out, and generate sparking electrical noise.

The advantage is that it does not lose steps, it takes much less power to hold a position, and it can apply maximum torque to keep trying to move to the next position.

With servo feedback, you can also detect when you run into a hard stop and use this for calibration without any limit switches or probes. You can also detect when one axis is not keeping up, and slow down the other axis to keep the X,Y,Z in the proper place.

Brushed DC motors have next to no torque so I assume that they have a gearbox. As long as the encoder sits after that, it may be possible to compensate for the backlash. Interesting. I'd still like to see how the speed/torque/cost compares to an equivalent stepper based solution. Also, a servo motor holding its position of course does so by correcting when the position deviates by more than a delta. Making the delta too small and the motor will be constantly try to correct its position, too large and you loose precision.

I'd agree that you can use the encoder to calibrate the bed size (running at very slow speed), but I would not rely on them as end stops. Crashing into the end at full tilt is a great way to wear out .. everything. However, once you know the bed size, you can avoid crashing or at least slow down when you get close.

I'm intrigued. A quick googling/eBaying around for "DC motor encoder" I haven't found anything particularly cheap compared to a stepper and furthermore, they all appear to have the encoder at the motor end!

I was guessing that the reason they appear to have two motors on each axis is that one of them is the actual motor, and the other is the position encoder. That doesn't explain the extruder, which appears to have just one motor, though perhaps it has a built-in encoder since the precision required isn't as high.

Ah, it's starting to make slightly more sense. An encoder on the screws of LISA should be fairly easy. For Wally it might be good enough if they could be added on the XY pulleys. I'm not sure if encoding the GUS pulleys would be good enough.