Hello, welcome to Clear Sky Institute, Inc.
My name is Elwood Downey. I am the founder and president of Clear Sky Institute, Inc. I would like to describe my experience and explain that we offer complete observatory control system implementations and engineering services targeted to the astronomical community.
It has been my joy and privilege to be involved with telescope and observatory control systems since my days as a programmer at Kitt Peak National Observatory beginning in 1979. You may already know of the venerable XEphem, my labor of love with roots going back to 1981.
Here are some of the larger projects for which I made significant contributions:
- From 1993 to 1998 I had the good fortune to collaborate with Dr. Robert Mutel on a project which became the Iowa Robotic Observatory where I honed my skills at the following topics:
- servo control and PID tuning
- remote observing
- CCD calibrations
- precision photometry
- astrometry and guide star pattern matching
- fully autonomous robotic scheduling and execution
The system was named OCAAS (Observatory Control and Astronomical Analysis System) and was entirely successful. It remains in full use today allowing some 300 astronomy students every semester to utilize a telescope 2,000 miles from the University of Iowa. After that experience I incorporated CSI Inc in 1999 as a vehicle for full time work in this fascinating area.
- I worked for several years as a contractor for Optical Mechanics, Inc.. My primary direction was to implement the control system for their line of .5 - 1.0 m telescopes, which I did successfully. OMI purchased this system and released as the open source project named Talon. Their telescopes are used by customers in several countries around the world.
OCAAS also plays a key role in the Sierra Stars Observatory Network (SSON) as described in this note by the founder:
Elwood Downey developed the Observatory Control and Astronomical Analysis Software (OCAAS) originally in the late 1990s that is used to operate the Sierra Stars Observatory telescope in California and the Rigel Telescope at the Winer Observatory in Arizona. OCAAS was bought by Torus Technologies (now OMI) and renamed Talon. The excellent code that Elwood wrote for this development is in continuous use running observatories in locations around the world.
Founder of Sierra Stars Observatory Network (SSON)
In 2004 I had the good fortune to become the Principle Engineer for the 2.4m Magdalena Ridge Observatory in New Mexico, USA. In addition to serving to oversee all technical design and construction of the building, telescope and dome, I also designed and lead the development for the software that integrates the telescope, dome and environmental monitoring equipment, accessible both at the observatory and remotely via Internet.
From 2008 through 2011 I was the control systems engineer for EOS Technologies (now defunct) where we designed, built and installed telescopes up to 2.4m diameter all around the world. Some of these telescopes were completely controllable via an INDI interface.
I was contracted to design and lead the implementation for the Fabra-ROA Baker-Nunn refurbishment project in Spain. This upgraded a legacy Baker-Nunn camera to become a fully automated remote observatory in the Spanish Perrenes mountains. The Reference Manual for this installation gives a good idea of what my current systems can do.
Since 2012 I have been chief software engineer for the Large Binocular Telescop Interferometer . My primary challenge has been to control the real-time path length controller, a combination of camera, image processing and piezo electric actuators to maintain path coherence on the 2.4 um reference beams from each light path. The entire control system is built using INDI technology.
Thus, over time I have been improving my approach to control architectures. My latest package is built around INDI, the Instrument Neutral Distributed Interface language I invented expressly for efficient remote observatory control, although it may be used in any domain, not just astronomy. INDI is fully supported by XEphem, is used by other applications such as kstars and has an active community web site.
From these and other experiences, I now have a stable and robust code base upon which I can easily and efficiently build more such systems. Please contact me if you would like to discuss how I may assist in your next observatory automation project.
INDI Control System Architecture
The core of INDI is the idea that all information is captured in Properties. Properties are small typed XML packets that contain anything from telescope azimuth to current wind direction to a camera image.
The following diagram shows the basic architecture of an INDI control system.
Start at the bottom to see several individual INDI Drivers. Drivers bridge the details of a device to the world of INDI Properties. Some drivers provide Properties related to a particular hardware device. But Drivers may also offer abstract services, such as scheduling or target prediction, so they are not limited to hardware interfaces. Think of an INDI Driver then as an interface to any kind of resource that is useful to an observatory. The Driver bridges the details of the service to the world INDI Properties.
Next skip to the top and notice the boxes representing INDI Clients. An INDI Client is any process that wishes to utilize the Properties provided by INDI Drivers. It is not limited in any other way. Clients can be rich GUI applications, command line scripts, watchdogs, or any other applications. They may be written in any language, from GUI's written in Java or Qt, to scripts written in shell, Python or Perl. The only requirement they share is a need to communicate with INDI Properties to access and control the observatory services they require.
In the middle, between Clients and Drivers, is the INDI Server. Think of this as an intelligent router. It filters and directs INDI messages between Clients and Drivers so only those messages for which they have an interest are sent to a given Client or Driver, thus eliminating extraneous traffic. The INDI Server does not otherwise interpret the INDI messages it handles and thus it can operate in a very efficient yet generic manner. Over time my implementation of the INDI Server has improved to the point where it consumes less than 2% of a typical PC-class machine even with a full complement of Clients and Drivers at a busy observatory.
It is useful to note that it is possible to chain together multiple INDI Servers. Since the INDI protocol is nearly symmetric, an INDI Client may in fact be another INDI Server. This can be useful in order to deploy an INDI Driver on a machine optimized for a piece of hardware, such as a camera, and yet provide the functionality of that Driver seamlessly on a wider INDI network. Note also that each INDI Server can be configured as to the INDI Drivers for which it allows communications. This allows, for example, certain highly critical Drivers to be rendered invisible to outward facing nods on an INDI network.
INDI Server produces complete logs of all activities from Clients and Drivers. The level of detail can be configured to four levels, from simple connection requests to full message protocol details. Drivers can also add their own messages to these logs. The logs are stored in simple ASCII format and each entry is automatically time stamped and marked as to Client or Driver of origin.
The connection between an INDI Server and an INDI Driver is simply the stdin, stdout and stderr channels common to all POSIX processes. The INDI Server forks each Driver and arranges file descriptors for all subsequent communications. This arrangement also allows for easy debugging during Driver development. The INDI Server also serves as a watchdog by automatically restarting any Driver if it should fail for any reason.
The connection between an INDI Server and an INDI Client is a tcp/ip socket on a well-known port, 7624, which has been officially recorded with IANA. This allows complete worldwide network interoperability among Clients and Servers. Although INDI itself does not address security, secure connections from Clients to Servers can be accomplished by simply using ssh tunneling of this port. Our GUI clients contain this ability internally without need for separate tunneling setup. Using tcp/ip also provides for a heterogeneous computing environment, for example Clients might be running on Windows and Drivers might be running on Linux; the only requirement is that all message traffic adhere to the INDI protocol.
Also, all INDI status and commands may be programmed and scripted through a simple but very flexible python library.
A variety of telescopes, cameras, motion controllers, domes and other devices already have INDI Drivers. There were either developed at CSI Inc and many other are being developed by the active INDI user community at community These can be leveraged to reduce development effort for all new applications. New drivers can be developed in a straight forward manner against a simple API.
Our code base includes rich modular GUI clients that can be modified to present specific information to users in a pleasing and efficient manner. These can be tailored for basic users to the most sophisticated engineering personnel or scientific users. These are written in pure J2SE Java for the ultimate in portability to all major desktops including Windows, Mac OS X and Linux.
There is also a standard suite of command line tools. These set or get atomic INDI properties and can be utilized by any scripting language to create arbitrarily complex applications written entirely by knowledgeable users on top of the core observatory infrastructure. The tools can be scripted in python, c/sh, perl or tcl to name a few.
A word about the scheduler. The idea is it accepts individual observing requests, sorts them in an order that optimizes for minimum zenith angle subject to constraints, performs the observation and collects the results for subsequent dissemination and analysis. Each request may specify a variety of constraints, including:
- group priority
- minimum solar separation
- maximum solar altitude
- minimum lunar separation
- maximum lunar illumination percentage
- maximum lunar altitude
- minimum target altitude
- specific UTC start time and tolerance or
- bracket of no-sooner-than and no-later-than dates and times.
Any set of INDI properties may also be specified as constraints. For example one might specify a minimum seeing value if this data is available on the INDI network.
Requests are described in an XML format. A GUI client is provided for making simple requests, or more sophisticated requests can be generated with any XML editor or generated from customer web pages using php. All requests are collected in a queue. New requests can be added or deleted at any time. The queue is resorted after each request completes so it can react to changing circumstances and accommodate Targets of Opportunity.
The actual work to be performed by a request is completely general so long as it can be expressed in terms of INDI properties. In this way, the scheduler can perform any functions available on the observatory INDI network, such as utilizing various instruments or accessing INDI services, without ever being rewritten.
In short, INDI provides the following advantages:
- Robotic: Fully capable of remote operation via the Internet in all respects, including GUIs, scripting and queued observing.
- Efficiency: Only the compact XML messages travel the network; GUIs or other intensive applications remain on the client side. It is entirely possible to control an entire observatory over a 56kbps modem (except for image data).
- Portable: INDI clients can be distributed transparently among systems running Windows, Linux and Apple Mac OS X.
- Extensible: The protocol is self-describing, so clients can easily discover and utilize new services with few or no coding changes.
- Uniform: Concise Drivers bridge disparate hardware and services onto the generic INDI messaging infrastructure.
- Safety: Critical reactions to weather or other adverse conditions can be handled entirely within the contained Driver infrastructure, without relying on diverse Client behavior.
- Scripting: Since all functions are performed by INDI, everything can be controlled by "get" and "set" command line tools which are provided in the core INDI suite. These in turn can be utilized by any scripting language such as bash, perl, python or tcl.
- Performance: Devices with particular hardware requirements, such as array processors, can be transparently chained into the collection of managed INDI resources.
- Security: Indiserver chaining makes it simple to hide certain specified drivers or services within the architecture while allowing outside access to other components.
- Queuing: Automatic scheduled activity can be defined and executed by a completely generic mechanism, relying on the self-defining nature of the INDI protocol for the specific actions to be performed.
Consulting ServicesA young man is eager to test drive his new car. He finds a deserted road and guns it up to 120 mph. But then the car sputters to a stop. He tries and tries but it will not start. Frustrated he starts walking. He finds an older man sitting on his porch sipping tea. The old man agrees to help, gets his tool box, and they walk back to the car. The old man opens the hood, looks around for a short while then picks up a hammer, gives a single hard tap then asks the young man to try it again. The car starts right up. The young man is amazed and asks how much. The old fellow says "That will be five hundred and one dollars." The young man says that's a lot for just a tap. The old man says "Oh the tap is just a dollar, the rest is for knowing where to tap".
I have a mature framework ready to work for you and the experience to fit it into your situation. If you are interested in discussing further how we can work together, please contact me directly.
A working relationship I have found to be particularly productive is to be involved early in your project, so together we develop a common set of expectations. This eventually leads to a list of devices to be controlled and specific performance criteria. This can be as simple as a new camera driver, or as complex as a complete observatory with dome, telescope, weather station and remote robotic scheduled operation. I can also function as a chief consulting engineer, contributing to the writing of Statements Of Work, contract evaluation criteria and participating in selection committees. I have accumulated experience at over a dozen major observatories so I can help define a vision, suggest hardware and refine functional requirements, as required. I can charge by the hour or by the project.
Although I am the principal human resource at CSI, Inc, I have well-established relationships with expert electrical, mechanical and software engineers with whom I have worked well in the past who can be brought in as required for specific projects.
Thank you for your time and attention. I hope to hear from you soon.
President, Clear Sky Institute, Inc.
8274 North Sunset Ranch Loop
Tucson, AZ 85743
Last edited 18 April 2014.