Syncless center (offset mode) doesn't seem to work for celestron

Sequence Generator
1

sg_logfile_20161013221020.txt (285.4 KB)

Version 2.5.2.4

I tried syncless centering with my cge-pro but it didn’t seem to work. I tried a number of times with different settings for the telescope sync behavior but they all had the usual behavior of getting stuck at 100 pixels away or so and not converging.

I assume I am supposed to use “offset” mode for sync - and the log does show that it was enabled for the tests - except when I was trying other modes also.

I then used my own python code - which operates completely by controlling sgp and doesn’t talk directly to the mount or camera, and it converged immediately and was a few arc sec-seconds off after 2 iterations.

For the python code the initial miss with a blind slew was 478" - and the next miss was only 4.9". After that 3.9" then 2.9".

So I’m not sure what is going on. Log attached above.

Frank

2

My impression from looking at the log is that you are simply calculating the sync value yourself and keeping track of it. If so - that won’t help my mount and others improve on the centering - because the problem isn’t in the sync but in the slew. If you simply replace the mount’s sync with your own - that won’t help centering.

The centering routine needs to keep track of the difference between where it tried to slew to, and where the plate solve said it actually landed. This is very different from simply asking the mount where it is - and finding the offset from the true plate solve. When you do that, it does not include the error in the slew itself - which for me is the whole problem, and the thing that prevents the centering routine from improving after a single iteration.

I hope that makes sense - but maybe I’m missing something in what you have implemented.

Frank

3

I’m struggling with this- when SGP tells the mount to slew to a position x,y, the mount should slew to what it thinks is x,y and would report it is at x,y with an ASCOM property enquiry.

Why would the mount think it is in a different position to that which SGP told it to slew?

4

I think I see what Frank is saying.
Yes, the mount now reports it is at x,y. Obviously that is what the mount to going to report to ASCOM.
But, the platesolve, shows that the mount is actually pointing to: x+errX, y+errY.
So SGP should keep track of errX and errY and now slew the mount to x+errX, y+errY. The mount will then report that it is pointing to x+errX, y+errY, when it is actually pointing x,y, the real target location. (correction, I think + signs are required)

5

Well, yes, that’s certainly part of it. But that would be rather useless by itself…

Step 1: Update offsets (delta) based on sync using Telescope Coords and Plate solve:

[10/13/2016 10:21:45 PM] [DEBUG] [Telescope Thread] Telescope: Sync behavior set to "OFFSET", offsets updated: 
[10/13/2016 10:21:45 PM] [DEBUG] [Telescope Thread] 		 RA:  0.000485322504670431 hours
[10/13/2016 10:21:45 PM] [DEBUG] [Telescope Thread] 		 Dec: 0.00956177913366218 degrees

Step 2: Apply offsets to slew location prior to sending to telescope:

[10/13/2016 10:21:45 PM] [DEBUG] [Telescope Thread] Telescope: Using "OFFSET" sync option, updating slew cooridnates with offsets:
[10/13/2016 10:21:45 PM] [DEBUG] [Telescope Thread] 		 RA:  1.34937421139356 hours
[10/13/2016 10:21:45 PM] [DEBUG] [Telescope Thread] 		 DEC: -70.8526604430886 degrees
[10/13/2016 10:21:45 PM] [DEBUG] [Telescope Thread] Telescope: Slewing to J2000 RA: 20.2406131709034 (20h14m26.21s) Dec: -70.8526604430886 (-70°51'09.58")
[10/13/2016 10:21:45 PM] [DEBUG] [Telescope Thread] Telescope: Slew received J2000 coordinates, mount requires JNOW, converting...
[10/13/2016 10:21:45 PM] [DEBUG] [Telescope Thread] Telescope: Slewing to JNOW RA: 20.2695464547823 Dec: -70.8033991166732

Also looks like the RA (RA: 1.34937421139356 hours) is getting double converted but is for display only.

It looks like everything is working as expected…

Thanks,
Jared

6

I think you are still missing the point. If you are only looking at the error between where the telescope thinks it is - and where plate solve says it is - and correcting the slew position based on that - it will have no improvement for my mount - and others - over normal sync/slew centering. In fact - it is sync/slew centering - it’s just that SGP is now doing the sync.

That will not work for my mount and it explains why it is not converging.

The goal of centering is to go to X and have it land at X. If it lands at X + dX the goal is to make dX zero.

The point of syncing is to make the telescope coordinates match the plate solve value when the telescope is not moving. That is neither necessary nor sufficient to make the dX value above go to zero.

If instead of looking at the difference between the mount’s coordinates and the plate solve - you look at the difference between the slew target and the subsequent plate solve after the slew - you will see that after one iteration my mount would point with an error of a few arc-seconds - and will continue to converge in more iterations - which probably won’t even be needed. It is much more accurate and much faster.

Otherwise this will have no improvement for my mount and others - that don’t have a problem with syncing, and that are capable of very accurate centering when combined with a plate solve.

Frank

7

OK - Here is a log from my own centering routine - again using only SGP to do the imaging, plate solving - etc. It shows an initial miss on the first slew of 478 arc-seconds - but after taking that error into consideration, the next slew has an error, based on the plate solve after it slewed, of only 4.86 arc-seconds. SGP and its centering routine have never come close to that after many iterations - and this happened in the second slew.

You are saying that the SGP routine centers well - and you make effort to show the user how far the plate solve position is from the target - yet your feedback system for doing the centering only looks at the error of the encoder compared to the current position - and never looks at the error of the target position from the plate solve. Yet that is what you show to the user in the centering routine - because you know that is what really matters: how well did you actually center on your target location.

If that error that you show to the user is obviously the thing that is important to the user, why don’t you use it in your feedback loop so that you are minimizing it - instead of something else?

So - would you consider making this slight change in logic - so that all mounts would be able to center well, including celestron mounts? Focus on the error in the final plate solve vs. the slew target - i.e. the error you are already showing the user. Not the final plate solve vs. where the mount thinks that it is.

Frank

slewing from encoder position 20.093043 -73.076757
To encoder position 20.233333 -70.862222
Slew complete. Landed at encoder position 20.232860 -70.852536 with encoder miss of -25.560805 34.871264 - distance 43.236093 arc-seconds
take exposure
do solve

Try 1 has solved error: ra, dec, dist = -478.701384 4.340442 478.721062 arc-sec
slewing from encoder position 20.232857 -70.852514
To encoder position 20.242198 -70.863428
Slew complete. Landed at encoder position 20.241758 -70.853680 with encoder miss of -23.756124 35.093578 - distance 42.378209 arc-seconds
take exposure
do solve

Try 2 has solved error: ra, dec, dist = 1.899740 -4.479441 4.865635 arc-sec
slewing from encoder position 20.241751 -70.853615
To encoder position 20.242163 -70.862184
Slew complete. Landed at encoder position 20.241729 -70.852113 with encoder miss of -23.412259 36.254998 - distance 43.157372 arc-seconds
take exposure
do solve

Try 3 has solved error: ra, dec, dist = -0.035024 3.888722 3.888880 arc-sec
slewing from encoder position 20.241739 -70.852092
To encoder position 20.242164 -70.863264
Slew complete. Landed at encoder position 20.241692 -70.852477 with encoder miss of -25.476613 38.833322 - distance 46.444426 arc-seconds
take exposure
do solve

Try 4 has solved error: ra, dec, dist = -1.965663 2.253042 2.989988 arc-sec
slewing from encoder position 20.241686 -70.852477
To encoder position 20.242200 -70.863890
Slew complete. Landed at encoder position 20.241714 -70.853507 with encoder miss of -26.249149 37.377120 - distance 45.673482 arc-seconds
take exposure

1 Like
8

Hi FWIW I tried the new syncless routine with a Paramount MX+ and the best it get me is within 1 arcmin of error, no matter how many time it iterates.

Cheers,

Jose

9

That is surprising because there is a way to do syncless centering that won’t help mid range mounts but it should work fine for a paramount even if it isn’t properly syncd to the sky. So if the new syncless routine doesn’t work for paramount either, maybe there’s a problem.

The basic methods can be tested just with pencil and paper and doing it manually. It’s just a couple additions and subtractions to compensate for the measured error in the slew.

Frank

10

I wanted to resurrect this thread because I finally got a chance to play around with offset centering myself, and my experience is the same as Frank’s. I also have a CGE Pro so I suppose it is not surprising. With either type of centering, it typically goes something like this:

  1. First rough slew gets the target within a few minutes of center. How close depends on how good my alignment model is.

  2. First plate solve and slew gets me within about 100px or about 40".

  3. Second plate solve and slew gets me within about 80px or 30".

  4. For all remaining iterations this remains unchanged, with the error in RA and DEC being essentially the same every time.

There was a discussion on TeamCelestron about this and while the reasons are complicated, Celestron mounts will miss a close synched slew very accurately and repeatedly. This repeatability in the error is what Frank is talking about exploiting. My mount will miss by right around 80px in RA and 15px in DEC every time after the first synched center. So, it seems that it should be a simple matter to look at where the mount ended up with plate solve and then send it not to the target coordinates, but the target coordinates corrected by the error on the last slew. As Frank pointed out, where the mount thinks it ended up is meaningless.

Anyway, I hope progress continues on this. I typically compensate for the predictable error when framing, but better centering would be invaluable when the sequence has a pier flip and when doing mosaics.

Tim

11

Thanks for posting, Tim. Yes there is no change in centering performance after the move to syncless centering for my cge-pro mount - because I think they are not correcting for the offset that really matters.

I don’t know if the developers a) Assume it is all working as well as possible b) Don’t understand the error is due to a “landing” error rather than a sync error, or c) Do understand the nature of the problem - but don’t want to fix it on principle - because it would be a form of “voodoo” fix to overcome a problem in the mount that shouldn’t be there in the first place.

Anyway - I spent a lot of time on this problem and demonstrated that the centering of this and other mounts could be on the arc-second scale - and very fast - if syncless centering were implemented properly.

And I see there was another posting after yours of someone with what appears to be the same problem. Any time the centering process hits a limit and the subsequent ra/dec errors are constant - that’s a sign that this other slightly different way to do syncless centering would work great - as opposed to showing no improvement at all over normal sync’d centering.

Frank

12

It’s more d) working well for most and more pressing things to address.

The way that you’re proposing does not fit well into the current flow of things or we would have implemented it as a test by now.

Unfortunately we have limited time and resources and must decide where to focus our effort. At the end of the day we decide what goes into our product and when.

Thanks,
Jared

13

Of course. But you also seem to welcome feature requests and have at least started progressing in the direction Frank and I are suggesting. I was just contributing some of my experience with the hope that it would help with the progress. Now that I know it is not a priority, I’ll bow out.

Tim

14

Tim,
That particular comment was not directed at you or anyone in particular. Requests sometimes tend to get “championed” and while we do realize that these features are important we still have to consider the “greater good” when looking at when to implement features. Since we release very often there is, occasionally, an expectation that requests will get fulfilled within days or weeks…but we’ve been trying to shift our development to be more focused.

Because of some choices we made about the centering routine in the early days it would require a fair bit to fit the new recommendation into that model. So I wouldn’t expect much to happen on this issue for at least a few months…it may even have to be a 3.0 thing. Currently Slewing and Syncing are separated processes and with Frank’s suggesting they would need to be more closely coupled. At a minimum this means we need to have the slew coordinates available when we do a sync to calculate the offset, but these things happen fairly “far apart”. While this may seem trivial it has pretty wide sweeping implications and is not as straightforward as it may seem. For instance if we stored the slew coordinates on the telescope object during the slew and then during the sync calculated and stored the offset, this would likely break disparate slew and sync behavior. So it needs to be more atomic, and we’re not currently structured for that as currently everything is encapsulated in a single object with multiple calls. At a minimum this means we need to push things a level higher so the centering routine would do this logic which is currently nicely encapsulated in the telescope.

