×

Warning

JLIB_APPLICATION_ERROR_COMPONENT_NOT_LOADING

The following is a video tutorial on how to get started with INDI & Ekos under Windows 10. To use INDI under Windows, download Ekos VM and use Ekos to manage your devices. When using Raspberry PI to connect to your devices, simply set the Raspberry PIs IP address in Ekos and you can connect to it and control it transparently.

INDI Web Manager is a simple Web Application to manage INDI server. It supports multiple driver profiles along with optional custom remote drivers. It can be used to start INDI server locally, and also to connect or chain to remote INDI servers. It is especially useful to install on remote Raspberry PIs installations where you can easily startup INDI server without needing to SSH into the device. Furthermore, the Web Manager provides a RESTful API where you can issue simple calls to start and stop INDI services over the network.

For more information on the API, check the project's GitHub page.

 

  • Requirements

INDI Library must be installed on the target system. The Web Application is based on Bottle Py micro-framework. It has a built-in webserver and by default listens on port 8080. Open a terminal and install the pre-requisites:

sudo apt-get install python-dev python-pip
sudo pip install psutil

 

  • Download

Download the INDI Web Manager zip file. Extract the zip file:

unzip indiwebmanager-master.zip
cd indiwebmanager-master

Copy the servermanager folder to your $(HOME) (e.g. on Raspberry PI it is /home/pi) or any folder where the user has read and write access. The following command copies the servermanager directory to your home directory.

cp -rf servermanager ~/

You can perform all these operations in any file manager (e.g. Dolphin) as well. You can use the console commands where you do not have a graphical access on the target system.

  • Usage

The INDI Web Manager can run as a standalone server. It can be started manually by invoking python:

cd servermanager
python drivermanager.py

Then using your favorite web browser, go to http://localhost:8624 if the INDI Web Manager is running locally. If the INDI Web Manager is installed on a remote system, simply replace localhost with the host name or IP address of the remote system.

  • Auto Start

To enable the INDI Web Manager to automatically start after a system reboot, a systemd service file is provided for your convenience:

[Unit]
Description=INDI Web Manager
After=multi-user.target

[Service]
Type=idle
User=pi
ExecStart=/usr/bin/python /home/pi/servermanager/drivermanager.py
ExecStart=/usr/bin/python /home/pi/servermanager/autostart.py

[Install]
WantedBy=multi-user.target

The above service files assumes you copied the servermanager directory to /home/pi, so change it to where ever you installed the directory on your target system. The user is also specified as pi and must be changed to your username.

Copy the indiwebmanager.service file to /lib/systemd/system:

sudo cp indiwebmanager.service /lib/systemd/system/
sudo chmod 644 /lib/systemd/system/indiwebmanager.service

Now configure systemd to load the service file during boot

sudo systemctl daemon-reload
sudo systemctl enable indiwebmanager.service

Finally, reboot the system for your changes to take effect:

sudo reboot

After startup, check the status of the INDI Web Manager service:

sudo systemctl status indiwebmanager.service

If all appears OK, you can start using the Web Application using any browser.

  • Profiles

The Web Application provides a default profile to run simulator drivers. To use a new profile, add the profile name and then click the plus icon. Next, select which drivers to run under this particular profile. After selecting the drivers, click the Save icon to save all your changes. If you check Auto Start, then the profile drivers will be started on system boot up.

INDI is by design a distributed control protocol where multiple INDI servers may span different hosts and on different network topologies. This enables an N to N communication between front end clients and backend servers. When operating a local or remote observatory, it might be necessary to run INDI servers on multiple devices. If you are using Ekos as your client of choice, then it is necessary that all remote INDI servers are chained, that is, they should all be linked together as to appear at one INDI server to Ekos.

Thankfully, INDI servers support chaining among themselves. In this tutorial, we shall explore a hypothetical scenario where you have two Raspberry PIs over the local network (WiFi or LAN) and each Pi is connected to several devices.

First and foremost, you have to decide which device should act as the primary INDI server host. If you have two identical devices, then it shouldn't matter which is which, any device can be the primary. As a general rule of the thumb, the more powerful device with faster and reliable connection should act as the primary device. In our example, Raspberry Pi #1 is the primary device. For each device, it is recommended to use an alias for the IP address. Raspberry Pi #1 alias is starpi and has an IP address of 192.168.1.50. On the other hand, Raspberry Pi #2 alias is astropi with an IP address of 192.168.1.51

