INDIClient 1.0.15: New INDIMount Tool

Juan Conejero

PixInsight Staff
Staff member
Hi all,

Today we have released a new version of the INDIClient PixInsight module: 1.0.15, now available as a regular update for PixInsight 1.8.4 on FreeBSD, Linux, OS X and Windows.

This version comes with an exciting new tool: INDIMount. This tool allows you to control your telescope with features such as online catalog search, GoTo, Slew, Sync and Park functions, high-accuracy mean/apparent coordinate transformations, differential position corrections, fully scriptable process, and more. The new version also includes bug fixes and stability and performance improvements in the rest of INDIClient tools: INDIDeviceController and INDICCDFrame.

INDIMount.png

INDIMount is really straightforward to use, as you can see in the above screenshot. However, there is much more under the surface that what you might expect from the simplicity of its user interface. One of our main goals with the development of these tools is to achieve the highest possible pointing accuracy. While our efforts can be clearly excessive to control small telescopes, they can be quite important for large telescopes and modern high-quality mounts, and are essential for the next generation of tools that we have planned within the INDIClient project. This includes generation and integration of astrometry-based pointing models, among other tasks.

When you search and select an astronomical object with the Online Coordinate Search dialog (see above), INDIMount computes the apparent position including corrections for proper motions (when available), stellar aberration, precession, nutation, and frame bias. The resulting apparent geocentric coordinates populate the coordinate fields on the GoTo section, and are sent to the selected INDI mount device for GoTo and Sync operations. Apparent coordinates are computed using accurate, rigorous algorithms. Our implementation is based on the IAU SOFA software library. In the current implementation we are not computing the corrections for parallax and radial velocity (which are very small in most cases; the largest parallax is smaller than 0.75 arcsec), and we are neglecting the effect of light bending. In the next version we'll include calculation of topocentric coordinates (which can be relevant for observation of near-Earth objects and the Moon), the effect of atmospheric refraction (very important, but neglected in this initial version for simplicity), and calculation of solar system ephemerides (using an integration of JPL development ephemerides with the PixInsight/PCL platform).

INDICCDFrame.png