Yes, we certainly do welcome requests. And we have even stated that we would do further investigation into this but don’t currently have a timespan in which to do it.

Thanks
Jared

15

That may have been a little premature. I played around with this a little more and realized it really only applies to Auto Center and Center Here and was able to crowbar in an implementation. It hasn’t been tested with actual equipment but it’s basically the same as the previous offset sync except that it only happens on the “Validation” step and it uses the reference position (slew position) as the “expected” to calculate the offset.

Performing a “Solve and Sync” with “Offset2” will do nothing, same behavior as “None”. “Offset2” only gets used when Auto Center or Center Here are executed.

Should be out in the next beta. You can find it as “Offset2”

Thanks,
Jared

16

Thank you Jared - this is very good news. Your earlier reply on Oct 14 implied the solution was working fine and there was no reply to my explanations for why it still was not working - so I didn’t know if you realized the problem was still there.

In my case imaging with sct the lack of accuracy meant I could not use automatic centering in sgp at all. If the field is small enough that the residual errors strongly alter the composition - then the centering simply becomes unusable. And without centering you can’t do multi-target sequences. And you can’t do mosaics. As a result, all my work with sgp has involved manually centering a target - and then imaging that one target.

This all changed recently when I started doing hyperstar imaging. In that case the centering error is more negligible and I was able to make much better use of SGP’s features - many for the first time. I used the mosaic tool for the first time and found it to be extremely well implemented. I had heard people rave about it - but didn’t realize how good it was until I tried it.

So if you implement the centering routine so that it works with cge-pro - it won’t be an incremental improvement - it will open a door for me and others to make use of features that were otherwise unavailable.

I look forward to trying the beta - but I want to clarify one thing. Yes - this landing error issue only affects the situations that trigger the automatic centering routine. And yes - there is no need to keep track of the landing offset - it can be thrown away once the target is centered. But in my case I do in fact value being able to solve/sync. That works just fine with my mount - and losing that feature is undesirable because it improves the pointing model locally - and keeps TheSky and any other software in sync with where the mount is pointing.

So I think users divide into two classes

  1. Their mounts don’t mind syncing - so solve/sync is fine - but use syncless centering for Auto Center and Center Here - because there is no reason not to - and some mounts require it. There is no inherent advantage to syncing the mount in the centering process.

  2. Their mounts should not ever be sync’d - so disable solve/sync - but still use syncless centering as in (1).

I realize the syncless centering should be tested more to make sure it works - but I think there is a way to avoid things being too complicated - and that is to use syncless centering by default - and disable solve/sync only for those mounts that can’t sync. I’m just trying to have a way that I can use syncless centering - but still be able to do solve/sync.

Thanks,
Frank

17

Thanks, Jared. I look forward to trying it.

Tim

18

I should be able to add this in. I think what we’ll eventually end up with is this:
(AC/CH Behavior - Sync Behavior)

  • Sync - Sync: “Current” Behavior. I don’t really want to change this as it’s always worked great for myself and many others.
  • Offset - None: Uses offsets for AC/CH, doesn’t sync (for those mounts that don’t like syncing)
  • Offset - Sync: Uses offsets for AC/CH, but can still be synced via Solve and Sync
  • None - None: Never syncs and never updates offsets. For those cases where “Mount knows best”

Now to figure out how/where to do this. The “easy”, and likely wrong, place is just where the Sync options are currently stored. As this is now controlling the Centering Behavior as well as the Sync behavior they probably need to be split as such. But for the time being they will likely just be a single option until there is some additional data.

Thanks,
Jared