Would you consider making an Indigo version of the driver?

[exa065]

Would you consider making an Indigo version of the indi_pylibcamera driver? https://www.indigo-astronomy.org Using an INDIGO server should provide additional performance and reliability. Here is a brief summary of the advantages of INDIGO presented by the project makers:

INDIGO Astronomy (Instrument Neutral Distributed Interface for Generic Objects) is designed as a next-generation, improved alternative to the traditional INDI framework. It focuses on higher performance, easier development, and better support for modern, distributed, and commercial applications.

Here are the main advantages of INDIGO over INDI:

Higher Performance & Reliability: INDIGO uses a software bus-based, multi-tier agent architecture, which can be up to 1000x faster than INDI in scenarios where drivers and clients are in the same process. It is more efficient with memory and CPU usage, making it better for battery-operated field setups.

Advanced "Agent" Architecture: INDIGO uses "agents" (e.g., Mount Agent, Imager Agent) that run on the server side. These agents can perform complex tasks independently of the client connection; you can start a capture, disconnect your laptop, and reconnect later to download the results.

Better Built-in Tools & Web Support: INDIGO features a built-in webGUI for servers, allowing control from a browser.

Improved Hot-plug & Error Handling: INDIGO supports hot-plugging USB devices, allowing them to appear/disappear on the bus without restarting drivers. It is designed to handle port conflicts and device management better, particularly in multi-device, non-ASCOM setups.

Summary of Differences

INDI
Architecture: Traditional Client/Server
Performance: Standard
Agent Support: No (requires client to be active)
Hot-plugging: Limited

INDIGO
Architecture: Software Bus / Multi-tier Agents
Performance: High (1000x faster in some cases)
Agent Support: Yes (agents run on server)
Hot-plugging: Native Support

[scriptorron]

Hello. Probably, INDIGO has many advantages compared to INDI. But it was much easier for me to implement the driver in INDI. I feel more comfortable in Python than in C. An implementation of the INDI protocol was not a big deal in Python. And I already had a lot of experience in controlling the camera with Python. For an INDIGO driver I would need to switch to C. There would be no reuse of the driver code possible. An INDIGO driver would mean a lot of effort for me.

Besides this my telescopes are controlled by KStars + EKOS + INDI + indi_pylibcamera. I am happy that they work now and I don't want to change a running system.

[exa065]

Thank you for considering my request. Indigo-rpi-ccd (Libcamera) will not be included in the official Indigo distribution and it is abandoned. indigo-astronomy/indigo#732 (comment)

It doesn’t work with the RPI HQ Camera.
indigo-astronomy/indigo#654 (comment)

I was thinking of reusing the original code. indi_pylibcamera driver can be installed and loaded with Indigo server from the command line. Indigo should be able to fail back to the original INDI interfaces but there are glitches. More work will be needed to implement full Indigo support.

[scriptorron]

Do I understand right that Indigo can use standard INDI driver? That would be an easy option to use the indi_pylibcamera without rewriting it. Unfortunately I do not have Indigo installed and can not help to implement the full support for it. Have you tried it? Maybe you can forward me the error messages and I can try to fix it.
Or even better - help me to set up Indigo on a Pi 4 and I can do my own debugging.

[exa065]

Yes, Indigo can use a standard INDI driver. You can install Indigo side-by-side on RPI with Indi and Kstars. It is very lightweight and involves running a couple of commands. See https://www.indigo-astronomy.org/downloads.html or just run the commands below.

$ echo "deb [trusted=yes] https://indigo-astronomy.github.io/indigo_ppa/ppa indigo main" | sudo tee /etc/apt/sources.list.d/indigo.list
$ sudo apt-get update
$ sudo apt-get install indigo
$ sudo apt-get install ain-imager
$ sudo apt-get install indigo-control-panel

From a virtual environment running pylibcamera start the Indigo server:

$ source ~/venv_indi_pylibcamera/bin/activate
$ indigo_server -i indi_pylibcamera

Start the Indigo control panel. This may take a while.
In the navigation panel on the left select pylibcamera
Go to Main Control – Connection and select Connect
Go to Camera Control - Enable and select Enable
Go To Main Control – Expose and set exposure 1 sec. This will cause an error; the Indigo control panel will restart.

