Software options for controlling a Robotic Telescope

(This is in Uncategorized rather than Software so that folks don’t think it is about the current PANOPTES software.)

It’s a lot of work to write a control system for a telescope, especially one intended to run completely automatically for weeks at a time. Wilfred and others have done a great job at putting POCS together, and I’ve had fun contributing to it. Nonetheless, we need to occasionally consider the build vs. borrow vs. buy decision, which means:

  • Build: Continue writing our own, totally custom software.
  • Borrow Some: Use some existing libraries for telescope control, such as INDILIB.
  • Borrow Lots: Adopt an open source system, contributing PANOPTES specific features to such a system, or layering PANOPTES specific features on-top of it (e.g. depending on the extension mechanisms supported).
  • Buy: Use a commercial package for managing the scope.

I’m not aware of any commercial package that has a low-enough price that makes buying a practical choice, but the borrow options are growing more capable than they were when PANOPTES was founded.

RTS2 is under very active development, but the core is written in C++, making it inaccessible to many people. And it doesn’t appear to have support for critical items we use: Canon DSLRs and iOptron mounts.

INDILIB started as a protocol for providing access to many kinds and models of astronomy devices in a manner that didn’t require hard coding each type of device into your system (POCS does require that). In recent years a lot of additional capabilities have been added, including a sophisticated observation scheduler.

INDILIB also provides support for interacting with devices that aren’t all attached to a single computer; i.e. the protocol allows for sending messages over a network. This is a feature that the Huntsman Telephoto Array team is currently working to add to POCS in support of having a separate computer for each camera/focuser/filter wheel that is atop their mount.

Skynet is non-commercial, though not open source; from our discussions with the head of that project it seems like they’re willing to move in that direction over time. Skynet can manage observations across a network of robotic observatories, a feature we’d like to PANOPTES to be able to use for things like TESS follow-up observations, or coordinated survey operations (i.e. maximizing the duration of light curves that we can produce). One possibility w.r.t. Skynet is extend POCS with the option of being managed by Skynet, rather than to replace POCS. PANOPTES telescopes located away from high-speed internet access would need to continue to run autonomously, but telescopes with good internet access could optionally be connected to Skynet.

I’m not proposing a change in our current direction, but want to bring this up as a topic of conversation. What do others think?

These options aren’t new and they haven’t changed much since the time when we first started developing POCS. My original master’s thesis had 5 pages with about a page dedicated to each of these options (except Skynet) and a few more and why we are not using them. I will find those pages again and post for the record.

I also evaluated ROS, which I think has interesting potential. There are few cases of people adapting it specifically for astronomical observing. Obviously isn’t a domain-specific tool so there are the disadvantages of that.

This is an interesting field to keep an eye on. The broader community hasn’t gelled around INDILIB quite the way I’d hoped it would. I think that’s still the most likely thing for us to adopt if we change course. Enabling a standards based device control system would be good, but I’m glad we chose custom at the beginning as it enabled us to get as much control as possible of the hardware (especially the mount) without going through an intermediate library which might have had limitations.