Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of Observatory Conditions #1

Closed
joshwalawender opened this issue Dec 6, 2013 · 0 comments
Closed

Handling of Observatory Conditions #1

joshwalawender opened this issue Dec 6, 2013 · 0 comments

Comments

@joshwalawender
Copy link
Contributor

Hi all,

I have a question on the philosophy of the observatory conditions. There are things like weather.safe and mount.slewing and camera.exposing which typically have two possible values and which are critical for decision making in the state machine. In each while_(state) function, I query those conditions and check to see if they match the expected situation for that state.

Should I query them at the beginning of each function and populate a variable/property, then use that variable/property in the logic or should I query the condition multiple times. For example, consider a while function for something like the slewing state:

currentCondition = "slewing" weather.query_condition() # populates the weather.safe property with True or False mount.query_slew_state() # populates mount.slewing if weather.safe and mount.slewing: ## do stuff for getting ready state else: ## this means conditions don't match, so we need ## to figure out what to do based on how they don't match if not mount.slewing and weather.safe: ## we're done slewing so move on to imaging or some other state if not weather.safe: ## park because weather is not safe

Compare this with an alternative in which each test of weather.safe (or any other condition) queries it:

currentCondition = "slewing" if weather.safe() and mount.slewing(): ## do stuff for getting ready state else: ## this means conditions don't match, so we need ## to figure out what to do based on how they don't match if not mount.slewing() and weather.safe(): ## we're done slewing so move on to imaging or some other state if not weather.safe(): ## park because weather is not safe

This second example will make 3 queries to weather and 2 queries to mount compared to a single query to each in the first example.

I'm inclined to use something like the first situation so we query each property only once during the execution of the function. The reason I prefer this is that even though each function should take a very short time to execute, it might happen that a condition changes halfway though the execution of the while_(state) function. If that happens, the logic may get totally screwed up as a conditional statement evaluates differently at different positions in the function code.

Anyway, I wanted to see if there were any thoughts on this before I refactor the while_(state) functions I've written to use that methodology.

-Josh

PhysicsFTW pushed a commit to PhysicsFTW/POCS that referenced this issue Feb 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant