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: initial support for slew limits #874

Closed ijessen closed 8 months ago

ijessen commented 8 months ago

The Evolution mount seems to be pretty robust to crashes (ask me how I know)- that said, it would be better not to tempt fate.

This PR implements initial slew limits. It's sufficient to prevent tracking, an incautious goto, or a manual slew from causing too much havoc. That said, it doesn't promise to prevent you from doing something stupid. For example, if the mount is already beyond a limit and you (or an automation script) command it to move even further into the no-go zone, it will (at least briefly) until the next polling period. A more robust solution that prevents all motion further into a no-go zone would be better, but this is enough to start.

Limits are set as angles relative to the index (i.e. startup position if no HC connected).

knro commented 8 months ago

Thank you, how would this affect the mount in different configurations?

  1. Alt-Az
  2. Alt-Az on an equatorial wedge
  3. GEM
ijessen commented 8 months ago

Conceptually, mount type shouldn't matter - axis limits are axis limits, regardless of the orientation of the axis. I purposely stayed away from relying on alignment for this. It's based solely on angle (i.e. encoder value).

I don't have access to a GEM mount, but have tested with az/alt and wedge.

Because Celestron encoder values are not absolute and can be (and are) reset, it's important to pay attention to component startup order and/or ensure the mount is appropriately leveled and north-aligned at start up.

Limits should be set with a reasonable buffer to any danger area. The limit is only checked on the polling rate (1 Hz by default) so there can be significant (few degrees) encroachment into the no-go zone if the scope is slewing at full speed.

knro commented 8 months ago

Great, thanks. Perhaps also add this to saveConfigItems(..) as well?

ijessen commented 8 months ago

Great, thanks. Perhaps also add this to saveConfigItems(..) as well?

I did! But it was a force push after I had already opened the PR so if you weren't reviewing on GH maybe you need to pull again?

knro commented 8 months ago

I'll merge this and you can submit another PR for the saveConfigItems