celestron-aux: initial support for slew limits #874
Conversation
|
Thank you, how would this affect the mount in different configurations?
|
ijessen
force-pushed
the
celestron-aux-limits
branch
from
a816f1f to
6dafa66
Compare
|
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. |
|
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? |
|
I'll merge this and you can submit another PR for the saveConfigItems |
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).