Close the Indigo control panel.
Restart the pylibcamera virtual environment and start again the Indigo server.
Start ain-imager. It may take a while to connect and to populate all controls.
Make sure you are on the Capture tab.
In the Camera drop-down select pylibcamera.main@indi_pylibcamera.
This will cause some errors., Ain will display the drop-down with red background. At the bottom of the window there is an error log. This is as far as I’ve managed to get with Indigo.

You can also run the Indigo server from command line and connect Ekos on the local RPI with a remote profile configured on localhost or 127.0.0.1.

[scriptorron]

Thank you. I will setup a new Pi and test. Please give me some time.

[scriptorron]

@exa065, thank you again for your detailed instructions. I followed them.

When I start an exposure in the Indigo control panel (by setting exposure time to 1 sec) I get the following error in the console which runs the driver:

indi_pylibcamera.indidevice-ERROR- could not interpret client request: <newSwitchVector device="" name="CONFIG_PROCESS">
<oneSwitch name="CONFIG_LOAD">On</oneSwitch>
</newSwitchVector>

This error is caused by the empty name device="" in the request. The driver expects to see its name here. A request with an empty device name probably means that it fits to every device. I changed that in the code.

Once the error occurred the indigo_server does not close the driver process. When restarting the driver the camera is still occupied by the old driver process and an error will come. I had the same issue with INDI and implemented something in the code which searches and kills an old driver instance. Unfortunately the code searches for processes indi_pylibcamera.py and indi_pylibcamera.sh. You started the driver with indi_pylibcamera and the detection of the old driver does not work. Same will happen when using INDI. I fixed this in the code.

The control pannel and the ain-imager still crash when the driver sends the image blob. Probably this has something to do with the command

<enableBLOB device="pylibcamera Main" name="CCD1">Also</enableBLOB>

I have not implemented it (was not needed with INDI). Just ignoring the command did not help. Next I need to find out what "Also" means and what kind of image blob data is expected by indigo.

Sorry for the many "probably" and "maybe" in the text above. All I know about the INDI protocol is from reverse engineering the communication of the INDI CCD Simulator communication.

I will tell you when I made progress.

[scriptorron]

I found the reason for the remaining crash. It had nothing to do with "enableBLOB" or the BLOB transmission. Reason for the trouble was a long log message which either made a buffer overflow in the indigo server or had a bad character. After removing the log message it is working now. I can configure the camera and make images with ain-imager.

