Wait for tracking adjustment #332
Conversation
The tracking adjustment for ioptron uses `move_ms_<dir>`, which places the mount in `guide` mode (as indicated by the status) but is non-blocking. If the tracking adjustment is too long (~ > 4-5 seconds) and no blocking is done the machine will try to transition to next state. There is a condition on the state machine that the mount must be in `tracking` to `observe` so it gets stuck and then tries again. After 5 iterations of same state without successful transition the machine will give up and park the mount. Here we just wait out for up to 30 seconds until back in `tracking` mode. Note: Ideally we should never have to have an adjustment of 4-5 seconds, so not entirely sure what is going on there. Seems to happen most on first adjustment after pointing but also depends on where mount is poining. This is a problem with PAN001 that we have had and might not be an issue on other units.
Codecov Report
@@ Coverage Diff @@
## develop #332 +/- ##
===========================================
- Coverage 83.81% 83.51% -0.31%
===========================================
Files 51 51
Lines 3368 3409 +41
Branches 422 432 +10
===========================================
+ Hits 2823 2847 +24
- Misses 404 415 +11
- Partials 141 147 +6
Continue to review full report at Codecov.
|
|
Fixed major drop. Would still be nice to get some more in the |
* Mount simulator will always report a fake offset * Fixing call to `get_ms_offset` so it correctly uses axis (has no practical effect on ioptrons, which don't allow for differing rates between the axis) * Renamed `test_run` -> `test_run_complete` so easier to run in isolation * Fixing docstrings
| @@ -501,10 +501,10 @@ def get_ms_offset(self, offset, axis='ra'): | |||
| """ Get offset in milliseconds at current speed | |||
|
|
|||
| Args: | |||
| offset (float): Offset in arcseconds | |||
| offset (astropy.units.Angle): Offset in arcseconds | |||
There was a problem hiding this comment.
Support for using type annotations. :-)
There was a problem hiding this comment.
Actually the astropy units was one of the things I was concerned about. I'm hoping it works seamlessly for them.
pocs/mount/simulator.py
Outdated
| offset (astropy.units.Angle): Offset in arcseconds | ||
|
|
||
| Returns: | ||
| astropy.units.Second: Offset in milliseconds at current speed |
There was a problem hiding this comment.
How does the type (Second) match with the comment saying it is milliseconds?
There was a problem hiding this comment.
Actually this should be aQuantity anyway. I'll get it changed.
| pocs.next_state = 'parking' | ||
|
|
||
| # If we came from pointing then don't try to adjust | ||
| if event_data.transition.source != 'pointing': |
There was a problem hiding this comment.
I'm confused about pointing vs tracking vs observing w.r.t. moving / adjusting the mount.
There was a problem hiding this comment.
In what sense? For what the mount reports or for the actual state? Maybe some documentation of the states will eventually help with this.
| if event_data.transition.source != 'pointing': | ||
| pocs.say("Checking our tracking") | ||
| try: | ||
| ra_info, dec_info = pocs.observatory.update_tracking() |
There was a problem hiding this comment.
Seems like we should move more of this code into POCS or Observatory. i.e. these on_enter functions should have little logic of their own. Thoughts?
There was a problem hiding this comment.
Yes, good point. Doing that now.
There was a problem hiding this comment.
I've done this but removed the say output that says what correction was. It's been useful for me the last few days to watch it but it's also a little too much information for the say box. Ideally we should be plotting this in real-time within PAWS. The info is delivered via the status update so information is there.
This was mostly because I've been keeping any say calls exclusively in the states (except for the setup in core.py). Not sure if that is necessary or not.
* Move wait on tracking adjustment to inside the method * Fix return type docs for ge_ms_offset
The tracking adjustment for ioptron uses
move_ms_<direction>, which placesthe mount in
guidemode (as indicated by the status) but is non-blocking.If the tracking adjustment is too long (~ > 4-5 seconds) and no blocking
is done the machine will try to transition to next state. There is a
condition on the state machine that the mount must be in
trackingto
observeso it gets stuck and then tries again. After 5 iterationsof same state without successful transition the machine will give up
and park the mount.
Here we just wait out for up to 30 seconds until back in
trackingmode.
Note: Ideally we should never have to have an adjustment of 4-5 seconds,
so not entirely sure what is going on there. Seems to happen most on
first adjustment after pointing but also depends on where mount is poining.
This is a problem with PAN001 that we have had and might not be an issue
on other units.