We have the following devices connected to each Pi:

  1. starpi (192.168.1.50):
    • Joystick
    • EQMod Mount
    • Canon DSLR
  2. astropi (192.168.1.51):
    • Robo Focus
    • ZWO CCD

In order to refer to the devices by their alias, we need to add them to the /etc/hosts file on the PC/Device running Ekos, and also on the Raspberry PIs. So on each device, you can run the following commands:

sudo echo "192.168.1.50   starpi"  >> /etc/hosts
sudo echo "192.168.1.51   astropi" >> /etc/hosts

Now when you run ping starpi, you should see it is pinging 192.168.1.50

Since astropi is the secondary device, we start the INDI server there first because we will connect to it later from the primary device:
indiserver -m 100 -vv indi_robo_focus indi_asi_ccd

It is important to note that in order to chain this INDI server to the primary server that we shall create later on, we need to know the device names. For most devices, the device name is static and does not change. While other devices get their name at run-time according to the actual model detected. For Robo Focus, the device name is always static RoboFocus, but for ZWO CCD, the actual device name depends on the model of the camera you have. The device name is also the same name you get in the INDI control panel. If you start indiserver with with -vv option above, it will display more verbose information including the device names. You only need to use the -vv argument if you don't know the exact device name.

2016-02-23T13:07:42: startup: indiserver -m 100 -vv indi_robo_focus indi_asi_ccd 
2016-02-23T13:07:42: Driver indi_robo_focus: pid=10202 rfd=3 wfd=6 efd=7
2016-02-23T13:07:42: Driver indi_asi_ccd: pid=10203 rfd=4 wfd=9 efd=10
2016-02-23T13:07:42: listening to port 7624 on fd 5
2016-02-23T13:07:42: Driver indi_asi_ccd: sending 
2016-02-23T13:07:42: Driver indi_robo_focus: sending 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_robo_focus: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: snooping on Telescope Simulator.EQUATORIAL_EOD_COORD
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: snooping on Telescope Simulator.TELESCOPE_INFO
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: snooping on CCD Simulator.FILTER_SLOT
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: snooping on CCD Simulator.FILTER_NAME
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: read 
2016-02-23T13:07:42: Driver indi_asi_ccd: read 

Here we can see that the actual device name is ZWO CCD ASI120MC. Now, we login to starpi and start INDI server:

indiserver -m 100 -v indi_joystick indi_eqmod_telescope indi_gphoto_ccd "RoboFocus"@astropi "ZWO CCD ASI120MC"@astropi

This will start INDI server on starpi and chain it to the INDI server running over at astropi.

In Ekos Setup, select Remote mode and then select all your devices as illustrated below.

Next, open Ekos options and change the host to starpi and port to 7624. Now you're good to go! Simple click Start INDI and it will connect to to the remove devices. You should see all the devices popping up in INDI control panel.

Next simply click Connect in Ekos Setup and all your device should come online so you can start using Ekos right away!

You can accomplish remote startup and chaining of the INDI devices in a simple Python script. You run the the script on the same machine running Ekos, and it can SSH into the remote devices and start the corresponding INDI servers. For the script to work, you must be able to login to the Raspberry PIs using PKI authentication (SSH Keys) and not password.

Numerous astronomical devices still communicate with the venerable RS232 standard despite the wide adoption of Universal Serial Bus (USB) protocol. Since modern PCs/SBCs no longer support connecting to RS232 via the traditional DB9/DB25 connectors, USB serial adapters are often used to pass the RS232 data to the host via a USB stream.

On Linux, USB serial devices are created incrementally on the /dev file system and often appear as /dev/ttyUSB0, /dev/ttyUSB1, ...etc.

This device port is needed in many INDI drivers in order to communicate with the device, but the problem is that the device designations are not persistent. If you reboot the device or unplug/replug the USB device, you are very likely to end up with a different device designation under /dev. When you attempt to connect to the device again, you'd be surprised as why INDI is having trouble connecting to it, only to realize that the port mapping changes. This situation is indeed quite frustrating and completely unacceptable especially when operating remote automated observatories. Wouldn't be nice if we can have /dev/mount and /dev/focuser all the time?!

