Arduino

Arduino micro-controller boards have been around for over 10 years and designed to be highly extensible and affordable. Along with the slightly more powerful Raspberry Pi boards, they have become the go-to choice for small projects and robotics that require sensing and control. The original boards have a standardized connector arrangement that enables easy I/O expansion over parallel and serial interfaces. In Arduino parlance these expansion boards are called “shields”. As these devices are optimized for new users, the Arduino website has extensive support for software and hardware development and an active support forum. Outside schools and universities, the architecture has also found applications in industry, in my case, a ruggedized Programmable Logic Controller (PLC) version (fig.3). To make them more accessible, they are supported by an Integrated Development Environment (IDE) and an active user community. A common feature is a bootloader on the board that allows them to be permanently programmed via a serial port (normally a “virtual” COM port, using a USB to serial adaptor). They have all kinds of interface capabilities including: I²C, RS232, USB, WiFi, Analog, Digital and Ethernet. Once programmed they work stand-alone. Looking over the forum, these little boards have been used for an amazing diversity of applications. In comparison, my application is quite straightforward but requires some care to make it reliable. Arduino boards are typically programmed in the C or C++ language. (Incidentally, both Steve Jobs and Dennis Ritchie died in 2011. Ritchie, who created the C language and a large part of UNIX was largely overlooked but made an arguably more significant contribution to modern life, as these are the bedrock of modern computing, including Apple’s.) The free Arduino development environment is quite basic but usefully, there is a plug-in (from the Visual Micro website) to the Microsoft Visual Studio application that allows the Arduino, driver and Windows applications to be developed in the same environment.

fig.3 This Arduino is sold as a programmable logic controller (PLC) and conveniently has screw connectors for inputs and outputs, along with two serial ports. The analog inputs are an invitation to expand into weather sensing at a later stage.

ASCOM

The asc­om-­sta­nda­rds­.or­g site goes into great detail on the benefits of ASCOM. Fundamentally, it, or more precisely ASCOM drivers, present a consistent device interface for the mainstream software applications. These applications can command and talk to any AS-COM compliant astronomy device (physical or logical), without knowing how each and every device works. It achieves this by defining standardized commands and data for each class of device. The acronym stands for AStronomy Common Object Model and usefully the programming objects it creates are programming language independent, allowing a broad range of applications to access them. The standard extends beyond just an interface standard and it also offers tools to ensure reliable operation within a Windows operating system as well as mathematical conversions and utilities. ASCOM has been around for about 15 years and is frequently refined to accommodate evolving requirements. It is not a commercial product and relies upon, in no small part, to the generosity of a handful of volunteers. It is not perfect and in some respects needs some modernization, for instance, to ensure ongoing Windows support; some of the utilities would benefit from being re-coded in C#. There are some competing alternatives too, such as the X2 driver standards from Software Bisque, used in TheSkyX.

Each class of device has a unique set of possible commands and variables, not all of which have to be implemented by a driver. In programming parlance, these are called “methods” and “properties”. In the case of a roll-off roof (which is basically a sub-set of the more complicated requirements for a rotating dome) the useful ones include “OpenShutter”, “CloseShut ter” and “ShutterState”. My ASCOM driver for my particular roof translates these generic requests into specific serial commands that are sent to the Arduino, that in turn, after confirming to itself that the mount is parked, moves the roof and detects its position. For mature devices, these definitions are rigorous but for emergent technologies, such as weather sensing, the ASCOM community work together to define a set of definitions for the more obvious items (temperature, humidity, pressure) and at the same time keep some definitions open for new developments. The way that the ASCOM drivers are compiled creates a number of library subroutines, that can be called by any application or script. For instance, for my Paramount mount, I can control it via its ASCOM driver with a Visual Basic Script (VBS) from a command line or access it from many programs including Java, JavaScript, Cobol, Python, C#.net, the list goes on.

To support software development, the asc­om-­sta­nda­rds­.or­g site not only has downloads for the platform and distributed drivers but also has development tools and documentation. There are a couple of helpful videos on the website too from Tom How, that show a simple Arduino development, ASCOM driver and Windows application in VisualBasic. Additional links are provided for installer utilities that allow one to create your own Windows driver installer package.

Observatory Control

This is a Windows application and a nice-to-have addition. It provides all the information and controls in one place. The imaging applications may not always be running and it is useful to control the roof safely and potentially override the safety sensors too. I designed it to independently monitor rain and weather sensors too (fig.8).

fig.4 This observatory Windows app provides a basic interface to the roof, its setup and allows simple controls of the mount position so that it is tucked out of the way of the roof aperture. The Windows form allows for various control customization and endless layouts. The 4 relay control buttons at the bottom are an expansion into power control, which helps with remote operation and system resets, using ASCOM Switch .COM methods.

There are several layers of command:

  1 At the highest level it can monitor the weather conditions, automatically open and close the roof and at the same time ensure the mount is in a safe position. (At a later stage I may add functionality linked to light detectors too or a timer to enhance the intelligence.)

  2 At a basic level, it will use the standard ASCOM commands to open and close the roof. These trigger fail-safe open and close commands in the Arduino code.

  3 At the third level it uses unique commands (through ASCOM) that bypass the safety controls, for special situations. These trigger unique override commands in the Arduino code, or cause it to operate in a different mode that consistently ignores sensory information, say in the case of a small refractor that always clears the roof line.

In this implementation the application communicates to the dome and mount through a hub, an ASCOM compliant driver that allows multiple connections to a single device. In time, I might write my own, but for now the one sold by Optec® works very well for my purposes.

fig.5 Rather than test my code out on the roof and mount hardware, this simple test jig emulates the optical sensors and allows for safe and intensive testing on the bench.

fig.6 Two plywood cradles support my existing Mk2 interface box around the pier, which houses the USB system, power control and serial communications.

fig.7 Two reflective detectors, used to confirm the roof in the closed, and here, the open position. They have adjustable sensitivity for a wide range of uses and conform to IP65.

Robust Programming

With something as simple as moving a roof, we conceptually know what we want to achieve. Writing the code for both the Arduino and ASCOM driver is relatively straightforward, once you have mastered the language, use the supplied templates and know what Windows library functions you can call upon. At the end of the day, the amount of typing is minimal. The tricky bit is knowing what to type and making it work in the real world! I openly admit that my books on C were hopelessly out of date (1978) and it took quite a bit of reading and scouring the Internet for examples, as well as some forum suggestions, before the light came on. Of the three books I purchased on C#, The C# Player’s Guide by RB Whitaker was best suited for my needs, since it dealt with the C# language and Microsoft’s Visual Studio developing environment.

We take a lot for granted; armed with a roof remote control and the mount software, our brains instantly compute and adjust our actions based upon the position of the roof and mount and their response, or lack thereof. We must translate that adaptive intelligence into the world of computer control. Our program requires robust strategies to cope with life’s curve-balls. For example; the roof might not open fully, two programs access the roof with conflicting commands or a prolonged delay in responding to a command causes a hang-up in the calling application, the list goes on. At every stage in the programs, one needs to consider fail-safe options, error handling and an ordered exit when things go wrong. The best way of writing code is to anticipate the potential error states and design them into the flow from the start. This makes for a more elegant outcome, that is also easier to follow. Murphy’s law rules; in the case of Three-Mile Island incident, the all-important switch for the pressure relief valve had an illuminated indicator. Unfortunately, that indicated the position of the switch rather than the position of the pressure relief valve, with disastrous results. I have seen some sophisticated drivers on the web that assume commands are followed-through. My engineering background makes me more cynical; I use roof position sensors for closed-loop feedback to ensure that when the shutter state says it is open, it is, rather than should be.

fig.8 The weather sensor array consists of an anemometer, a cloud detector from AAG and a Hydreon RG-11 rain detector, that has programmable sensitivity and a simple relay output.

Within C and its relatives, there are programming pitfalls too. The language is very compact, in that many commands have abbreviated forms and code sometimes resembles Egyptian hieroglyphics. It also relies upon precedence, which determine the order of computation in a mathematical expression. A single misplaced semi-colon can alter the entire operation. Thankfully the development environment tools often identify these mistakes before it even attempts to compile code, but not in every case. The trick is to build and test the code progressively, either from the lowest level subroutines up to the main loop or the vise versa. During the development phase, I did not wish to use the actual roof and mount hardware and in the case of a roll-off roof, it is easy enough to make a simple test jig with a few switches for the roof, rain and mount position sensors and a LED in series with a resistor to monitor the motor control outputs (fig.5). This emulates the roof hardware and the entire program can be checked for every possible combination and sequence of inputs, within the comfort of the office.

In addition to general good practice, ASCOM lays down some rules that reduce the likelihood of unexpected behavior or crashes. For instance, if an application starts to communicate to a particular focuser through its ASCOM driver, it normally locks out others from using the same focuser. When an application finishes with it, the code must release the driver for use by another. That seems to be quite a restriction but it has some logic behind it. If two applications try to communicate with the driver at the same time, it is entirely possible that the responses from the driver can get mixed up and directed to the wrong application.

It is quite tricky to manage; if two people ask you two separate questions at the same time and you answer both, with a “yes” and a “no” , how do the interrogators know which answer is meant for them? In ASCOM, it is possible for multiple devices to communicate to a single device through a special ASCOM driver called a “hub”. This is especially relevant with mount drivers, which often require logical connections to multiple applications. These hubs use a number of techniques to queue up the interrogations and ensure that each gets the intended response. Considering the project here, since I want the maximum imaging sky view, it is necessary to incorporate mount controls to move the mount to a safe park position, before the roof closes.

The C# language has a comprehensive error handling process that provides an opportunity to fix things before a major crash, or at least provide a useful warning message to the user. The most likely issues will be associated with serial communications and as these should not be fatal I intend to “catch” them with a warning dialog that asks the user to try again or check connections.

Communication Protocols

The ASCOM templates provided in the developer pack define the protocol between the mainstream applications and a device. When using C#, these typically involve passing and returning strings and logical parameters using predetermined methods of the device’s class. On the other hand, the communication protocol between the Arduino and the PC is entirely the developer’s choice, as is the communication medium. In this project the medium is good old RS232 from the 1960s and consists of a serial data stream using +/-12 volt signal levels at a pedestrian 9,600 baud (bits per second). By way of comparison USB 3.0 can transfer data up to 5,000,000,000 bits per second. RS232 though can happily transmit over 100 m at 9,600 baud and since the volume of traffic is minimal, robustness is more important than speed. There is a snag, however, in that the time for a message to transmit is slow in computing terms and it has the potential to tie up a PC while it is waiting for a response. With such an ancient interface too, there is sometimes a need to ensure the message got through. There are several ways around this, some of which make use of the multi-tasking capabilities of modern operating systems.

Two possible schemes are:

  1 Commands to the Arduino do not require a response but it periodically transmits its status. The incoming status is detected by the driver and a recent copy is maintained for instant retrieval.

  2 Commands are echoed back to the PC, along with any additional status information. The PC monitors the responses, which confirm the communications are working and decodes the additional information on request.

fig.9 The electrical systems are mounted in waterproof containers onto a plywood panel. From the top; power switches, Arduino controller, mains junction box, mains distribution box, DC power supplies and the NUC sits in a sealed food container at the bottom for easy access along with its external solid state drive. The three reflective sensors, two for the roof and one for the mount are mounted to the walls. Illumination is provided by an 1P65 LED strip around the top of three walls.

In this particular case, I use scheme a), with the Arduino receiving commands in the form xxxxx#, where xxxxx is a command word. I have the Arduino transmit its sensor status once every 4 seconds in the form $a,b,c,d,e,fg#, where a–g are status flags or sensor values. Presently I only make use of a–c, reserving d–f for potential expansion. The symbols # and $ are used as “framing” characters, which make it easy for the PC to isolate commands and status values. This makes some sense with a roll-off roof, since an open or close operation takes about 20 seconds to complete and the Arduino does not wait for the command to complete before returning control to the PC. The ASCOM driver in this case nimbly responds to all commands and in the background, detects incoming serial data and updates the status.

Hints and Tips for the Arduino Code

There are no templates here to help you and one starts with a clean sheet. The Arduino development language is similar to C++ with a few exceptions and additions. The www­.ar­dui­no.­cc website has extensive learning resources, designed for a wide range of abilities. It is worth looking over the language reference since there are a number of simple high-level functions that greatly simplify communications, timers, string handling and input/output. The basic design for the code is shown in fig.10. This shows a simple loop that includes a serial port monitor, follows up on roof movement commands and periodically reads and transmits the sensor status every 4 seconds. Within this loop is a one-line lifeline called a watchdog. This is a simple timer that is reset every loop. If for whatever reason it does not and it times-out, it automatically resets the Arduino and it re-boots, which in this application has no adverse operational consequence.

There are two serial ports on the Comfile® Arduino module and I use one for programming and the other for operation with the PC. The Arduino uses the Data Terminal Ready (DTR) pin on one serial port to provoke a processor reset and for the bootloader to wake up. If the DTR pin is connected, an initial scan of the USB hub also wakes the bootloader. I found out the hard way that this can interfere with normal communications and in practice I switch serial cables over at the PC end between developing and testing code. (I’m assuming one can equally make up two cables, with and without DTR connections.) As mentioned before, the serial commands are terminated with a ‘#’ character, that allow one to use high-level string commands such as Serial.readStringUntil(‘#’).

Many of my Arduino functions mimic the ASCOM commands, for example: OpenRoof(), CloseRoof() and ShutterStatus(). There are some others that provide additional functionality to the unit during the time in which the roof is moving. There are also non-standard ASCOM commands to interface to the safety sensors. These are allowed within the free-form ASCOM methods but are limited for use by those applications in the know, such as my observatory control application. These pass unnoticed by the ASCOM Conformance checker but do not pass through either the Generic or POTH ASCOM hubs. OPTEC (www­.op­tec­inc­.co­n2) have developed an extensive multiple device hub, which they call an AS-COM server. This usefully passes all commands for all device types and additionally can cope with multiple devices of the same class. So, if you had two focusers, one for the guider and one for the main camera, this hub will allow both to operate at the same time.

fig.10 The basic flow of the Arduino code is a simple loop.

Testing the Arduino code is fairly straightforward with the aid of two tools; the serial monitor and the test-jig described earlier. In practice, by keeping things simple, I did not find it necessary to use the debugging capabilities or breakpoint features of Visual Studio. The test-jig also allows for simulating unusual conditions and stress-testing the Arduino control logic. I also tested the actual roof operation using a toggle-switch connection to its module. Here, I discovered the motor controller required a short pulse to operate the roof and that, being designed for a driveway gate, responded differently to a change in direction command. The Arduino logic was suitably modified.

Hints and Tips for the ASCOM driver

On the advice of some of the other ASCOM developers, I chose Visual C# rather than Visual Basic (VB) for creating the ASCOM driver. When one creates the project, as directed earlier, what appears to be a fully-populated program is generated. This is not quite the case; scrolling through you will soon notice some green comments that indicate where you need to put in your specific code to operate your particular device.

In C# terms, the ASCOM has a library of classes, each corresponding to a device type. These classes describe a device in the form of their allowable functions (methods) and variables (properties). The beauty of the ASCOM templates is they create an instance of the device’s class that you then personalize for your hardware. This means that all the allowable methods and variables are already in place and you “just” need to put in the device-specific actions. These include ready-made support methods for choosing, selecting and storing the device settings and overall, save considerable effort and at the same time, encourage a tried and tested approach. It also includes the framework for writing a log-file with one-liners at different points in your driver code. This is a useful tool for debugging programs and looking at interactions between drivers and applications.

In the case of a roll-off roof, it only requires a few methods being fleshed out. Many of the commands are not required and you will notice that the template has already made that assumption and put in the appropriate exception, declaring the function as not supported. After personalizing the code to your driver name, the principal methods issue a text string command or retrieve and interpret a text string status from the device using the serial port. In this application, the tricky part is handling these serial communications. As mentioned earlier, I chose a protocol that had the Arduino continually broadcasting a simple status message every four seconds. The device driver uses an “event handler” that detects received characters on its serial port and reads them. The device driver software looks for a start-of message character and then builds up the text string until it detects an end-of message character. It then updates a few local variables with the roof status so that it can respond without delay to a status enquiry. A handful of characters every four seconds is not a burden and although this approach is acceptable with the slow cadence of roof movements or environment changes it is wasteful of processor resources if the refresh rate is set higher than necessary and may not be a suitable approach for other, faster device types.

The ASCOM device driver templates include several standard routines that store the device settings, such as the serial com port number and whether the diagnostic trace is active. It does not store, however, the chosen device. For this, my code includes two small functions that store and retrieve the device IDs for connected devices in a small text file to remember the last connection. (Later on, I use this to store power relay names too.)

Hints and Tips for the Application

My simple Windows application uses a C# form. Playing with the form design is easy and fun but it is better to start with a clear plan in mind and do the functional programming first. Using high-tech CAD tools (paper and pencil), I sketched out some form designs and controls. For each of the controls, there is a function in the program, which generally communicates to the ASCOM devices using the method and properties in their class. It made sense that separate connect / disconnect / setup device controls were useful for setting up and testing the system as well as connect- and disconnect-all functions for normal convenience.

