I have no relationship with ASCOM other than that I think they are doing great work with Alpaca. I wrote this because it makes me sad to see so many people not understanding what Alpaca is and why it is awesome. I believe Alpaca represents the best in class attempt at remote observatory control, and sets the framework for a future with much richer control surfaces than we have now
I have not found a good description of what Alpaca is, how it is different from ASCOM, in what ways it breaks free from Windows, or why it is really important for the future of astrophotography. So I wrote this.
At a very high level, Alpaca is about decoupling control software from astrophotography hardware. It creates a standard protocol for control software to talk to astrophotography hardware over industry standard technologies that are platform independent and work over a network. If you don’t want to Remote Desktop / VNC / Team Viewer into a computer running on your mount, Alpaca is for you, and you can use this now, with just an ASCOM software upgrade. If you want a future where you can control all your astrophotography equipment from macOS inside your house, with no computer running at the mount at all, Alpaca is for you (but we are not quite there yet).
I think the ASCOM team was in a bind over naming. The ASCOM “brand” gives weight to Alpaca. It comes from the same world as the forerunner in astrophotography control systems. But that name brings with it confusion over dependency on Windows. Alpaca builds on the knowledge gained through ASCOM, but it is not ASCOM.
To explain Alpaca, I look at a world before ASCOM, what ASCOM provided when it came along, and what Alpaca now does in place of ASCOM
The World Before ASCOM
You have some control software that you want to use to control some hardware, your control software needs to know how to talk to that piece of hardware. If I have a different piece of control software that I also want to talk to the same piece of hardware, my software also needs to know how to do that. Two things are required to achieve this (I don’t consider the case where the control software directly interfaces with hardware, that is pretty rare).
1. The hardware manufacturer must write a driver that exposes control functionality for each operating system.
2. The control software developers need to update their software to speak to that driver.
That means that a hardware manufacturer has to write code for every operating system they want to support. It also means that the writers of your chosen control software have to support the hardware you own, by extending their software to talk to that driver.
This sucked for everyone. If I was using an obscure piece of tech I had to hope that my control software supported it. If I want to use software on an operating system that my hardware manufacturer did not write drivers for, I’m out of luck, even if my software developer is willing to extend their software.
ASCOM came along and solved this for Windows. It created a set of standard interfaces for astrophotography equipment control that, encompassed all* non device specific workflows. For example, capturing an image of a specific duration, rotating a filter wheel to a specific slot or parking a telescope mount. As long as my hardware manufacturer supplies an ASCOM driver, my software developer only needs to support communicating with ASCOM and not individual drivers and their software will work with any device that has an ASCOM driver. In this sense, ASCOM is known as middleware. It sits in the middle of two sides of a control system and acts as a mediator so that as long as both sides can speak to the mediator, they can speak to each other (through that mediator, not directly). This solves the many to many problem (many different pieces of hardware x many pieces of software = lots of work), and was a huge boon for astrophotographers because suddenly you could swap out an old camera for a new one and as long as there was an ASCOM driver, the existing control software would pretty much just work (Reality is, of course, more complex, but that’s the theory).
This is great. Except it emerged in an era where Windows was strongly dominant, and so was only ever implemented for Windows. It could have been similarly implemented on other operating systems, there is no technical reason why not. Other OSs would need different drivers anyway, and they could have been created “ASCOMLinux” compliant, for example. But that never happened. So we were stuck with ASCOM on windows and not much else otherwise until fairly recently. INDI and others have made progress on Linux, etc, but take a fundamentally different approach to distributed control.
The Future with Alpaca
Today we have new paradigms in software engineering. Windows is no longer dominant. The internet is (or more specific, TCP/IP and HTTP are) ubiquitous. But the fundamental problem of needing middleware still exists. It’s a good software engineering pattern, because it solves the many-to-many problem. I still don’t want to wait on my software developer to update their app to support my new camera.
So this middleware concept is really important, and Alpaca tries to imagine what middleware in 2020 looks like.
There are a few key insights about what astrophotographers want that lead to Alpaca.
1. Remote observatory control, be that from indoors or across the world.
2. Greater choice in what operating systems we use.
3. Easier system set up.
4. Not to be reliant on control system software developers updating their software to support new hardware. Likewise software developers don’t want to have to support every piece of hardware directly.
This requires a many-to-many solution (hardware to control software), that isn’t reliant on any specific operating system, that is easy to use across a network, ideally that just works.
Alpaca takes all the great work on standardization done in the ASCOM project, specifically the work they did in generating a nomenclature of astrophotography control systems, and extends it to meet these criteria for 2020.
Whereas ASCOM provided the middleware on Windows between hardware drivers and control software running on the same machine, Alpaca defines a middleware protocol (or an API) between control software and hardware interfaces running on any machine on a network. Drivers and a windows machine are not strictly necessary any more, though in practice I expect they will be around for a while. Alpaca is setting the standard for the next 10 - 20 years and change like this can be slow.
In Alpaca all that is defined is that standardized interface that allows software developers to instruct a piece of hardware to take a specific action, e.g. for a camera to take a frame, or a filter wheel to rotate to a specific slot, etc. This standard interface is not platform dependent. It’s just a language and communications protocol specification. It operates using web technologies (TCP/IP, HTTP, REST, JSON) that are supported on every platform, in every programming language.
It specifies that devices should be exposed through web server endpoints, with actions enacted by control software calling those endpoints with specific parameters, as specified by the Alpaca API. This uses industry standard technology. Web Servers accessed over TCP/IP for network level communication, REST over HTTP for calling a specific action, and JSON for the response value. This is a paradigm used by the vast majority of web connected software out there.
These endpoints can be written in any language and run on any hardware (including directly on embedded control chips in astrophotography hardware) and are incredibly easy to build. The industry standard nature of these technologies means that there are extensive tool kits and documentation for building them.
The control software doesn’t care where the endpoint is running, it could be on the local machine, it could be on another machine on the local network, it could be across the world connected to my network via a VPN or other means. It also doesn’t care what software or operating system that end point is running. As long as that end point is coded to the same specifications that the control software is, they can talk. That specification is Alpaca.
On a control software side, this now means that anyone can update or write software in any language, on any operating system and have access to the same standardized hardware control that previously was available only to Windows users. Software can be written with direct support for Alpaca and there will be no need for an ASCOM installation on the control software system. I do not believe that any control software exists that natively supports Alpaca today, but everything is in place for that. No one has implemented this yet AFAIK.
So what are these endpoints Alpaca compliant control software can talk to and why don’t you need drivers any more? Well, they can be anything that can be coded to the Alpaca specifications, specifically that they operate as an HTTP Service, that speaks the Alpaca REST protocol.
They come in three forms.
1. Devices that directly expose an Alpaca control endpoint over the network. These devices would be connected to a network via Wifi or wired via ethernet. Their embedded control software runs a webserver on startup that talks the Alpaca protocol. Control software that speaks Alpaca can directly control these devices with no additional hardware. Imagine a camera with just an ethernet, no more USB. Or a mount that works with any software over wifi, without needing hardware specific software vendor support. In my mind this is revolutionary, and absolutely the way forwards. Network embedded devices are huge. They don’t require any computer at the telescope. There are no drivers. They simply connect to your network directly. Of course this requires new hardware designs to implement the embedded network endpoints. I believe that this is a smart move for manufacturers, since they would no longer need to write or maintain (this is huge!) OS dependent drivers. They update their firmware as needed, but they do this already, and this firmware contains the Alpaca endpoint.
2. Drivers that expose an Alpaca endpoint on a computer with a physical (e.g. USB) connection to the device. This is the more traditional driver route with a twist. Hardware manufacturers would still have to write drivers for different observatory side computer operating systems, but those drivers would all expose Alpaca network endpoints, to which any Alpaca compliant control software could connect over the network. This can be done today by a hardware manufacturer with no hardware changes. Of course it’s not as neat as the first format, because it still requires OS dependent software and a computer at the mount.
3. The existing ASCOM windows framework can actually expose Alpaca interfaces for all devices physically connected to the machine running ASCOM. Existing installations can be Alpaca compliant with an ASCOM software update and nothing else. This means that control software that speaks Alpaca, running on any OS, on any device, can now control equipment connected to a plain old ASCOM set up at the observatory. Double bonus, any Windows based control software that speaks ASCOM can already control any device that speaks Alpaca over the network (With an upgrade to the latest ASCOM platform). No more Remote Desktop or Team Viewer. Just run your control software on any machine and connect to your devices over Alpaca on the network.
I’m personally very excited for devices that expose alpaca over an embedded network interface. These are very stable, don’t require a computer at the mount, and enable me to completely break free from specific OS requirements.
You should be excited too. This will make your life easier. And there is a really neat slow upgrade path while hardware manufacturers build these embedded systems. Running an existing ASCOM system on Windows at the mount you can move to Alpaca supported control software by upgrading ASCOM on both ends. This works today. As new control software becomes available you can remove ASCOM from the control end and simply rely on Alpaca conformity. You could even move to control software on macOS or Linux (or an iPad app, or a web browser, etc, etc, etc) if it supports Alpaca. As hardware supports it you can slowly reduce dependency on a computer at the mount by connected network embedded devices directly to your network.