Linux offers a method to make persistent port mappings across reboots and disconnections! It's called udev and it is a device manager for the Linux kernel. When you connect your serial device, udev creates a device node in /dev. To overwrite its behavior, we need to write a udev rules file to have persistent names for our devices.

All USB devices have a Vendor ID and a Product ID. Running lsusb in Ikarus Observatory's Odroid, I get the following:

Bus 006 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. 
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. 
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 054: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 003 Device 053: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 003 Device 075: ID 1278:0507 Starlight Xpress Lodestar autoguider
Bus 003 Device 052: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 003 Device 057: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 003 Device 060: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 003 Device 056: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 003 Device 059: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 003 Device 055: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 003 Device 051: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 050: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 049: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Most serial devices seem to use the FTDI FT232 as seen above which has a Vendor ID (VID) of 0x0403 and Product ID (PID) of 0x6001, so we can't distinguish among the devices alone by the VIDs and PIDs. How can we tell which is which? Fortunately, to uniquely differentiate USB devices, we can use Serial identifier. Of course, if you have multiple Serial-To-USB adapters that have different VID:PID combinations, then there is no need for a Serial identifier, it is only needed if you have multiple adapters from the same manufacturer which is often the case.

To find out the serial ID, run the following command against the device node. For example, the find the serial id of the device connected to /dev/ttyUSB0:

udevadm info -a -n /dev/ttyUSB0 | grep '{serial}' | head -n1

In my case, I got the following:

ATTRS{serial}=="A8YNLO6X"

To get all the serial numbers, it is recommended to connect each device by itself i.e. no other device are connected, and then run the above command to obtain the serial number, along with the VID:PID. In Ikarus Observatory, the following devices are connected via USB Serial connectors:

  • EQMod Mount
  • MoonLite Focuser
  • Flip-Flat
  • Vantage Vue Weather Console

Vantage Vue INDI driver already installs a udev rules file that creates a symlink at /dev/vantage. For the rest of the devices, I created a file in /lib/udev/rules.s/99-observatory.rules:

# MoonLite Focuser                                                                                                                                                                                                                          
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A501T0P9", MODE="0666", SYMLINK+="focuser"                                                                                                            
                                                                                                                                                                                                                                            
# Flip Flat                                                                                                                                                                                                                                 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A8YNLO6X", MODE="0666", SYMLINK+="remotecap"                                                                                                          
                                                                                                                                                                                                                                            
# EQMod Mount                                                                                                                                                                                                                               
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FTG8H6RX", MODE="0666", SYMLINK+="mount"

Therefore, when the mount is plugged, the device symlink /dev/mount is created and remains consistent across reboots. After saving the rules file, it is recommended to reboot the device/PC so that the udev rules take effect.

Ekos powerful Capture Module recently added support to automated capture of flat field frames. Using the capture sequence queue, it was always possible to capture flat images with manually-specified exposure times, and now completely automated flats are supported!

Once you select a flat frame from the Type drop-down list, click the Calibration Options button to open the flat calibration options dialog. In the dialog, you can set the flat field frame Source and Duration as following:

  • Manual: The flat field light source is set and turn on/off manually by the user.
  • Dust Cap: Use a dust cap device (e.g. FlipFlat) as the flat field light source. Ekos will park (close) the dust cap if it was not already parked when capturing the flat frames.
  • Wall: Before capturing flats, slew the telescope to a specific Azimuth/Altitude position on the wall where an evenly-illuminated panel is installed. If the light panel is controllable and is connected as an INDI device, Ekos will turn on/off the panel light as needed.
  • Dawn/Dusk: Future options reserved for dawn/dusk flats but might not be implemented due to the unreliability and limited time of dawn/dusk flats.

After selecting the flat source, you need to specify the flat desired duration:

  • Manual: No changes shall be made to the flat exposure duration. The user specified duration in the capture module shall be used.
  • ADU Percentage: Analog to Digital Units (ADU) are the dynamic range of pixels values in your CCD. For a 16bit CCD, the maximum possible ADU is 65535. The actual maximum ADU depends on your CCD. ADU count is proportional to the electrons excited by incident photons and CCD gain. Set the desired ADU % and Ekos shall adjust capture time until target ADU % is reached. When using this setting, it is recommended to set the exposure time to 1 second and Ekos will adjust it accordingly.

