Encoder-based PE Correction on the cheap
Posted 18 April 2013 - 09:39 AM
Posted 18 April 2013 - 11:07 AM
Posted 01 May 2013 - 07:49 PM
However I have found another source of long-term drift: the periodic error of the encoder itself over a full rotation.
Initially I thought of running the mount for 24 hours and capturing data, but then I realized that I could run the mount at a higher speed so it could complete one entire rotation in < 24 hours.
And the result:
this is not a full 360 degrees rotation, it's about 200 - 220 degrees. But the sinusoidal waveform is obvious. That's probably encoder swash.
Since the encoder doesn't have an indexer or absolute positioning, it's impossible to correct this long, very slow, but very large magnitude (about 500" p-p) periodic error.
One solution is not to keep track of the absolute position, but keep resetting the origin every 1 - 2 minutes. That way the long-term error doesn't accumulate.
Another solution is to keep track of speed, rather than position. I can't get this one working right though - but keeping track of position works (except for the long-term drift due to the encoder's gross PE).
Posted 02 May 2013 - 08:02 AM
Ever since I use EQMOD, the PE-curve sometimes get "un-
synchronized" with the worm due to power failure or whatever.
Then, in order to maintain the PEC data and resync, it's
just using the flat surface on the worm-axis oriented to
a reference point and bingo.
IMHO using a little optocoupler, we could use that flat
surface or whatever other reference point, to "trigger"
the absolute start for the encoder, that might enable
PE for the encoder-swash I believe.
Just my 2
Very interesting data, looks more like it now!!!!
Posted 02 May 2013 - 10:13 AM
Likewise if the speed is low enough to make the frequency to be within the bandwidth of the control system the servo can follow the error and no position error can be seen, but the telescope will be moving with the error.
Using an indexer is not an option.. because the Arduino can't command the mount to move to the index via the ST-4 interface (at least, not in our lifetime )
I did some exploring with Freemat (darn! where was this thing all my life, and me futzing around with Excel) and... it's not possible to recover the encoder gross PE from the corrected data.
So I'm stuck. How to get rid of the slow drift... actually the slow drift is not a problem because... it can be autoguided out!
but... my design goal was 20 minutes unguided. Currently that's not possible with the 1" / minute slow drift. Definitely though the encoder tames the fast periodic errors, so long guide exposures can be done (e.g. 5 - 10 second guide exposures).
but.... I know the TDM has solved this problem. Cannot... rest..
Posted 02 May 2013 - 10:22 AM
If slow drift is the problem what is preventing you to add a digital low pass filter in your code? You already know the frequency of the drift, so it is trivial to implement the low pass filter in software with the specified cut off frequency. Am I missing something?
Posted 02 May 2013 - 10:38 AM
Might work. Not sure how to do an LPF (to extract the error term for correction) except with an FFT.
I have seen that with a 512-point FFT covering 256 seconds (1/2 of the worm period) the encoder PE can't be extracted. I suspect at least 1-2 worm periods (so, 900+ seconds) would be needed to extract the encoder PE.
It's not enough to know the encoder PE frequency - you also need to know the phase, so you can subtract it.
I'm thinking I'll just cop out. The TDM is only rated for 5-10 minutes unguided. I think I can do that level by resetting the encoder origin every 5 minutes. This ensures that the encoder PE drift doesn't get too large.
Posted 02 May 2013 - 10:54 AM
You don't need to wait to record a whole cycle to apply the filtering. Depending on the frequency you want to filter out you have to wait a short number of samples to start filtering out the low frequencies.
Digital filters easy to implement in software, and you don't need FFT or complex math to do it.
Let me try to find some samples for you.
Posted 03 May 2013 - 07:58 AM
So the encoder solution is (almost) as good as auto-guiding. It would not be terribly useful on a midrange or high end mount. On the AP600 it's not that amazing but there's a definite improvement.
I thought of regulating the axis speed instead of its position (this avoids long-term drift effects). Used the Arduino PID control library and it seems to be working... but it clouded out and I can't verify that it works.
Posted 03 May 2013 - 05:55 PM
Posted 04 May 2013 - 03:24 AM
The plot is the position error (while correcting). When correcting based on encoder position the error doesn't increase - a false measurement because the mount is getting slaved to the encoder's errors.
Here there's drift because I'm regulating the RA rotation speed and not its position - this reflects the encoder's 24-hour period error, but the graph is straight, I think this shows that PID-controlling the speed successfully controls short-period errors while being insensitive to the long-period error of the encoder itself.
Hopefully a test against PHD on a star will prove the validity of this approach. I'm growing tired of this particular project. :o still.. considering it's cloudy all the time, the time I've sunk into this has prevented me from buying stuff on astromart, so overall I'm out ahead.
Posted 04 May 2013 - 10:28 AM
Also, this is a 3" over 6 hour effect- I suggest this isn't the spot to sink a lot of time at the moment.
Posted 04 May 2013 - 02:02 PM
The SiTech guys have a spreadsheet for calculating PE based on non concentricity. Even a 0.005" non orthogonality would result in over 1000" of PE with a 24 hour cycle.
Here are the results from doing PID control of the RA axis speed (rather than tracking the axis position):
This is the best case, the Arduino + encoder can beat autoguiding (normally I only manage 0.3px RMS with autoguiding). The worst case is less pretty, but I'm not sure if it's due to seeing effects or the encoder issue itself.
PECPrep output (including the bad spikes). Fundamental has been knocked down to about 4" p-p (from about 15").
Unfortunately the 2nd strongest harmonic is the 17.2-second one. Which is from the encoder! (it's the grating period, 86164 sec / 5000 slots)
The encoder PE adds about 1" to 2" of additional periodic error. The overall PE including all the ugliness is about 5" to 6". But the numbers from PECPrep are what they are - PECPrep reports my Mach1 has 3" p-p after PEM, but PEMPro reports 0.5" p-p. So the encoder might be performing better than these graphs lead me to believe.
I guess the real test will be trying to take long (e.g. 10 minute) unguided exposures, and see how that works out.
Posted 04 May 2013 - 08:55 PM
Posted 05 May 2013 - 02:21 AM
What pain in the neck. The orthogonality itself seems to argue for special tapered fittings. I'm trying to think of ways to cause it to find its own center accurately. Come to think of it, it's a special procedure to get things centered on a milling machine.
OK, at the risk of annoying someone who is already frustrated, I'm going to back up a little bit and ask how one either (A) gets the encoder to magically give up what is needed or (B) get the data needed some other way? Note, I'm only going to post this if I feel like I made progress on the issue by the time I'm done thinking on what you're seeing.
So, I have an observation about Celestron drives: The system commands a set of drive movements which will result in perfect tracking on 1 rotation intervals, or 8 minutes in this case, if the drive repeats on one worm rotation. Now, thanks to the 8/3 weirdness, that means the real interval for seeing a "Perfect" reference come back from the drive itself is every 24 minutes. Or, in other words, if you look in on a CGEM drive every 24 minutes as your sampling point, you would conclude it was perfect. However, if the drive didn't have the 8/3 business, it would appear to meet perfection every 8 minutes (and those wacky NexStarSE mounts with the triangle wave tracking actually do this). So, the drive will come close to accurate every 8 minutes with the 8/3 error overlaid, and will be correct every 3 rotations no matter what, at which point any cumulative corrections must total out to zero, even if there is encoder eccentricity.
So, the corrections have:
(1) a set which will repeat every revolution of the worm.
(2) a set which has repeated 8 times for every worm 3 revolutions.
So, is it possible to ONLY look for frequencies matching those behaviors? One frequency is repeating 8 times in 24 minutes, or every 180 seconds, with an overlay of the worm repeating every 8 minutes.
So, if the system can filter based on these being the longest allowable periods, then that might be a way to cause it to run based on the possible drive errors, since the error in the timing for the 8/3 error is actually correct every 3 minutes, any 3 minute interval is long enough to see the entire performance of the upper drive reduction.
Now, on Milby's point about looking for a reference on the shaft, there is nothing to say the system couldn't look for the shaft reference with multiple detectors, so it would have to be visible during alignment.
Anyway, that's what I've got for now. I'm kind of swimming thinking about the overlaid functions. I feel like there should be some sort of maximum slope theorem of something to allow the system to be restricted to these inputs. Ah- I think I have it- periodically reset the definition of "Zero" on the encoder. Actually, that would be every 3 minutes. Could it be that simple?
Posted 05 May 2013 - 02:29 AM
Posted 05 May 2013 - 03:06 AM
Ah- I think I have it- periodically reset the definition of "Zero" on the encoder. Actually, that would be every 3 minutes. Could it be that simple?
I have done that - see my post 5837844 above.
Reason there's no supporting data is because the performance wasn't great. I was actually resetting the zero every 120 seconds.
If you check, 500" over 24 hours is 0.35" per minute. So resetting every 2-3 minutes should be enough. But you will still get drift (trust me, it's very obvious on the PHD graph).
Controlling the speed is actually just another way of doing the reset - because
speed = (new_tick - old_tick) / (new_time - old_time)
So long as "old_tick" and "old_time" aren't too far behind new_tick and new_time, you won't see any encoder drift.
I tried using old_time and new_time being exactly 17.233 seconds apart (so that you are reading ticks from adjacent encoder slots, and thus interpolation errors between slots would cancel out) but the problem with such a long (17.233 second) measuring interval is, the system responds very slowly to input.
Just think.. applying a 500ms guide pulse will not do very much to change the average speed taken over a 17.233-second period.
The result was my PID control algorithm slowly built up a bigger and bigger oscillation.
The current algorithm uses the instantaneous velocity (i.e. old_tick and new_tick are only 1 sampling interval apart which is 0.5 seconds). I think this is too low, because encoder jitter would screw up the instantaneous velocity.
But the algorithm seems to maintain an average velocity of 15.04" / second quite well! the graph above is for this.
Maybe I will use a 4-second running average or something to smooth out the encoder jitter.
Frankly... I think this is an optimization exercise at this point. I'm sure even with the existing algorithm one can do 5-minute unguided with a CGEM at modest pixel scales (e.g. 2"/pixel). An unassisted CGEM cannot hope to do that.
One other use case - some people need 10-second guide exposures because they're using OAG or narrowband filters. A stock CGEM cannot be used with 10-second guide exposures due to the PE. As it is, this box can turn a CGEM into something usable for these use cases.
I'd call this a qualified success.
Posted 05 May 2013 - 11:41 AM
I'm wondering if a purpose made attachment mounting and a carefully installed shaft adapter might not do the trick. While quickness is met by a thin aluminum plate and some circuit board standoffs, I would not be surprised if they were the main error source.
Posted 05 May 2013 - 10:35 PM
The choice of encoder shaft mount (Heidenhain claims their blind shaft is self centering) also might have something to do with it.
Posted 07 May 2013 - 10:26 AM
Without correction (this is the AP600, west-heavy, so about 15" p-p):
and with correction (misleading, because the mount is actually following the curve of the encoder's error):
much nicer than capturing the data with Putty and graphing it after the fact in Excel!
I did some more simulation and analysis, and realized that I cannot get rid of the 24-hour periodic error with low-pass filters (learned a lot about IIR filters though! - the smooth curve in the Processing sketches are actually 3rd order Butterworth lowpass filtered)
So I need to have some better shafts made. I goofed in my previous measurements (didn't have a digital caliper then) - measured the encoder shaft ID at 0.992" when it actually is (exactly) 1.000". So my shafts are undersize by 0.008" and the encoder wobbles on it.
I mean I had noticed this wobble before, but I didn't realize it contributed so much error.
Now hoping the person who made my original shafts would be willing to make more..
- bsavoie likes this
Posted 07 May 2013 - 11:53 AM
Posted 07 May 2013 - 12:08 PM
This is because the threads aren't that tight, so the shafts wobble a little bit. My revised shaft design (for the 1.000" ID, if ever I get this working I'll need a revised design with a 12mm shaft for the Heidenhain encoder) has a collar to ensure it's tight:
(the shaft I want made is the lower one)