In my application I connect to dome, mount, observing conditions, and safety devices to get an all round view of whether to open or close the roof. Rather than rely on a single sensor, my first implementation uses any one of high humidity, heavy cloud or rainy conditions to decide to shut-up shop. It also uses the mount device’s reported park status and a park sensor to ensure the mount is truly parked. This may be a little too cautious and in doing so also requires some unique commands to the Arduino/ ASCOM driver that for some, may get in the way of basic operation. (Not everyone may need or want roof and mount sensors.) To pare back this functionally requires a sensor override. I decided on two approaches: a single forced one-off roof operation command using a unique CommandBlind call to the ASCOM driver and a more generic one, that is stored in the Arduino’s EEPROM memory, that disables the sensors for any application using the generic ASCOM commands. For this, the Arduino code includes the EEPROM library functions and simply stores two flags, for roof and mount sensors, in permanent memory. In that way, the code in the Arduino is configurable with a few unique commands from my observatory app. These are remembered when the power is off and allow the Arduino to play nicely with other programs such as Maxim DL or Sequence Generator Pro without the possibility of conflicting sensory conditions.

The main application form itself is generated by dragging various text and buttons from the Visual Studio toolbox to a blank form on the screen. Using just a mouse these can be manipulated to design the layout and align objects. In my application I also use tabbed boxes and groups, to make the layout more intuitive. These buttons are C# objects in themselves and have their own properties and methods. One is its “click” action that you point to a method you have previously prepared. Other properties can be set to change fonts or colors dynamically, to provide an instant visual warning. One less obvious object is the timer object. When added to the form and linked to a function it performs a periodic repeat method call; in this case, the update of weather and equipment parameters. This timer is set to a few seconds, slightly faster than the Arduino broadcast rate. In this way, it is more nimble to a status change. You can also have more than one timer event, for instance if there is a need for both fast- and slow-response requirements.

Debugging and Compiling

When you “build” the project or solution, it normally is in one of two modes: debug or release. The compiler build options should be set up in each case for the processor and operating system settings. Although most operating systems are 64-bit, most astronomy applications are still 32-bit. In the build tab in the code’s properties menu, I tick “prefer 32-bit” and “Any CPU” for the platform target and select .NET 4.0. In debug mode, when you run the program, the application and its driver are run dynamically so that breakpoints and crashes are managed dynamically and safely. The compiled files are stored in the debug folder. Diagnostic information is shown too, such as memory usage as well as instructive data on the cause of a crash (fig.11). If the memory usage slowly increases with time, it can be an indication of a memory leak issue in the program. This application is not particularly sophisticated but the debug features are useful during the first forays into the C# language.

I normally work on the driver and the application projects in the same solution and the compiler senses whether it needs to re-compile each project. In release mode, the ASCOM driver and observatory applications are stored by default into its release folder. The generated observatory app is a simple executable .exe file but the ASCOM driver requires installing. This is made trivial by the free application called Inno Setup. When you install the ASCOM developer components, it creates a folder called “Installer Generator” in which is placed a program that helps Inno Setup generate your own professional ASCOM driver installer. After filling out the form with the code information, run the compiler. The resulting .exe program can run from within Inno Setup and is stored in the Visual Studio project folder. This file is a standard Windows installer and is the file with which to install onto other computers. One of the installer features is that it usefully removes old driver versions before installing the new one. At the same time, the Inno Setup program generates a small file in your code folder with your driver name and with the file extension .iss. Double clicking this file loads Inno Setup with all the details of your source code, program locations and the compiler settings, facilitating a quick turnaround for another attempt.

After designing what you believe to be a working driver, run the ASCOM conformance checker on your driver code. With the test jig at the ready, hook up the Arduino and run the conformance program. After selecting the dome device and running the checker, it tests a number of features of the code. As it runs, watch what is happening on screen and flip the status switches on the test jig within the allowed response times when the open and close commands are issued (normally between 20–60 seconds for a roof) . The conformance checker will of course only check for the standard commands. Others, specific to your hardware (like my mount and rain detectors) rely upon systematic manual testing.

fig.11 Visual Studio 2015 screen. Shown here running the application in debug mode. It is simpler than it looks!