Goertzel demo (capacitive encoder?)

ManAtWork

I saw the goertzel demo at the "chat with Chip" webinar with that big capacitive sensor pad that works like a "radar". Suddenly a possible application popped up in my mind: This could be used to build an encoder for measuring rotation angle. PCBs are much easier to make compared to glass discs with patterns of ultra-fine etched lines. And capacitive sensing much less sensible to dust, oil and mechanical shock.

Of course a sensor with just 4 quadrants doesn't give enough accuracy but we could use more and thinner PCB traces. 256 lines on a 2" disc should be no problem. This would result in 64 full electrical periods. If we could divide each period into 1024 interpolated steps we'd get 16 bits resolution for a full revolution alltogether.

Such a product already exists, see https://www.digikey.com/product-detail/en/cui-devices/AMT112Q-V-4096/AMT112Q-V-4096-ND/5034549 for an incremental or https://www.digikey.com/product-detail/en/cui-devices/AMT203-V/102-2050-ND/2278846 for an absolute version. Those can resolve up to 4096 steps per revolution or 12 bits. Sounds not bad but what they don't tell you is that they have an internal sampling period of 100µs and output the quadrature signal interpolated to the internal time slices. If an external counter is counting the signal it suffers from an unknown delay of 0 to 100µs between actual movement and counter position because you don't know when the actual sampling of position takes place. This leads to jitter and noise and is bad for doing accurate high speed servo control.

I think this could be done much better with the propeller.

Mickster

CUI's don't seem to be too much of a problem for the Odrive

evanh

Most would be happy with a 10 kHz servo loop but ManAtWork is gunning for some obscenely fast loop times. That's a potential downside of using any sort of comms link. You're limited to some predetermined sampling bounds of that device.

EDIT: I guess there is also potential for a buffered lag effect irrespective of what the sample rate is.

ManAtWork

Don't get me wrong. I don't need exaggeratedly fast loop update rates. A delay of 100µs would be absolutely tolerable if it was *constant*. You could easily compensate the lag by adding the last measured velocity times the (known) delay time.

However, if the exact sampling time-points are unknown then the delay becomes non-constant. The internal sampling frequency of the encoder and the external loop update rate of the servo controller produce aliasing by mixing two unknown frequencies.

I just can't say often enough that any random jitter is something to avoid if you want to machine smooth surfaces at high speeds. I'm not the only one complaining about that effects. Check this report from Jon Elson:
https://sourceforge.net/p/emc/mailman/emc-developers/thread/4DFC13BB.4020109@pico-systems.com/#msg27669457

Mickster wrote: »

CUI's don't seem to be too much of a problem for the Odrive

Yes, they work. I also used them in two projects. You notice the difference only if you tune up the gain of the velocity loop as much as possible and if you have a high quality optical encoder to compare to.

Rayman

I was wondering if it could make a low cost but robust joystick...

evanh

ManAtWork wrote: »

However, if the exact sampling time-points are unknown then the delay becomes non-constant. The internal sampling frequency of the encoder and the external loop update rate of the servo controller produce aliasing by mixing two unknown frequencies.

That's basically asynchronous in nature then. Not the greatest implementation for something you want to be synchronous. It's possible that ramping up the polling rate might produce an oversampled effect. The higher the oversample, the more precise the response becomes.

cgracey

Instead of long Goertzel accumulation times, we could do very short ones with a rolling buffer and a running average. That would keep the jitter to a minimum, but still give as much accuracy as is wanted.

ManAtWork

Yes, a rolling buffer would give best performance as delay is always constant.

However, this wouldn't be absolutely necessary. As long as the delay is known it can be compensated. If the sensor processing and servo calculations are done inside the same CPU everything is known anyway.

If we'd use two seperate chips, one near the motor and one in the controller cabinet (because capacitive sensing doesn't work with long cables) then we could start the accumulation exactly in the moment when the remote controller request it (over serial communication) and not at some asynchronous event.

Cluso99

I haven't followed the thread, but can you utilise the counter to determine time lag between measurements?
The counter is a free-running 64-bit counter of P2 clocks, so you can take a copy at any point in time to another and fully determine the elapsed time between points.