The fixed driver is in branch support_indigo. I will implement other changes (and fix issue #107), do some tests with my setup and than I will merge everything in a new release.

Thank you for helping me to improve the driver.

[exa065]

I thank you for spending the time to make indi_pylibcamera compatible with Indigo! I am inpatient to try it but I don't have a test environment that I can mix up. I will wait for the merge and then I will play with it.

[scriptorron]

Right now I released version v3.2.0 of the driver which has the fixes. Please tell me if you see more issues in Indigo. My telescope setup is based on INDI and I do not have the chance for deep tests with Indigo.

When you think this driver is useful please make some advertising in the Indigo community. I will not get money but I would appreciate any kind of feedback.

Clear skies,
Ronald

[exa065]

Hello Ronald, I’ve managed to upgrade to driver v3.2.0. It works fine with Indigo, I took a quick shot with the Ain Imager. It is -3 degrees outside, so I will have to wait for warmer weather to take the telescope out for a real test. I will also make an announcement on the Indigo forums and I will send you a link. Next I tested the driver with an INDI server instance started in the virtual environment, and with Ekos remote profile pointing to localhost. This works fine like before. My test with the new Ekos integration capability was not successful: · I started a virtual environment for the driver, but I didn’t start from the command line the INDI server. · I started Ekos and I made a local profile. The profile editor can see and add the driver to the profile. I used the first one, pylibcamera. · I attempted to start the profile and nothing happened. Ekos just waits indefinitely. · I can disconnect and stop the profile, however a hung INDI server remains in memory until the system is restarted. What am I doing wrong? Is there a way to kill the orphaned INDI server instance without a restart? Cheers, George From: scriptorron ***@***.*** Sent: March-14-26 12:37 PM To: scriptorron/indi_pylibcamera Cc: exa065; Mention Subject: Re: [scriptorron/indi_pylibcamera] Would you consider making an Indigo version of the driver? (Discussion #106) Right now I released version v3.2.0 of the driver which has the fixes. Please tell me if you see more issues in Indigo. My telescope setup is based on INDI and I do not have the chance for deep tests with Indigo. When you think this driver is useful please make some advertising in the Indigo community. I will not get money but I would appreciate any kind of feedback. Clear skies, Ronald — Reply to this email directly, view it on GitHub <#106 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADYXT73MNLYN6WNTIA7CAU34QWDBTAVCNFSM6AAAAACWGSD4KKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMJTGE3DQMA> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/ADYXT736RCQ65WUDCWNGNC34QWDBTA5CNFSM6AAAAACWGSD4KKWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQA6YTGA.gif> Message ID: ***@***.***>

[scriptorron]

Hi George,

you did nothing wrong: the EKOS integration still does not work for a local server. It only works when you start the indiserver on command line (with all drivers you need) and setup a profile for a remote server on localhost (or wherever you started the indiserver):

The "INDI pylibcamera" drivers in the profile editor are only placeholders telling EKOS that you have cameras running on your server. Later EKOS replaces them with the camera drivers you started on command line.

Since a long time I try to make the EKOS integration running. To list the drivers in the EKOS profile editor it is needed to copy file "indi_pylibcamera.xml" from the virtual environment to folder "/usr/share/indi". This is what the "indi_pylibcamera_postinstall" script is doing after installation. This is the current state you have after installation. It works for the command line start of the indi server but not when EKOS starts the server:

EKOS does not find the driver executable in the search path. For experiments I made symbolic links in "/usr/bin" to the executables in the virtual environment:

ln -fs /home/cam/venv_indi_pylibcamera/bin/indi_pylibcamera /usr/bin

(do the same for indi_pylibcamera2, indi_pylibcamera3, ... indi_pylibcamera5)

Now EKOS can be configured for a local server and it will start the indi_pylibcamera driver:

INDI Server:  "2026-03-15T09:42:28: FIFO: start indi_pylibcamera -n \"INDI pylibcamera\""

EKOS adds the command line option -n "INDI pylibcamera" to the driver call which sets the driver name to "INDI pylibcamera". But I want the driver name set from the INI file! The INI file has the advantage that everyone can give a useful and descriptive name (like "main camera", "guider camera", ...). The string "INDI pylibcamera" comes from the XML file in "/usr/share/indi" and it would be confusing for many users to edit this file. I have no idea how to force EKOS to use a custom name for the driver.

EKOS starts the local server with the indi_pylibcamera driver and expects to get a camera driver with the name "INDI pylibcamera". When the driver takes a different name from the INI file it will not be found by EKOS. :-(

For experiments I set the driver name in the INI file to "INDI pylibcamera" and EKOS found the driver, asked me for the optical train and showed the camera tab. But when I tried to make an exposure I got the error message [] No camera detected. Check train configuration and connection settings.. I do not know what is still missing. The camera driver is running, EKOS lists it in the control panel and the optical train is configured to use it as camera. This is the same situation as when you start indiserver from command line but it still does not work. Frustrating! I gave up.

I have no problem with starting the server on command line. In fact I made a script which starts all the software I need for an observation night. My PI 5 has 2 HQ cameras connected ("Main" and "Guide"), it controls the mount with indi_lx200autostar, runs KStars as user interface and PHD2 for guiding. For setting up an observation session I connect with XRDP to the PI. When the exposure series are running I can disconnect the laptop and the PI does its job alone. Very comfortable for me.

A full EKOS integration would be nice and help other people to use this driver. Maybe once I will find the trick to make it working.

[exa065]

Hi Roland, Maybe Ekos is doing something else with the driver name. For example for naming the original LibCamera driver instance it makes a concatenation between the driver name and the camera interface. For example: LibCamera imx477-0 Most likely this is an Ekos/INDI bug. Why don’t you post an issue on their bug-tracking site? It looks like a simple thing that they should be willing to fix. On my side I am happy to have a driver that really works well. It is fine for me to use an Ekos remote profile on localhost. It will be of course easier to use a local profile. It is a bit more convenient to use indi_pylibcamera with Indigo. I don’t need the drivers for my other equipment listed on the command line that starts the Indigo server. They are loaded from my pre-saved configurations. From: scriptorron ***@***.*** Sent: March-15-26 6:53 AM To: scriptorron/indi_pylibcamera Cc: exa065; Mention Subject: Re: [scriptorron/indi_pylibcamera] Would you consider making an Indigo version of the driver? (Discussion #106) Hi George, you did nothing wrong: the EKOS integration still does not work for a local server. It only works when you start the indiserver on command line (with all drivers you need) and setup a profile for a remote server on localhost (or wherever you started the indiserver): image.png (view on web) <https://github.com/user-attachments/assets/fac74ab8-8751-498f-b66a-27b1f717d4c5> The "INDI pylibcamera" drivers in the profile editor are only placeholders telling EKOS that you have cameras running on your server. Later EKOS replaces them with the camera drivers you started on command line. Since a long time I try to make the EKOS integration running. To list the drivers in the EKOS profile editor it is needed to copy file "indi_pylibcamera.xml" from the virtual environment to folder "/usr/share/indi". This is what the "indi_pylibcamera_postinstall" script is doing after installation. This is the current state you have after installation. It works for the command line start of the indi server but not when EKOS starts the server: EKOS does not find the driver executable in the search path. For experiments I made symbolic links in "/usr/bin" to the executables in the virtual environment: ln -fs /home/cam/venv_indi_pylibcamera/bin/indi_pylibcamera /usr/bin (do the same for indi_pylibcamera2, indi_pylibcamera3, ... indi_pylibcamera5) Now EKOS can be configured for a local server and it will start the indi_pylibcamera driver: INDI Server: "2026-03-15T09:42:28: FIFO: start indi_pylibcamera -n \"INDI pylibcamera\"" EKOS adds the command line option -n "INDI pylibcamera" to the driver call which sets the driver name to "INDI pylibcamera". But I want the driver name set from the INI file! The INI file has the advantage that everyone can give a useful and descriptive name (like "main camera", "guider camera", ...). The string "INDI pylibcamera" comes from the XML file in "/usr/share/indi" and it would be confusing for many users to edit this file. I have no idea how to force EKOS to use a custom name for the driver. EKOS starts the local server with the indi_pylibcamera driver and expects to get a camera driver with the name "INDI pylibcamera". When the driver takes a different name from the INI file it will not be found by EKOS. :-( For experiments I set the driver name in the INI file to "INDI pylibcamera" and EKOS found the driver, asked me for the optical train and showed the camera tab. But when I tried to make an exposure I got the error message [] No camera detected. Check train configuration and connection settings.. I do not know what is still missing. The camera driver is running, EKOS lists it in the control panel and the optical train is configured to use it as camera. This is the same situation as when you start indiserver from command line but it still does not work. Frustrating! I gave up. I have no problem with starting the server on command line. In fact I made a script which starts all the software I need for an observation night. My PI 5 has 2 HQ cameras connected ("Main" and "Guide"), it controls the mount with indi_lx200autostar, runs KStars as user interface and PHD2 for guiding. For setting up an observation session I connect with XRDP to the PI. When the exposure series are running I can disconnect the laptop and the PI does its job alone. Very comfortable for me. A full EKOS integration would be nice and help other people to use this driver. Maybe once I will find the trick to make it working. — Reply to this email directly, view it on GitHub <#106 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADYXT723PYCSHRBQMPNZPDL4Q2DSBAVCNFSM6AAAAACWGSD4KKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMJUGA2DKMY> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/ADYXT733JKBVKESGXNEGO3D4Q2DSBA5CNFSM6AAAAACWGSD4KKWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQA6ZEKK.gif> Message ID: ***@***.***>