INDIMount and INDICCDFrame work cooperatively. When you acquire new client-side images and a telescope device is available (see INDICCDFrame's telescope device parameter), it is used to retrieve its current EOD (epoch of date) coordinates just before each exposure. These apparent coordinates are converted to ICRS J2000.0 mean positions by an inverse transformation. Once these coordinates are computed for each acquired image, they are stored as standard XISF properties (Observation:Center:RA and Observation:Center:Dec). For compatibility with legacy applications, as well as with tools and scripts still performing the transition from FITS keywords to XISF properties, the same coordinates replace the OBJCTRA and OBJCTDEC keywords provided by the INDI server.

The main advantages of this process are: (1) we always store mean J2000.0 positions in newly acquired images, which are directly comparable between different images and stellar catalogs, irrespective of the times of observation, and (2) we compute apparent and mean positions using very accurate and rigorous algorithms (IAU 2006 precession/nutation model and a rigorous stellar aberration model). As noted above, this is necessary for the implementation of future tools, including generation of pointing models.

INDIMount also has a very nice feature: differential pointing correction. To use this feature, follow this sequence of operations:

- Point your telescope to a desired location with INDI Mount Controller.

- Acquire an image with INDI CCD Controller.

- Solve the image astrometrically with the ImageSolver script.

- Launch a new instance of INDIMount (you know: INDI Mount Controller, click blue triangle, drag) to the image.

With this sequence, INDIMount will compute the difference between the observation coordinates (where the telescope thinks it's pointing to) and the actual pointing coordinates, then this difference will be applied to move the telescope from its current location. This feature is very useful to perform quick pointing corrections and/or to synchronize your mount at a known location.

Our next goals with the INDIClient project are:

- Improve the INDIMount and INDICCDFrame processes.

- Pointing model generation and integration.

- Autoguiding.

- Autofocus.

So stay tuned! As always, a huge thanks to Klaus Kretzschmar for his work on this project, to Vicent Peris for great development ideas, to the INDI developers for making all of this possible, and to all the users and friends that enthusiastically support us.
 
Do these developments on INDI signal a departure from further developing PI processing tools? 

To be honest, I'm struggling with this INDI stuff. I have seen it about but never looked into it. I had to Google it and worked out its some form of Linux. I'm not a computer nubie, I have been using and developing computer/microcontroller systems since the days of CP/M. I am more a user than developer these days though, with only small forays into developing ASCOM drivers and utilities to automate my observatory.

Mine is not a professional observatory but it just works, is reliable and I cannot think of any major issues.  I am struggling with the concept of re-inventing the wheel and overcoming all the device interface issues once more .... and for what... to do what I already do today?

It may be exciting and all that - but what is the point?

The target market may be professional users - or those who just like the fun of creating stuff or just refuse to use Win/OSX.

 
Do these developments on INDI signal a departure from further developing PI processing tools?

Not at all. Why do you think so?

It may be exciting and all that - but what is the point?

As exciting as you want it to be. For example, what is the point of the whole PixInsight project? Isn't it a reinvention of the wheel, given that there are so many image processing applications out there? The answer to these questions is simple: we try to do it different, and better.

I'd like to understand exactly why each time we start a new project a lot of people gets invariably scared or annoyed. Please relax. There's no problem here. Hardware control is just another development project in PixInsight.
 
Hi Juan,

- For GEM, need to set mount flip point to arbitrary (non-meridian) local hour angle. To allow tracking and/or slews into "upside down" position. Required for long-exposure narrow band exposure sequences. Initial exposure may be upside down and later exposures become rightside up, or alternatively initial exposures are rightside up and upside down state occurs towards end of exposure sequence. My current software in use extended to support this.

- For GEM with declination gear backlash, "all" slews need to "approach" target from a specified declination direction (north or south). Current situation: mount polar misaligned slightly so that declination drift is always in one direction, so declination backlash never needs to be unwound during exposure tracking. Initial slew prior to first exposure in sequence needs to result in a backlash unwound state. So slew approach direction is set appropriately based on polar misalignment direction. My current software in use extended to support this.

- Both of these are absolute requirements for me to obtain good tracking and efficient dark time utilization with my Takahashi EM-400 mount.

Thanks,
Mike
 
Juan Conejero said:
As exciting as you want it to be. For example, what is the point of the whole PixInsight project? Isn't it a reinvention of the wheel, given that there are so many image processing applications out there? The answer to these questions is simple: we try to do it different, and better.

Considering the high quality of your soft and comparing with the development quality of many astro software out there, I have no doubt you'll do better !
For my part, i'll certainly wait for the autoguiding part to be done but I can't wait for it !
Continue to do so neat job ! It's highly appreciated :)

N.B: Lot of my friends says PixInsight is expensive. I always tell them the price is truly cheap regarding the quality and the professionalism of the work you guys do.
 
I get a kick out of the "PixInsight is expensive" argument that people use. I have one of the simplest setups you can have. A mirrorless camera, memory card, intervalometer, cheap scopes and lenses, a CG-5 and a DIY pier.  I don't guide, I don't use a computer for acquisition at the mount and PixInsight is still less then one tenth my astro equipment budget.


Mike 
 
Just curious and may be jumping ahead here, but is Pixinsight planning to come up with its own autoguiding solution or interface with existing projects like PHD2 similar to how other acquisition packages do?
 
mar504 said:
Just curious and may be jumping ahead here, but is Pixinsight planning to come up with its own autoguiding solution or interface with existing projects like PHD2 similar to how other acquisition packages do?

Hi,

We will do everything on our own. The graphical interface in PixInsight (specially the multiple workspaces) is powerful enough. Forget the idea of having multiple applications running at the same time.


Best regards,
Vicent.
 
Juan Conejero said:
As exciting as you want it to be. For example, what is the point of the whole PixInsight project? Isn't it a reinvention of the wheel, given that there are so many image processing applications out there? The answer to these questions is simple: we try to do it different, and better.

I'd like to understand exactly why each time we start a new project a lot of people gets invariably scared or annoyed. Please relax. There's no problem here. Hardware control is just another development project in PixInsight.

PixInsight does not reinvent the wheel on processing. It is a complete departure in functionality and originality. It is different and better - but takes some time to master.

There is no harm in starting new projects - I have several patents to my name. I'm not scared or annoyed but I'm interested in what the gain is.
Once a user can control their mount, guide and acquire images reliably- what is left to improve upon? As a hobby I recognize that some of the fun stuff is overcoming challenges but really... why would I deliberately set the clock back and go through debugging all over again? I use a NUC with SGP, TSX and PHD2. It just works. I'm sorry, I don't see the satisfaction of trying to squeeze it onto a Raspberry Pi or whatever.

Reading the other post, it seems that ASCOM is still required? Well, if you wanted to break new ground, I would start there. As a concept it is fine but its architecture is showing its age - for example to cope with multiple devices in an imaging array.
 
mschuster said:
Hi Juan,

- For GEM, need to set mount flip point to arbitrary (non-meridian) local hour angle. To allow tracking and/or slews into "upside down" position. Required for long-exposure narrow band exposure sequences. Initial exposure may be upside down and later exposures become rightside up, or alternatively initial exposures are rightside up and upside down state occurs towards end of exposure sequence. My current software in use extended to support this.

- For GEM with declination gear backlash, "all" slews need to "approach" target from a specified declination direction (north or south). Current situation: mount polar misaligned slightly so that declination drift is always in one direction, so declination backlash never needs to be unwound during exposure tracking. Initial slew prior to first exposure in sequence needs to result in a backlash unwound state. So slew approach direction is set appropriately based on polar misalignment direction. My current software in use extended to support this.

- Both of these are absolute requirements for me to obtain good tracking and efficient dark time utilization with my Takahashi EM-400 mount.

Thanks,
Mike

Hi Mike,

What software do you use at the moment? I use Chuck's ASCOM driver and I'm not sure it supports what you are describing. In any case, shouldn't your requirements be aimed at the INDI platform at its Temma driver? From what I've read it seems to be a bit underdeveloped at the moment.

Thanks,

  Sander
 
Sander,

My own. Note Chuck's software does support Tak non-meridian flipping (at my request :).

We will do everything on our own.

I need concurrent task execution support. My refocus software runs concurrently to autoguiding, measures a temperature probe mounted on tube, and updates FLI Atlas focuser a few microns at a time depending on temperature change every minute or so based on a calibrated model. Critical for tight stars on 40min Ha FSQ frames in changing ambient conditions at my sites.

Thanks,
Mike
 
mschuster said:
Sander,

My own. Note Chuck's software does support Tak non-meridian flipping (at my request :).

We will do everything on our own.

I need concurrent task execution support. My refocus software runs concurrently to autoguiding, measures a temperature probe mounted on tube, and updates FLI Atlas focuser a few microns at a time depending on temperature change every minute or so based on a calibrated model. Critical for tight stars on 40min Ha FSQ frames in changing ambient conditions at my sites.

Thanks,
Mike

In the future you'll be able to send commands to a running PixInsight instance through the system shell.

V.
 
mschuster said:
Sander,

My own. Note Chuck's software does support Tak non-meridian flipping (at my request :).

We will do everything on our own.

I need concurrent task execution support. My refocus software runs concurrently to autoguiding, measures a temperature probe mounted on tube, and updates FLI Atlas focuser a few microns at a time depending on temperature change every minute or so based on a calibrated model. Critical for tight stars on 40min Ha FSQ frames in changing ambient conditions at my sites.

Thanks,
Mike

OTOH, how does your software the concurrent refocus? Based only on temperature? Or by measuring the PSF? Or any other way?
 
OTOH, how does your software the concurrent refocus? Based only on temperature? Or by measuring the PSF? Or any other way?

Temperature only (i.e. an open loop controller). The temperature/focus drift model is good but not perfect. Refocuser runs for one 40 min exposure and then stops. A normal refocus is done between each exposure. So the refocuser starts from a known good point.

A ~2 micron focuser movement happens whenever temperature has changed 0.05?C which occurs on average every 2 minutes. With the Atlas, small movements help reduce lateral image shift (autoguided out) and improve overall tracking accuracy.

Mike
 
Yes, you are right of course that the Temma driver has the 'flip' command. I forgot about that.

No, not a simple flip command, but rather a non-meridian flipping slew.

A normal slew across the meridian will flip a GEM to keep the scope on top. Need a slew where the flip point is the act of crossing any arbitrary local hour angle.

Suppose the flip point is two hours prior to the meridian, the GEM is slewed one hour prior, the scope ends up upside down. Now a small slew is done to target a nearby bright star for focusing purposes, the scope remains upside down (if less than two hours prior). Then a small slew back to the target. The scope remains upside down.

The maximum meridian flipping offset is limited to avoid any chance of crashing. On my setup within two hours is OK.

And to avoid backlash problems, all of these slews need to approach the target from the specified declination direction. This in general may require declination overshoot and backtrack by an amount larger than worst case backlash.

Thanks,
Mike
 
Buzz said:
Not true BUT importantly Indi has the ability to control an EQMod mount. It even works with my Bluetooth EQ dongle (under Windows, OSX and/or Linux).

Chris

ps Having Indi Server running on a Pi has a lot of benefit for low power consumption uses such as star parties. I have done a couple of sessions using other Indi Client software using Indi Server on a PI powered by a small phone charger battery (which happily powers it for 24hours).
 
mschuster said:
Yes, you are right of course that the Temma driver has the 'flip' command. I forgot about that.

No, not a simple flip command, but rather a non-meridian flipping slew.

A normal slew across the meridian will flip a GEM to keep the scope on top. Need a slew where the flip point is the act of crossing any arbitrary local hour angle.

Suppose the flip point is two hours prior to the meridian, the GEM is slewed one hour prior, the scope ends up upside down. Now a small slew is done to target a nearby bright star for focusing purposes, the scope remains upside down (if less than two hours prior). Then a small slew back to the target. The scope remains upside down.

And to avoid backlash problems, all of these slews need to approach the target from the specified declination direction. This in general may require declination overshoot and backtrack by an amount larger than worst case backlash.

Thanks,
Mike

OK, that is useful, thanks. I will read up on how to do this.
 
Hi!
Excuse for my English.
Use for GoTo in INDIMount online of catalogues strongly narrows possibilities of application INDIMount on the nature.
Whether there is a possibility to make connected catalogues from a hard disk? UCAC4, UCAC3?
Thanks,
Evgeniy
 
Back
Top