search

indilib / indi-3rdparty

INDI 3rd Party drivers repository
https://www.indilib.org/devices.html
GNU Lesser General Public License v2.1
124 stars 208 forks source link

celestron-aux bugfix: track target was not updated after manual slew #872

Closed ijessen closed 8 months ago

ijessen commented 8 months ago

fixes #871

knro commented 8 months ago

Thanks, how is the tracking performance?

ijessen commented 8 months ago

Thanks, how is the tracking performance?

Not bad with the default PID parameters, but the polling rate absolutely needs to be higher than the default (I use 5hz). Very sensitive to leveling and alignment. I can take 5 second exposures pretty reliably, up to 10 seconds if the alignment is very good.

The PID is an interesting approach. I've thought about experimenting with adding feed-forward (based on an analytical solution of the expected rates at the tracked target) but honestly it's working well enough for my purposes (short exposure EAA and planetary capture).

Only true pain point is that it's completely out to lunch before the alignment converges (at least 3 sync points), which sometimes makes alignment more difficult if tracking becomes accidentally engaged. I haven't dug into that yet and it might be a process error on my part.

knro commented 8 months ago

5Hz does not cause any jitter? I actually started without any PID initially, but the tracking was bad. Part of me believes that the PID loop is an overkill but I'm not sure how the hand control achieves such a good tracking performance as reported by many users. Perhaps your proposed feed-forward is a better solution? What do you mean by analytical solution exactly?

Currently we have mount modeling which is not active by default since I found the Nearest algorithm to be the most reliable.

ijessen commented 8 months ago

Honestly I haven't dug into the jitter. Empirically my 5-10 second exposures look pretty tight, so whatever jitter is present doesn't seem to have a significant impact.

PID is a great fly swatter. Maybe there are alternatives, but it almost always works to control poorly modeled or inconsistent systems - exactly like what we have here.

As far as feed-forward, all I was thinking was seeding the rates (i.e. PID outputs) with calculated values for the target location (i.e. derivatives of the eq->alt/az conversions) after a reset. That would help the controller reach steady state more quickly, rather than having to come up to speed from 0. Might also allow for a lower update rate, since convergence was one of the reasons I had to bump it up.

I haven't played around with mount modeling at all yet. I switched to the SVD math plugin becuase - why not? - but couldn't say what difference, if any, it made.

Any reason not to pick this PR in the meantime? I'm absolutely going to continue to experiment with tracking (at least until I give up and get a wedge - but it's pretty good as is!), but this little PR is just addressing a single bug.