Skip to content

Latest commit

 

History

History
79 lines (54 loc) · 4.4 KB

gsoc-2019.md

File metadata and controls

79 lines (54 loc) · 4.4 KB
Raw
heading sub_heading layout title slick_carousel slick_images banner_image hero_button show_site_name textline feature_button services show_news show_discourse show_twitter partners date
Project PANOPTES
Discover New Worlds
landing-page
GSoC 2019
false
text href
false
text href
false
false
false
2019-02-04T20:59:29.000+00:00

We will be posting project ideas for GSoC 2020 during the month of February. Check the GSoC 2020 page for updates.

Google Summer of Code 2019 - Project Ideas

Scheduler Updates

The PANOPTES scheduler is currently a simple weighted dispatch scheduler that is ignorant of the rest of the PANOPTES network. In order to support our next phase of the survey we would like to make some improvements to the scheduler. These improvements will help to support both “survey” and “follow-up” modes of operation. The scheduler should be able to handle both network connected units (i.e. “give me the best target right now”) as well as offline units (i.e. “give me good targets for the next 6 months”).

Suggested Milestones:

  1. Simple cloud-based scheduler to return a single target for a single unit. Most of the mechanics of this are done, it would involve setting up Google Cloud Functions and gluing some pieces together. First steps would involve becoming familiar with existing setup.
  2. Add “survey” and “follow-up” distinctions for single unit.
  3. Incorporate multiple units into target decision. This is mostly useful for follow-up mode, where we want to try and schedule a target to be observed simultaneously (or sequentially) by multiple units as appropriate.

Difficulty: Medium

Skills: Python, Google Cloud Platform (Cloud Functions)

Mentors: James Synge, Wilfred Gee, Josh Walawender, Jen Tong

Observatory Dependency Decoupling

Currently the various hardware components (e.g. mount, camera, etc) and the scheduler are tightly coupled to the main Observatory class that is used by the PANOPTES Observatory Control System (POCS). In order to support a more flexible architecture, and to handle dynamic adding/removing of hardware components (perhaps due to failure), the Observatory class will be converted to utilize Dependency Injection for major systems.

Suggested Milestones:

  1. Scheduler Injection. A first step would be to remove the scheduler creation from the main Observatory class. This will get a user familiar with the overall system and should be straight-forward.
  2. Hardware Injection. Remove the remaining hardware components from the Observatory class. Cameras have already been removed so this would involve mostly the mount and dome as well as a clear system for any future hardware.
  3. Dynamic injection/removal. In order to test a real system that is running live, help develop a testing suite that will randomly cause failures in some of the various hardware components along with successful recovery or graceful shutdown.

Difficulty: Medium

Skills: Python, Google Cloud Platform (Cloud Functions)

Mentors: James Synge, Wilfred Gee

Message-based API Design & Implementation for Components

As part of the plan to decouple the dependencies from the main Observatory class, the PANOPTES Observatory Control System (POCS) is also being converted to a messaging-based system for each of the sub-components. A zeromq-based messaging system is currently built-in to POCS but is used mainly for non-critical parts of the system. The goal of this project would be to design and implement a messaging communication API for the Observatory class and various hardware components. This is basically a form of a Remote Procedure Call (RPC) for the system.

Suggested Milestones:

  1. Design basic API for camera operation. This will involve becoming familiar with the system and designing the basic structure for how a camera will interact with the Observatory with an eye toward a system for all hardware, not just cameras.
  2. Implement system for cameras. Actually implement the system for the cameras, successfully operating a camera from message-based commands.
  3. Design API for additional hardware components. Expand the API to additional hardware as determined by the success of prior milestones.

Difficulty: Hard

Skills: Python, ZeroMQ (messaging), Hardware interaction

Mentors: James Synge, Wilfred Gee, Anthony Horton