Optionally, you can select to park the mount and/or the dome if required before the flat frames are captured. Please note that this will suspend any ongoing guiding process. Furthermore, once parked you cannot capture any light frames, so capture the flat frames either at the beginning of the session or at the end.

Tip: Using a controllable flat field light source (e.g. Flat-Man) can save a lot of time since light intensity can be adjusted per filter thereby reducing exposure times for narrowband filters considerably.

Hubble-like super wide field images of galaxies and nebulae are truly awe inspiring, and while it takes great skills to obtain such images and process them; many notable names in the field of astrophotography employ gear that is not vastly different from yours or mine. I emphasize vastly because some do indeed have impressive equipment and dedicated observatories worth tens of the thousands of dollars. Nevertheless, many amateurs can obtain stellar wide-field images by combining smaller images into a single grand mosaic.

We are often limited by our camera+telescope Field of View (FOV). By increasing FOV by means of a focal reducer or a shorter tube, we gain a larger sky coverage at the expense of spatial resolution. At the same time, many attractive wide-field targets span multiple FOVs across the sky. Without any changes to your astrophotography gear, it is possible to create a super mosaic image stitched together from several smaller images. There are two major steps to accomplish a super mosaic image:

  1. Capture multiple images spanning the target with some overlap between images. The overlap is necessary to enable the processing software from aligning and joining the sub-images.
  2. Process the images and stitch them into a super mosaic image.

The 2nd step is handled by image processing applications such as PixInsight, among others, and will not be the topic of discussion here. The first step can be accomplished in Ekos Scheduler where it creates a mosaic suitable for your equipment and in accordance to the desired field of view. Not only Ekos creates the mosaic panels for your target, but it also constructs the corresponding observatory jobs required to capture all the images. This greatly facilitates the logistics of capturing many images with different filters and calibration frames across a wide area of the sky.

Before starting the Mosaic Job Creator in Ekos Scheduler, you need to select a target and a sequence file. The Sequence File contains all the information necessary to capture an image including exposure time, filters, temperature setting...etc. Start the Mosaic Job Creator by clicking on the icon next to the Find button in Ekos Module.

On first use, you need to enter your equipment settings including your telescope focal length in addition to camera's width, height, and pixel dimensions. Finally, you need to enter the rotation of the camera with respect to north, or the position angle. If you don't know this value, start Ekos and slew to to your desired target then use the Align module to solve the image and obtain the position angle.

Next, enter the desired number of horizontal and vertical panels (e.g. 2x2, 3x3...etc) and then click Update. The target FOV shall be calculated given the number of panels and your camera's FOV and the mosaic overlap shall be displayed. By default, the percentage of the overlap among images is 5%, but you can change this value to your desired value. You can also move the complete mosaic structure around to fine tune the position of the mosaic panels. When satisfied, click Create Jobs and Ekos shall create an observation job and a corresponding customized sequence file for each panel. All the jobs shall be saved to an Ekos Scheduler List (.esl) file that you can load on any suitable observing night and it will pick off where you left. Before starting the Mosaic Job Creator, check that all the observation job conditions, constraints, and startup/shutdown procedures are as per your requirements since these settings shall be copied to all the jobs generated by the Mosaic tool.

With Ekos Scheduler, multi-night imaging is greatly facilitated and creating super mosaics has never been so easy. Get started with Ekos now and don't forget to post your results to INDI forums!

When operating a remote observatory, complete control of the devices rest with the remote INDI servers and drivers. In case of a communication loss, the observatory should be capable of performing a graceful shutdown until communication is established again by the client.

Since the actual shutdown procedure can be unique to each observatory, the user should be able to configure the exact required shutdown procedure. But for most users, the usual shutdown procedure involves parking the mount followed by parking the dome, if one exists. Using INDI WatchDog driver, the user can secure their remote observatory by setting a heart beat timeout threshold. A heart beat is a signal from the client to the watchdog driver to inform it that communication is OK. The user can configure the heart beat timeout in minutes in the WatchDog driver. If the driver does not receive the signal after the heart beat timeout threshold, it initiates the shutdown procedure. To disable the heart beat check, set it to zero.

The shutdown procedure is currently composed of the following steps in order:

  1. Park Mount: The mount driver specified under Options tab will be commanded to park. After parking is successful, the driver proceeds to the next step, otherwise it aborts the shutdown procedure.
  2. Park Dome: The dome driver specified under Options tab will be commanded to park.
  3. Execute Script: Execute a custom shutdown script as specified in the settings property. The script must be executable and exits successfully for this operation to be considered successful.
To park the mount and dome, the driver needs to act as a client as well in order to issue such commands. You need to specify the indiserver host and port where the dome and mount drivers are running. This is usually localhost at port 7624 which is the default value. The shutdown script can be used to perform any additional shutdown functions (e.g. turn off power, send email...etc). You can use Python INDI Client library to command devices, or INDI's built in scripting tools. All values can be saved in the config file by going to Options and clicking Save under the Configuration property. On subsequent runs, all values shall be loaded automatically on start up.

 Tip: When starting INDI server on a remote PC/Raspberry PI via SSH, make sure to run indiserver in the background so that if you get disconnected, the indiserver is not terminated. This is accomplished easily by adding & after the command. For example: indiserver -v indi_watchdog indi_eqmod_telescope indi_qhy_ccd &

 Getting Started

As more Single-Board-Computers such as the Raspberry PI, ODroid, Beaglebone..etc become more powerful with every release, they become closer to replacing the traditional desktop PC for trivial non-graphic intensive tasks. One of the nuisances of astrophotography is the necessity to be in close proximity to your equipment during the typical astrophotography workflow. Your telescope, CCD, focuser..etc are usually connected to a desktop or laptop running your favorite astrophotography software. In addition to freezing temperatures you might encountered in your neck of the wood in winter, it is often far more convenient to operate everything remotely from the comfort of your living room, and it's even better if it's done wirelessly.

Nowadays, the hardware and software technology stacks make this possible thanks to INDI/Ekos and cheap Single board Computers. INDI is the software that talks to your devices and controls them. INDI is a server and does not require a Graphical-User-Interface (GUI) nor a powerful PC, and hence INDI can run on devices such as the Raspberry PI. Ekos is the graphical client used to control the devices exposed by INDI. It offers powerful capabilities to capture, focus, guide, and plate-solve your images. Ekos requires a modern Linux distribution with KDE. Any desktop or laptop that can run Ubuntu/Kubuntu can run Ekos without any issues.

DBUS is a very powerful and versatile inter-process communication system used in Linux and other OSes. DBUS replaced DCOP in KDE4 and has since became the standard for IPC messages in KDE. With KStars (>v.2.3.0), it exposes a new INDI DBUS interface in addition to the existing KStars's DBUS interface giving you a fine control over most of KStars functionality.

In this tutorial, we will learn how to perform basic control of a telescope and CCD using DBUS and Python. We will utilize an external FITS viewer fv, you can install it in Ubuntu:

Introduction

There’s always point where you have to decide in any expensive undertaking, such as amateur astronomy, where it’s best to apply your hard earned currency. For any given piece of equipment, you have to determine what feature set is required, decide what commercial products, if any, suit your needs and finally, what your best purchase option may be. For me, there’s always been a desire to see if I can build a more cost effective solution first, before I proceed to purchase.

With that in mind, it’s been my goal for some time, to complete my automated and remote solution for my personal astronomical observatory. Not having found a cost effective remote focusing solution on the market, I decided to see about low cost DIY alternatives. During my search and evaluation I turned to the INDI platform for ideas.

The Raspberry PI (RPi) is an ARM-based credit-card-sized single board computer. It costs around $35 (PI 2) and therefore it is a very attractive choice for amateur astronomers to control their equipment either locally or remotely. It can be used over Ethernet or WiFi to control your equipment remotely. 

Due to power limitations of the RPi, it is recommended to connect all devices to a powered USB hub. INDI Library v1.2.0 packages in addition to 3rd party drivers are available for the RPi (Raspbian Jessie, Wheezy packages are no longer offered). Furthermore, if you install Ubuntu Mate for Raspberry PI 2, you can get all the bleeding edge INDI and KStars directly from the Ubuntu INDI PPA, no need to download and install packages manually!

You typically would run an INDI server on the RPi and connect to it remotely from Ekos. While it is technically possible to build Ekos in RPi, it would not run smoothly; therefore it is recommended to run INDI server on the RPi and Ekos on a more powerful machine.

Login

3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!