×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Running a distributed INDI-based astro-imaging setup

  • Posts: 9
  • Thank you received: 18
This sounds grander than it is, but it’s not incorrect. And INDI makes it easy, with distributed processing built into the protocol, so that once you have your devices plugged into some number of machines (e.g., Raspberry Pi's) and you establish a chain of priority--who's calling who, there's no difference in the way any app (like Ekos) interacts with the INDI-based system, whether it's a single computer or a group of computers.

My main reason for dividing instances of the INDI server across two Raspberry Pi's is to separate my iOptron CEM25P mount from the rest of the hardware (CCD, filter wheel, focuser, guide camera). I want to run the telescope-based components over wifi, with a dedicated battery pack, so there are no cables running from the mount to...anything. Everything is attached to the scope, including the rechargeable battery. And everything is controlled from my Macbook Pro over wifi. The problem to solve, which started me down the chained INDI server path, was to exclude the Go2Nova 8408 hand-controller from the mix. The iOptron mount passes all slewing and guiding commands (and everything else) through the controller over serial. I don't know if this is unique to iOptron mounts, but I don't have to do this with my Orion Atlas EQ-G; the serial cable from the computer plugs directly into the mount, without having the SynScan controller in the middle. Here’s the general idea with the CEM25P: in order to control the mount from any command software using INDI or ASCOM you connect the Go2Nova controller to the mount as usual, and then run a serial cable (RS232 -> RJ9) cable from the controller to your computer, in this case, a Raspberry Pi3B+ mounted on the telescope. This is fine if you don’t mind running cables to and from your scope, cameras, focuser, filter wheel--for power and data. This is how I’ve run things on this mount for the last year or so.

What changed? I’ve been looking at the StellarMate gadget for a while now, and Jasem’s presentation on the Astro Imaging Channel tipped me toward checking it out. He did a great overview of single-board computers in astro automation, with particular focus on Raspberry Pi's and the Atom-based Windows machines that have become popular. My goals with astrophotography have also changed over the last couple years; I've been moving more toward portability and automation, minimizing setup time, and using smaller refractors and lightweight but accurate EQ mounts. (Another general reason to go with StellarMate OS is it works great with the faster Rasp Pi 3B+. Just purchase the OS on stellarmate.com, download, flash an SD card, and you’re good to go).

Here's a diagram that shows one of my astro device setups. I spent the day getting this going, but haven't been able to get out under the stars with this yet. So far I've tested out the startup process several times, and successfully used all the connected equipment--slewing in KStars, taking a dozen exposures with the main CCD and guide camera, testing the focusing system. Everything worked well, but I think the final test will be guiding. I don't expect any problems, but that's the one connection that relies on one INDI server talking to another without any complications.



Any downsides to this setup? I don’t see any with the system distribution side of things. The only critique of chaining INDI servers I’ve read is about potential inefficiency and network latency, but I don’t see a problem here. Correct me if I’m wrong, but network speeds, even over a slow-ish wifi connection, are still going to be astronomically faster than the serial communication rates we use--9600 bits/sec to control a telescope mount, for instance. Even for guiding, where you need response times in seconds, latency shouldn't be a problem. With these inexpensive Raspberry Pi’s that can support 5.0 GHz wifi with speeds in the hundreds of millions of bits/sec, one second is still a long time.

I have only done some preliminary testing on the power side of this setup, with a boost converter (DC step-up) to maintain a fairly constant 12vdc output for the devices, and with a load the battery and converter can handle. I'm also looking at mounting a separate battery dedicated to dew control, and again it's about maintaining voltage and current.

Here’s an overview of the settings I'm using:

All three systems--primary pi, secondary pi, Macbook Pro--are running over the Stellarmate Wifi hotspot. The secondary Pi (astro-ieq) has a static IP of 10.250.250.105

Secondary Pi: astro-ieq
Connect through USB to Serial to the iOptron Go2Nova 8404 controller and CEM25P

Run this command:
indiserver -v indi_ieq_telescope

Primary Pi: stellarmate
Connect USB to: Atik CCD, ZWO guide camera, ZWO Filter Wheel, Moonlite-protocol focuser, and the remote connection you just started on the Secondary Pi: iOptron CEM25 on astro-ieq

Add a hostname to /etc/hosts that identifies the Secondary Pi
10.250.250.105 astro-ieq

Run this command:
indiserver -v indi_atik_ccd indi_moonlite_focus indi_asi_ccd indi_asi_wheel "iEQ"@astropi-telescope:7624

I don't think you need to sudo these commands, but I did in my tests. The "iEQ" designates the device ID for the iOptron CEM25 series of mounts. This parameter "iEQ"@astro-ieq:7624 tells the INDI server to connect to the "iEQ" device (iOptron mount) on astro-ieq (the secondary pi) through port 7624 (default INDI port). The tip from Jasem's tutorial on chaining multiple Raspberry Pi's together is to run indiserver -m 100 -vv indi_ieq_telescope first to get the verbose output and grab the device IDs. That's how I found the ID "iEQ", which works for several iOptron mounts, including the CEM25P and iEQ30.

Main computer
I have a Macbook Pro running Ubuntu Mate 16.04 in a Parallels VM. From here I setup a remote mode profile for the Stellarmate Primary Pi, which is running on 10.250.250.1. From the main computer's point of view--my point of view--there's nothing different about any of the operations in Ekos. That is the advantage of using the underlying INDI protocol, which supports distributed components at a deep level. After startup, you just do your imaging runs like you always do: polar alignment, create or manage your sequence queue, schedule new sequences. Everything just works!

Here are three shots of my working multi-node setup, showing the primary Pi (running StellarMate OS). The aluminum box on the top is a Raspberry Pi 3B+, with all four telescope-mounted components plugged in: Atik 414EX mono CCD, ZWO filter wheel, ZWO ASI120MM mini guide camera, and Moonlite-protocol focuser (not in view, other side of the scope. This is a new DIY focuser and controller I'm also testing out, which uses an Arduino Nano, 28BYJ-48 stepper motor, and ULN2003 motor driver board). The black box beneath the Raspberry Pi is a 6000mAh Li-ion battery with 12vdc out (www.amazon.com/dp/B00ME3ZH7C), along with a 5vdc USB power port. I run the Pi off the USB port, and the Atik camera off the 12v line, with a step up (boost) converter between to make sure we keep a steady 12v. You see that cable hanging down by the camera? That's the power line. I disconnected it before I took the pics because I'm measuring the boost converter for a 3d-printed case. For the system test I just velcro'd the PC board to the battery pack.



Close-up of the boost converter I used in my testing so far, the XL6009 DC-DC step-up power converter www.amazon.com/dp/B06XWSV89D. I put this inline between the battery and the camera's 12v connector. The problem I'm solving is the battery pack will drop voltage over time as the batteries discharge, and I'm willing to trade-off amperage in order to keep the voltage stable at 12v along that curve. Again, this is a test, so we'll see how this works out. My concern with real-world use is how much the camera draws for TEC (thermoelectric cooling) when I'm maintaining a sensor temperature at -20C? I still have to figure this out and see what I need to do for power to support this.



This next pic shows the secondary Pi, the black box velcro'd to the back of the iOptron CEM25P hand controller. The RJ-11 line from the conroller plugs into the mount, the RJ-9 (4-pin serial -> USB) cable plugs into the secondary Pi. For now I'm testing this off AC power, but for portability I will also run this side off of a battery pack.



Okay, that's where I am right now. I'll follow up with my continued testing and results!
The following user(s) said Thank You: Jasem Mutlaq, Gonzothegreat, Eric, Craig, Richard Roth, Bruce Eppler, Paul Muller
Last edit: 5 years 6 months ago by Chris Howard. Reason: minor updates to the text
5 years 6 months ago #28788

Please Log in or Create an account to join the conversation.

Great work Chris! This deserves to be featured!

Small note: you do not need to use sudo and you can drop the -m 100 from the commands above. The rest looks correct and spot on!
Furthermore, have you tried using KStars for MacOS instead of running it in Parallels? KStars 2.9.8 was just released yesterday.
The following user(s) said Thank You: Craig
5 years 6 months ago #28789

Please Log in or Create an account to join the conversation.

  • Posts: 9
  • Thank you received: 18
Thanks, Jasem!

Cool. I will remove sudo and -m.

I tried the MacOS KStars a year ago or so, but I'm used to running it under Ubuntu Mate, and I just went with that. I will check out the new Mac version!
5 years 6 months ago #28794

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
So let me get this right. You guide, dither, image, slew, plate solve and focus all from the MacBook through the distributed INDI system in the two raspberry pi’s? Wow! Got any image to show that you took using this setup?

And another question: you save the images on the first raspberry pi and then transfer them to your processing machine (I suppose your MacBook) later or download them instantaneously via wifi?
Last edit: 5 years 6 months ago by Wouter van Reeven.
5 years 6 months ago #28795

Please Log in or Create an account to join the conversation.

  • Posts: 9
  • Thank you received: 18
No images yet with this particular setup with the secondary Raspberry Pi, but I will after the next clear night! The only difference between what I described in the post and what I normally run is the additional Raspberry Pi dedicated to controlling the mount. That, and now I want to run everything off batteries located on the mount so I don't have cables going anywhere.

I have a couple different setups that I've been running for about a year. Which one I use depends on the camera, and that's mainly because large FITS files tend to slow things down. So, I do both: with smaller FITS files I setup a remote profile in the INDI control panel and do everything locally in KStars and Ekos as if my Mac is connected directly to the devices, and every command in the image sequence (change filters, shoot exposures) goes over wifi, and every image comes back and appears in the viewer as if the devices are local. The same applies to auto focusing, plate solving, guiding, etc.

For narrowband I typically use my Atik414EX, which has 6.45μ pixels at a resolution of 1394x1040, and this produces small FITS files, which transfer quickly. Nothing is stored on the Raspberry Pi in this case, but it does all the direct work with the devices. In the capture tab I have the directory set to "local", which will transfer the captured image to my Mac. You can also set it to "both" and store it on the remote and local machines.

For color imaging I have a ZWO ASI071MC, which has an APS-C sized 16MP sensor with 4.8μ pixels. The 32MB FITS files do not transfer quickly, and so I would rather they remain local to the machine connected directly to the devices. In this case I VNC into the remote machine and run everything from there.

Almost every image I've posted over the last year in my astro journal (saltwaterwitch.com/astronomy) uses one of these two methods--narrowband: remotely controlled with image data and everything else transferred over wifi, and color: VNC into the remote machine to control it directly and the image remain on the remote machine to be copied off after the night's run.

Here's a screenshot of the Profile Editor in KStars on my Mac for the above setup. Mode is set to "Remote" with the Primary Pi's IP address over port 7624. When you hit "Start INDI" all the devices connect and from my point of view it's as if they are all plugged into my local machine.

The following user(s) said Thank You: Wouter van Reeven
Last edit: 5 years 6 months ago by Chris Howard.
5 years 6 months ago #28797

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
Very interesting. Thanks for the detailed reply!
5 years 6 months ago #28800

Please Log in or Create an account to join the conversation.

  • Posts: 167
  • Thank you received: 54
Hi,

i often use such a setup, with three distant devices :

First : Odroid
  • Mount
  • ASI178 or ASI224
  • DIY Moonlite Focuser

Second : RPi
  • ASI120MM (USB2)

Third : Conventional and powerfull HTPC
  • Astrometry

The reason to use ASI120 on its own device is that it's the only way to make it work :blink:
And the use of HTPC is for performance, Astrometry is faster than light.

The "difficult" part is to launch driver, but it all works very well
I think we can now use webmanager to chain server, i saw a commit on Github that should resolve the problem we had to do that (config file)

Gilles.
Last edit: 5 years 6 months ago by gehelem.
5 years 6 months ago #28830

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
Is your RPi an RPi2 running an older kernel? The reason I ask is that ASI120MM and ASI120MC (USB2) no longer work on new Linux kernels (some 4.x version and newer) due to stricter requirements for devices to follow the USB2 protocol which the ASI120 M[MC] don’t follow. So using an older Linux with an older kernel should be a workaround for that conflict.
5 years 6 months ago #28831

Please Log in or Create an account to join the conversation.

  • Posts: 167
  • Thank you received: 54

Well, this is a Pi 3 with a fresh Stellarmate install, updated with usual tools, giving this :
stellarmate@stellarmate:~$ uname -r
4.14.50-v7+
ASI120 has been flashed with "compatible firmware"
But 16bit capture still breaks
This is good enough for guiding
5 years 6 months ago #28832

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
Ah yes flashing it can help. I tried but it didn’t work so I bought an ASI120MC-S and that works flawlessly.
5 years 6 months ago #28837

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182
You have to use the -compatible.acc file. The other one will not work.
5 years 6 months ago #28838

Please Log in or Create an account to join the conversation.

  • Posts: 1957
  • Thank you received: 420
Yes I did. Perhaps I was suffering from the same 16 bit image capture issue as Gilles, I don’t know. Anyway, that’s not an issue for me anymore :)
5 years 6 months ago #28839

Please Log in or Create an account to join the conversation.

Time to create page: 0.563 seconds