Jump to content


Photo

Encoder-based PE Correction on the cheap

  • Please log in to reply
306 replies to this topic

#201 Raginar

Raginar

    Fly Me to the Moon

  • *****
  • Posts: 6138
  • Joined: 19 Oct 2010
  • Loc: Rapid CIty, SD

Posted 18 April 2013 - 07:52 AM

Keep at it orly :)

#202 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5649
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 18 April 2013 - 09:39 AM

Another business trip.. So next weekend I'll have another go using the RTC chip. Fingers crossed this will eliminate the clock drift.

#203 rpineau

rpineau

    Explorer 1

  • -----
  • Posts: 64
  • Joined: 30 May 2012
  • Loc: CA, USA

Posted 18 April 2013 - 11:07 AM

Yes you just need to enable the internal pull-up on the INT0 pin and wire the INT* output of the PCF8583 RTC to whatever pin is INT0 on the AVR you're using (and of course define the ISR in you code for INT0).
Regards, Rodolphe

#204 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5649
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 01 May 2013 - 07:49 PM

I was able to fix the timing problem without any added hardware (just got rid of delay() function call).

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:

Posted Image

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).

#205 Mert

Mert

    Skylab

  • *****
  • Posts: 4230
  • Joined: 31 Aug 2005
  • Loc: Spain, Pamplona

Posted 02 May 2013 - 08:02 AM

Hi Orlando,

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 :penny: :shrug:
Very interesting data, looks more like it now!!!! :waytogo:

#206 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5649
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 02 May 2013 - 10:13 AM

from Adaptive Correction of Periodic Errors Improves Telescope Performance (Toomas Erm, Stefan Sandrock)

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.


Doh!!!

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 :p )

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..

#207 tjugo

tjugo

    Viking 1

  • -----
  • Posts: 995
  • Joined: 06 Nov 2007

Posted 02 May 2013 - 10:22 AM

Hi,

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?

Cheers,

Jose

#208 tjugo

tjugo

    Viking 1

  • -----
  • Posts: 995
  • Joined: 06 Nov 2007

Posted 02 May 2013 - 10:23 AM

Sorry, I meant high pass filter!

Cheers,

Jose

#209 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5649
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 02 May 2013 - 10:38 AM

Jose,

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.

#210 tjugo

tjugo

    Viking 1

  • -----
  • Posts: 995
  • Joined: 06 Nov 2007

Posted 02 May 2013 - 10:54 AM

Orly,

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.

Cheers,

Jose

#211 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5649
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 03 May 2013 - 07:58 AM

OK so I did the "reset the origin every 120 seconds" and..... It sorta works. The AP600 can now maintain about 0.43px RMS (about 1.2" RMS) over a 20-minute period. This same mount can do 0.9" RMS when actively guided.

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.

#212 pfile

pfile

    Gemini

  • -----
  • Posts: 3168
  • Joined: 14 Jun 2009

Posted 03 May 2013 - 05:55 PM

nice work! it's been a very long road but it seems it was worth it.

#213 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5649
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 04 May 2013 - 03:24 AM

Posted Image

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. :rainbow:

#214 Starhawk

Starhawk

    Space Ranger

  • *****
  • Posts: 5601
  • Joined: 16 Sep 2008
  • Loc: Tucson, Arizona

Posted 04 May 2013 - 10:28 AM

Hold on- it looks like this is likey mechanical mismatch between the encoder and the mount. Move the RA axis by hand and see if it wobbles.

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.

-Rich

#215 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5649
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 04 May 2013 - 10:50 AM

Post deleted by orlyandico

#216 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5649
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 04 May 2013 - 02:02 PM

Rich, it is a mechanical mismatch. Either encoder swash or non concentricity. And its not that small - it's 500" over 24 hours.

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.

Posted Image

PECPrep output (including the bad spikes). Fundamental has been knocked down to about 4" p-p (from about 15").

Posted Image

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)

Posted Image

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.

#217 Raginar

Raginar

    Fly Me to the Moon

  • *****
  • Posts: 6138
  • Joined: 19 Oct 2010
  • Loc: Rapid CIty, SD

Posted 04 May 2013 - 08:55 PM

The truth is in the pudding sometimes. Can't wait to see a picture.

#218 Starhawk

Starhawk

    Space Ranger

  • *****
  • Posts: 5601
  • Joined: 16 Sep 2008
  • Loc: Tucson, Arizona

Posted 05 May 2013 - 02:21 AM

Egad,

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?

-Rich

#219 Starhawk

Starhawk

    Space Ranger

  • *****
  • Posts: 5601
  • Joined: 16 Sep 2008
  • Loc: Tucson, Arizona

Posted 05 May 2013 - 02:29 AM

One more thought, actually, the re-zeroing of the encoder should be much faster. This isn't PEC- all you need to know is if you are fast or slow at a single moment. Pick the drive update frequency and a nyquist criterion for measuring it, then just keep a running score.

-Rich

#220 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5649
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 05 May 2013 - 03:06 AM

Rich,

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. :grin:

#221 Starhawk

Starhawk

    Space Ranger

  • *****
  • Posts: 5601
  • Joined: 16 Sep 2008
  • Loc: Tucson, Arizona

Posted 05 May 2013 - 11:41 AM

I agree. The running average appears to be the way to go in my mind.

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.

-Rich

#222 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5649
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 05 May 2013 - 10:35 PM

They probably are...

The choice of encoder shaft mount (Heidenhain claims their blind shaft is self centering) also might have something to do with it.

#223 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5649
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 07 May 2013 - 10:26 AM

I wrote some nice Processing sketches to graph the measured periodic error in real time (pulling data off the serial port).

Without correction (this is the AP600, west-heavy, so about 15" p-p):
Posted Image

and with correction (misleading, because the mount is actually following the curve of the encoder's error):
Posted Image

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..

#224 Starhawk

Starhawk

    Space Ranger

  • *****
  • Posts: 5601
  • Joined: 16 Sep 2008
  • Loc: Tucson, Arizona

Posted 07 May 2013 - 11:53 AM

Interesting- if all else fails, 1.000" should be an off-the-shelf size. You could probably just buy some drill rod and use it.

-Rich

#225 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5649
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 07 May 2013 - 12:08 PM

A simple rod / shaft won't do.. my existing shafts are like that, and I realized that there must be some mechanism to ensure that they are trued up to the polar shaft.

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:

Posted Image

(the shaft I want made is the lower one)






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics