POCS
POCS copied to clipboard
panoptes
Allow for cameras to operate independently
I'm going to try some exposures of the comet 46P/Wirtanen tonight which is at a bright 5.3 magnitude. Would be nice to support operation where one camera exposes at 10 seconds while the other takes longer exposures (it happens to be in one of the TESS fields right now so the other camera could continue "normal" observations).
Feels like the ideal model is like a worker pool concurrency model. I can imagine the cameras finishing an exposure and sending a message to the observatory "I finished that one, now what?", and the observatory checking its queue of exposures and responding with either "OK, now do this one" or "OK, just wait for now". That would be an asynchronous, messaging based system, of course.
It would be nice to start moving to this model in some sense. It of course connects a number of ideas we have been having (links below). Part of the problem is I think we are waiting to do a big push on this when instead we should be incrementally adding. Harder to the the latter but might be the only way we can proceed. The GSoC student would help a lot in this respect but we won't see much activity on that until about June (if that project were even selected).
- https://forum.projectpanoptes.org/t/pocs-indi-support-thread/191
- https://projectpanoptes.org/gsoc-2019/
- https://forum.projectpanoptes.org/t/iconoclastic-idea-apache-airflow/171/1
- Inter-operability with e.g. SkyNet
Agreed, need to make progress in this direction. Issue is identifying manageable sized steps that take us towards the goal. I could certainly do with some pointers!
I feel like a master Issue with a check list of incremental steps would be helpful.
I feel like a master Issue with a check list of incremental steps would be helpful.
We have started this (somewhere! I'll find) but I'll dig back up and then kick-start the conversation again.
I think the first step would be to split the logging mechanism out, which should be easy to do. There are plugins for pyzmq to make it easy to just broadcast the messages and then we would just need to have some kind of central subscriber mechanism that is collecting them and writing to file. This would help with a lot of components but would obviously also have immediate impact even for the pyro cameras.
I think the first step would be to split the logging mechanism out, which should be easy to do. There are plugins for pyzmq to make it easy to just broadcast the messages and then we would just need to have some kind of central subscriber mechanism that is collecting them and writing to file. This would help with a lot of components but would obviously also have immediate impact even for the pyro cameras.
That would be really, really useful. Logging is definitely one of the non-ideal aspects of the current ad-hoc distributed cameras, and it's also one of the main dependencies that needs to be resolved in order to spin out the hardware support modules as a separate library.
Here's the page: https://pyzmq.readthedocs.io/en/latest/logging.html
I'll take a stab this weekend. The logging is screwing up some things I'm doing for the pipeline anyway.