INDIClient version 1.0.14.193

[jconejero]

I've just committed a new version of the INDIClient module with many of the features we were discussing in other posts (apparent positions, better management of image properties/keywords, etc).

Lots of things to comment. I'll return here later with a description of changes.

IMO this version is now 100% ready for release. Let's see how it performs under the real sky...

[kkretzschmar]

Hi Juan,
fantastic! I'll test the new module on real stars as soon as the weather
allows to ... might be already this night!

Thanks a lot!

2016-06-17 15:08 GMT+02:00 Juan Conejero notifications@github.com:

I've just commited a new version of the INDIClient module with many of the
features we were discussing in other posts (apparent positions, better
management of image properties/keywords, etc).

Lots of things to comment. I'll return here later with a description of
changes.

IMO this version is now 100% ready for release. Let's see how it performs
under the real sky...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#30, or mute the thread
https://github.com/notifications/unsubscribe/ACDypvP7Ceew-2S6__A_mZ46zT-HnQxlks5qMpxJgaJpZM4I4Vy8
.

[jconejero]

Hi Klaus,

might be already this night!

That would be great! Let me know how it goes.

[jconejero]

Here is a brief description of the main changes and new features I've introduced in this version.

INDICCDFrameInstance

This process has the following new parameters:

String p_objectName
The name or title of the object or event being observed. Will be set as the value of standard Observation:Object:Name XISF properties and OBJECT FITS keywords in newly created images.

pcl_enum p_telescopeSelection
This parameter tells how to select the telescope used for image acquisition (see the ICFTelescopeSelection enumerated parameter). The implemented options are:

• ICFTelescopeSelection::NoTelescope. In this mode newly acquired frames won't have any property or keyword related to the observation position. The OBJCTRA and OBJCDEC keywords provided by INDI (inaccurate) will be left intact.
• ICFTelescopeSelection::ActiveTelescope. Select the device specified by the ACTIVE_DEVICES > ACTIVE_TELESCOPE property of the INDI CCD device being used for acquisition.
• ICFTelescopeSelection::MountControllerTelescope. Select the device currently selected in the INDI Mount Controller interface, which is given by TheINDIMountInterface->CurrentDeviceName().
• ICFTelescopeSelection::ActiveOrMountControllerTelescope. Select the active telescope if available, or the INDI Mount Controller device otherwise.
• ICFTelescopeSelection::TelescopeDeviceName. Select the device specified by the p_telescopeDeviceName parameter of INDICCDFrameInstance.

pcl_bool p_requireSelectedTelescope
If this parameter is true, the acquisition process will fail if a valid telescope device cannot be retrieved by the method defined by the p_telescopeSelection parameter. If this parameter is false, the telescope device is optional.

String p_telescopeDeviceName
The name of a valid INDI telescope device when p_telescopeSelection = ICFTelescopeSelection::TelescopeDeviceName (see above).

When a telescope device is available, it is used to retrieve its current EOD (epoch of date) coordinates just before each exposure performed by AbstractINDICCDFrameExecution::Perform(). These are apparent coordinates (since a real telescope always observes the apparent topocentric celestial sphere), which are converted to geocentric mean positions referred to the equinox and equator of J2000.0 (ICRS) by an accurate 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). The same coordinates replace the OBJCTRA and OBJCTDEC FITS keywords provided by the INDI server, which are inaccurate because they are just precessed from EOD to J2000.0, but include the effects of nutation and stellar aberration, among other issues.

The main advantages of this process are (1) we always store mean geocentric 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).

In the current implementation, apparent positions include precession, nutation, stellar aberration and (for pointing or goto operations only) proper motions when available. To be rigorous, we should compute topocentric positions instead of assuming that the observer is placed at the geocenter. We probably should include also the effect of atmospheric refraction, which may be tricky. To evaluate the true relevance of these effects we should perform experimental tests under the real sky. For goto operations, the corrections for parallax / radial velocity are not computed, but these are very small in virtually all cases (the largest parallax is less than 0.75 arcsec) and negligible for instrument control tasks.

I have based this implementation (see ApparentPosition.h and ApparentPosition.cpp) on the IAU SOFA software library (http://www.iausofa.org/). I have solved the inverse stellar aberration transformation problem using Mathematica version 10.

INDIMountInstance

New parameters:

pcl_bool p_computeApparentPosition
When this parameter is true (it is false by default), AbstractINDIMountExecution::Perform() will compute apparent positions from p_targetRA and p_targetDec (obviously without proper motions, which are unknown at this point) in GoTo and Sync operations. This is very useful because one can simply send catalog coordinates to INDIMountInstance, e.g. from a script, and let it manage the mean to apparent coordinate transformation transparently.

double o_apparentTargetRA
double o_apparentTargetDec
These are read-only output parameters that store the computed apparent positions after a successful GoTo or Sync command, when p_computeApparentPosition = true.

CoordinateSearchDialog

This dialog is now largely improved to retrieve additional information about the objects, including proper motions, parallax and radial velocity, when available, as well as object type, spectral type and visual magnitude.

When the user performs a GoTo operation from CoordinateSearchDialog (by clicking the GoTo button on the dialog), or simply uses it to acquire target coordinates (by clicking the Get button), apparent coordinates are automatically computed, including proper motions when available.

Apparent positions are being computed with excessive precision accuracy in this implementation, considering the practical limitations of a real instrument (flexure, mechanical inaccuracies, misalignments to the celestial pole, etc). However, the calculation routines are quite cheap in terms of computational resources, and I always prefer to have too much accurate implementations instead of too little accuracy. Modern hardware is impressively accurate; see for example the latest ASA direct drive mounts.

[kkretzschmar]

Hi Juan,
thanks a lot, this is a great improvement and a must-have for any future
enhancements, especially an algorithm to correct the telescope pointing
error ( misalignment).

Yesterdays weather was not as expected and I could not test the new module
on real stars ... I'll give it a try this night again.

2016-06-17 19:52 GMT+02:00 Juan Conejero notifications@github.com:

Here is a brief description of the main changes and new features I've
introduced in this version.

INDICCDFrameInstance

This process has the following new parameters:

String p_objectName
The name or title of the object or event being observed. Will be set as
the value of standard Observation:Object:Name XISF properties and OBJECT
FITS keywords in newly created images.

pcl_enum p_telescopeSelection
This parameter tells how to select the telescope used for image
acquisition (see the ICFTelescopeSelection enumerated parameter). The
implemented options are:

• ICFTelescopeSelection::NoTelescope. In this mode newly acquired
  frames won't have any property or keyword related to the observation
  position. The OBJCTRA and OBJCDEC keywords provided by INDI (inaccurate)
  will be left intact.
• ICFTelescopeSelection::ActiveTelescope. Select the device specified
  by the ACTIVE_DEVICES > ACTIVE_TELESCOPE property of the INDI CCD device
  being used for acquisition.
• ICFTelescopeSelection::MountControllerTelescope. Select the device
  currently selected in the INDI Mount Controller interface, which is given
  by TheINDIMountInterface->CurrentDeviceName().
• ICFTelescopeSelection::ActiveOrMountControllerTelescope. Select the
  active telescope if available, or the INDI Mount Controller device
  otherwise.
• ICFTelescopeSelection::TelescopeDeviceName. Select the device
  specified by the p_telescopeDeviceName parameter of INDICCDFrameInstance.

pcl_bool p_requireSelectedTelescope
If this parameter is true, the acquisition process will fail if a valid
telescope device cannot be retrieved by the method defined by the
p_telescopeSelection parameter. If this parameter is false, the telescope
device is optional.

String p_telescopeDeviceName
The name of a valid INDI telescope device when p_telescopeSelection =
ICFTelescopeSelection::TelescopeDeviceName (see above).

When a telescope device is available, it is used to retrieve its current
EOD (epoch of date) coordinates just before each exposure performed by
AbstractINDICCDFrameExecution::Perform(). These are apparent coordinates
(since a real telescope always observes the apparent topocentric celestial
sphere), which are converted to geocentric mean positions referred to the
equinox and equator of J2000.0 (ICRS) by an accurate 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). The same coordinates replace the OBJCTRA and
OBJCTDEC FITS keywords provided by the INDI server, which are inaccurate
because they are just precessed from EOD to J2000.0, but include the
effects of nutation and stellar aberration, among other issues.

The main advantages of this process are (1) we always store mean
geocentric 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).

In the current implementation, apparent positions include precession,
nutation, stellar aberration and (for pointing or goto operations only)
proper motions when available. To be rigorous, we should compute
topocentric positions instead of assuming that the observer is placed at
the geocenter. We probably should include also the effect of atmospheric
refraction, which may be tricky. To evaluate the true relevance of these
effects we should perform experimental tests under the real sky. For goto
operations, the corrections for parallax / radial velocity are not
computed, but these are very small in virtually all cases (the largest
parallax is less than 0.75 arcsec) and negligible for instrument control
tasks.

I have based this implementation (see ApparentPosition.h and
ApparentPosition.cpp) on the IAU SOFA software library (
http://www.iausofa.org/). I have solved the inverse stellar aberration
transformation problem using Mathematica version 10.

INDIMountInstance

New parameters:

pcl_bool p_computeApparentPosition
When this parameter is true (it is false by default),
AbstractINDIMountExecution::Perform() will compute apparent positions from
p_targetRA and p_targetDec (obviously without proper motions, which are
unknown at this point) in GoTo and Sync operations. This is very useful
because one can simply send catalog coordinates to INDIMountInstance, e.g.
from a script, and let it manage the mean to apparent coordinate
transformation transparently.

double o_apparentTargetRA
double o_apparentTargetDec
These are read-only output parameters that store the computed apparent
positions after a successful GoTo or Sync command, when
p_computeApparentPosition = true.

CoordinateSearchDialog

This dialog is now largely improved to retrieve additional information
about the objects, including proper motions, parallax and radial velocity,
when available, as well as object type, spectral type and visual magnitude.

When the user performs a GoTo operation from CoordinateSearchDialog (by
clicking the GoTo button on the dialog), or simply uses it to acquire
target coordinates (by clicking the Get button), apparent coordinates are
automatically computed, including proper motions when available.

Apparent positions are being computed with excessive precision in this
implementation, considering the practical limitations of a real instrument
(flexure, mechanical inaccuracies, misalignments to the celestial pole,
etc). However, the calculation routines are quite cheap in terms of
computational resources, and I always prefer to have too much accurate
implementations instead of too little accuracy. Modern hardware is
impressively accurate; see for example the latest ASA direct drive mounts
http://www.astrosysteme.at/eng/mounts.html.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#30 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ACDypnedXQAJvQ27DXjbIOvR_kdF-VXaks5qMt7LgaJpZM4I4Vy8
.

[kkretzschmar]

Hi Juan,
this night I had the right weather conditions to test your changes. It
works perfectly !!!

• Move from parking position to vega
• Aquired an 2 sec image -> vega was not in the center of the image
• Applied ImageSolver to solve the image
• Then after executing the Mount process to the view with the solved image
  the mount moved to a new position
• Aquired another image -> vega was exactly in the center of the image

I could repeat the same steps to many other objects without any problems,
since my telescope is not really good aligned I always hat to center the
object, but it worked all the time.

Unfortunately I couldn't test the the other side of the meridian due to
occuring clouds. But I dont see any reason why it should not work.

Absolutely great job Juan. I never was that accurate in my attempts.

Btw, I would feel better if you would put your name on the copyright of the
module as well ;)... your contribution to this project is so big ...

Thanks and yes I think we are ready for release of this module ...

Klaus

2016-06-18 10:56 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:

Hi Juan,
thanks a lot, this is a great improvement and a must-have for any future
enhancements, especially an algorithm to correct the telescope pointing
error ( misalignment).

Yesterdays weather was not as expected and I could not test the new module
on real stars ... I'll give it a try this night again.

2016-06-17 19:52 GMT+02:00 Juan Conejero notifications@github.com:

Here is a brief description of the main changes and new features I've
introduced in this version.

INDICCDFrameInstance

This process has the following new parameters:

String p_objectName
The name or title of the object or event being observed. Will be set as
the value of standard Observation:Object:Name XISF properties and OBJECT
FITS keywords in newly created images.

pcl_enum p_telescopeSelection
This parameter tells how to select the telescope used for image
acquisition (see the ICFTelescopeSelection enumerated parameter). The
implemented options are:

• ICFTelescopeSelection::NoTelescope. In this mode newly acquired
  frames won't have any property or keyword related to the observation
  position. The OBJCTRA and OBJCDEC keywords provided by INDI (inaccurate)
  will be left intact.
• ICFTelescopeSelection::ActiveTelescope. Select the device specified
  by the ACTIVE_DEVICES > ACTIVE_TELESCOPE property of the INDI CCD device
  being used for acquisition.
• ICFTelescopeSelection::MountControllerTelescope. Select the device
  currently selected in the INDI Mount Controller interface, which is given
  by TheINDIMountInterface->CurrentDeviceName().
• ICFTelescopeSelection::ActiveOrMountControllerTelescope. Select the
  active telescope if available, or the INDI Mount Controller device
  otherwise.
• ICFTelescopeSelection::TelescopeDeviceName. Select the device
  specified by the p_telescopeDeviceName parameter of INDICCDFrameInstance.

pcl_bool p_requireSelectedTelescope
If this parameter is true, the acquisition process will fail if a valid
telescope device cannot be retrieved by the method defined by the
p_telescopeSelection parameter. If this parameter is false, the telescope
device is optional.

String p_telescopeDeviceName
The name of a valid INDI telescope device when p_telescopeSelection =
ICFTelescopeSelection::TelescopeDeviceName (see above).

When a telescope device is available, it is used to retrieve its current
EOD (epoch of date) coordinates just before each exposure performed by
AbstractINDICCDFrameExecution::Perform(). These are apparent coordinates
(since a real telescope always observes the apparent topocentric celestial
sphere), which are converted to geocentric mean positions referred to the
equinox and equator of J2000.0 (ICRS) by an accurate 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). The same coordinates replace the OBJCTRA and
OBJCTDEC FITS keywords provided by the INDI server, which are inaccurate
because they are just precessed from EOD to J2000.0, but include the
effects of nutation and stellar aberration, among other issues.

The main advantages of this process are (1) we always store mean
geocentric 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).

In the current implementation, apparent positions include precession,
nutation, stellar aberration and (for pointing or goto operations only)
proper motions when available. To be rigorous, we should compute
topocentric positions instead of assuming that the observer is placed at
the geocenter. We probably should include also the effect of atmospheric
refraction, which may be tricky. To evaluate the true relevance of these
effects we should perform experimental tests under the real sky. For goto
operations, the corrections for parallax / radial velocity are not
computed, but these are very small in virtually all cases (the largest
parallax is less than 0.75 arcsec) and negligible for instrument control
tasks.

I have based this implementation (see ApparentPosition.h and
ApparentPosition.cpp) on the IAU SOFA software library (
http://www.iausofa.org/). I have solved the inverse stellar aberration
transformation problem using Mathematica version 10.

INDIMountInstance

New parameters:

pcl_bool p_computeApparentPosition
When this parameter is true (it is false by default),
AbstractINDIMountExecution::Perform() will compute apparent positions from
p_targetRA and p_targetDec (obviously without proper motions, which are
unknown at this point) in GoTo and Sync operations. This is very useful
because one can simply send catalog coordinates to INDIMountInstance, e.g.
from a script, and let it manage the mean to apparent coordinate
transformation transparently.

double o_apparentTargetRA
double o_apparentTargetDec
These are read-only output parameters that store the computed apparent
positions after a successful GoTo or Sync command, when
p_computeApparentPosition = true.

CoordinateSearchDialog

This dialog is now largely improved to retrieve additional information
about the objects, including proper motions, parallax and radial velocity,
when available, as well as object type, spectral type and visual magnitude.

When the user performs a GoTo operation from CoordinateSearchDialog (by
clicking the GoTo button on the dialog), or simply uses it to acquire
target coordinates (by clicking the Get button), apparent coordinates are
automatically computed, including proper motions when available.

Apparent positions are being computed with excessive precision in this
implementation, considering the practical limitations of a real instrument
(flexure, mechanical inaccuracies, misalignments to the celestial pole,
etc). However, the calculation routines are quite cheap in terms of
computational resources, and I always prefer to have too much accurate
implementations instead of too little accuracy. Modern hardware is
impressively accurate; see for example the latest ASA direct drive mounts
http://www.astrosysteme.at/eng/mounts.html.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#30 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ACDypnedXQAJvQ27DXjbIOvR_kdF-VXaks5qMt7LgaJpZM4I4Vy8
.

[kkretzschmar]

Hi Juan,
I have seen that you have released the module, great!

Concerning 'Telescope Pointing Model', I have found the following paper

http://www.boulder.swri.edu/~buie/idl/downloads/pointing/pointing.pdf

Looks not so complicated, but it will be difficult to test ...

2016-06-20 0:07 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:

Hi Juan,
this night I had the right weather conditions to test your changes. It
works perfectly !!!

• Move from parking position to vega
• Aquired an 2 sec image -> vega was not in the center of the image
• Applied ImageSolver to solve the image
• Then after executing the Mount process to the view with the solved image
  the mount moved to a new position
• Aquired another image -> vega was exactly in the center of the image

I could repeat the same steps to many other objects without any problems,
since my telescope is not really good aligned I always hat to center the
object, but it worked all the time.

Unfortunately I couldn't test the the other side of the meridian due to
occuring clouds. But I dont see any reason why it should not work.

Absolutely great job Juan. I never was that accurate in my attempts.

Btw, I would feel better if you would put your name on the copyright of
the module as well ;)... your contribution to this project is so big ...

Thanks and yes I think we are ready for release of this module ...

Klaus

2016-06-18 10:56 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com
:

Hi Juan,
thanks a lot, this is a great improvement and a must-have for any future
enhancements, especially an algorithm to correct the telescope pointing
error ( misalignment).

Yesterdays weather was not as expected and I could not test the new
module on real stars ... I'll give it a try this night again.

2016-06-17 19:52 GMT+02:00 Juan Conejero notifications@github.com:

Here is a brief description of the main changes and new features I've
introduced in this version.

INDICCDFrameInstance

This process has the following new parameters:

String p_objectName
The name or title of the object or event being observed. Will be set as
the value of standard Observation:Object:Name XISF properties and OBJECT
FITS keywords in newly created images.

pcl_enum p_telescopeSelection
This parameter tells how to select the telescope used for image
acquisition (see the ICFTelescopeSelection enumerated parameter). The
implemented options are:

• ICFTelescopeSelection::NoTelescope. In this mode newly acquired
  frames won't have any property or keyword related to the observation
  position. The OBJCTRA and OBJCDEC keywords provided by INDI (inaccurate)
  will be left intact.
• ICFTelescopeSelection::ActiveTelescope. Select the device
  specified by the ACTIVE_DEVICES > ACTIVE_TELESCOPE property of the INDI CCD
  device being used for acquisition.
• ICFTelescopeSelection::MountControllerTelescope. Select the device
  currently selected in the INDI Mount Controller interface, which is given
  by TheINDIMountInterface->CurrentDeviceName().
• ICFTelescopeSelection::ActiveOrMountControllerTelescope. Select
  the active telescope if available, or the INDI Mount Controller device
  otherwise.
• ICFTelescopeSelection::TelescopeDeviceName. Select the device
  specified by the p_telescopeDeviceName parameter of INDICCDFrameInstance.

pcl_bool p_requireSelectedTelescope
If this parameter is true, the acquisition process will fail if a valid
telescope device cannot be retrieved by the method defined by the
p_telescopeSelection parameter. If this parameter is false, the telescope
device is optional.

String p_telescopeDeviceName
The name of a valid INDI telescope device when p_telescopeSelection =
ICFTelescopeSelection::TelescopeDeviceName (see above).

When a telescope device is available, it is used to retrieve its current
EOD (epoch of date) coordinates just before each exposure performed by
AbstractINDICCDFrameExecution::Perform(). These are apparent coordinates
(since a real telescope always observes the apparent topocentric celestial
sphere), which are converted to geocentric mean positions referred to the
equinox and equator of J2000.0 (ICRS) by an accurate 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). The same coordinates replace the OBJCTRA and
OBJCTDEC FITS keywords provided by the INDI server, which are inaccurate
because they are just precessed from EOD to J2000.0, but include the
effects of nutation and stellar aberration, among other issues.

The main advantages of this process are (1) we always store mean
geocentric 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).

In the current implementation, apparent positions include precession,
nutation, stellar aberration and (for pointing or goto operations only)
proper motions when available. To be rigorous, we should compute
topocentric positions instead of assuming that the observer is placed at
the geocenter. We probably should include also the effect of atmospheric
refraction, which may be tricky. To evaluate the true relevance of these
effects we should perform experimental tests under the real sky. For goto
operations, the corrections for parallax / radial velocity are not
computed, but these are very small in virtually all cases (the largest
parallax is less than 0.75 arcsec) and negligible for instrument control
tasks.

I have based this implementation (see ApparentPosition.h and
ApparentPosition.cpp) on the IAU SOFA software library (
http://www.iausofa.org/). I have solved the inverse stellar aberration
transformation problem using Mathematica version 10.

INDIMountInstance

New parameters:

pcl_bool p_computeApparentPosition
When this parameter is true (it is false by default),
AbstractINDIMountExecution::Perform() will compute apparent positions from
p_targetRA and p_targetDec (obviously without proper motions, which are
unknown at this point) in GoTo and Sync operations. This is very useful
because one can simply send catalog coordinates to INDIMountInstance, e.g.
from a script, and let it manage the mean to apparent coordinate
transformation transparently.

double o_apparentTargetRA
double o_apparentTargetDec
These are read-only output parameters that store the computed apparent
positions after a successful GoTo or Sync command, when
p_computeApparentPosition = true.

CoordinateSearchDialog

This dialog is now largely improved to retrieve additional information
about the objects, including proper motions, parallax and radial velocity,
when available, as well as object type, spectral type and visual magnitude.

When the user performs a GoTo operation from CoordinateSearchDialog (by
clicking the GoTo button on the dialog), or simply uses it to acquire
target coordinates (by clicking the Get button), apparent coordinates are
automatically computed, including proper motions when available.

Apparent positions are being computed with excessive precision in this
implementation, considering the practical limitations of a real instrument
(flexure, mechanical inaccuracies, misalignments to the celestial pole,
etc). However, the calculation routines are quite cheap in terms of
computational resources, and I always prefer to have too much accurate
implementations instead of too little accuracy. Modern hardware is
impressively accurate; see for example the latest ASA direct drive
mounts http://www.astrosysteme.at/eng/mounts.html.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACDypnedXQAJvQ27DXjbIOvR_kdF-VXaks5qMt7LgaJpZM4I4Vy8
.

[jconejero]

Hi Klaus,

Thanks! That paper is very interesting. See also a nice general description of the pointing problem by the author of TPoint:

http://www.tpointsw.uk/pointing.htm

The project to implement a pointing modelling tool arises directly from your idea of differential correction in INDIMount::ExecuteOn(). The mechanics of building a pointing model are essentially the same: compute differences between observation pointing locations and true astrometrically solved positions.

An analytical model is very nice, mainly because it attempts to describe the causes of pointing errors, so it is also a diagnostics tool. However, I am thinking more on a purely numerical solution, which provides less information about mechanical issues but is IMO potentially more accurate and flexible. Basically, we can build an approximating surface spline (aka thin plate) from measured differences in horizontal coordinates, then apply the spline to compute corrections each time we send new coordinates to the telescope. This is an empirical pointing model. It works exactly the same way as in DBE to build a model of the image background, or in DynamicAlignment to build an image registration model, for example. I use surface splines also in StarAlignment to build local distortion models. The big advantage of surface splines is that they are extremely flexible, and hence able to adapt to extremely complex functions. They are also numerically and computationally efficient, especially as I use them in StarAlignment.

The whole process of pointing model construction can be fully automated, even using a relatively simple script, with INDICCDFrame and INDIMount. This could be done right now, in fact. However, we need several improvements, especially to include atmospheric refraction in our apparent coordinate reduction model. We should have also topocentric coordinates to be rigorous. This is the basic idea. Note that it does not exclude the possibility to generate analytical models, as described in the paper you've found. I think we should explore both ways.

Looks not so complicated, but it will be difficult to test ...

That's very true. Hopefully we'll be able to use some telescopes from our university's observatory. Am I right, Vicent?

[GeorgViehoever]

I would very much prefer a model with analytical foundations (I.e. Based on spherical geometry, coordinate transformations plus some well understood empirical components for atmospheric aberration), with a thin plate model on top of it to capture factors that simply cannot be captured this way, such as mount flexure and temperature effects.

Reasoning: analytical model keeps corrections necessary by thin plates to a minimum, and allows for analysis of root causes of pointing errors. With a purely empirical model this is not possible.

Maybe this paper is also useful: http://eq-mod.sourceforge.net/docs/eqmod_alignment_models.pdf

Georg

Georg Viehöver (georg.viehoever@web.de)

Am 21.06.2016 um 17:31 schrieb Juan Conejero notifications@github.com:

Hi Klaus,

Thanks! That paper is very interesting. See also a nice general description of the pointing problem by the author of TPoint:

http://www.tpointsw.uk/pointing.htm

The project to implement a pointing modelling tool arises directly from your idea of differential correction in INDIMount::ExecuteOn(). The mechanics of building a pointing model are essentially the same: compute differences between observation pointing locations and true astrometrically solved positions.

An analytical model is very nice, mainly because it attempts to describe the causes of pointing errors, so it is also a diagnostics tool. However, I am thinking more on a purely numerical solution, which provides less information about mechanical issues but is IMO potentially more accurate and flexible. Basically, we can build an approximating surface spline (aka thin plate) from measured differences in horizontal coordinates, then apply the spline to compute corrections each time we send new coordinates to the telescope. This is an empirical pointing model. It works exactly the same way as in DBE to build a model of the image background, or in DynamicAlignment to build an image registration model, for example. I use surface splines also in StarAlignment to build local distortion models. The big advantage of surface splines is that they are extremely flexible, and hence able to adapt to extremely complex functions. They are also numerically and computationally efficient, especially as I use them in StarAlignment.

The whole process of pointing model construction can be fully automated, even using a relatively simple script, with INDICCDFrame and INDIMount. This could be done right now, in fact. However, we need several improvements, especially to include atmospheric refraction in our apparent coordinate reduction model. We should have also topocentric coordinates to be rigorous. This is the basic idea. Note that it does not exclude the possibility to generate analytical models, as described in the paper you've found. I think we should explore both ways.

Looks not so complicated, but it will be difficult to test ...

That's very true. Hopefully we'll be able to use some telescopes from our university's observatory. Am I right, Vicent?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[vicentperis]

Hi,

Congratulations on the new tool. You have some interesting comments by
Mike Schuster on the PI Forum. The things about the meridian flip can be
tricky because some mounts handle the meridian flip automatically...
Anyway, for all these options and the pointing model I think what we
really need now is some preferences about the observatory. Would it be
possible to add in the EDIT menu an "Observatory preferences" option?

Regarding the pointing model, I was talking with Juan about the numeric
approach to the pointing model. Think also that this can be very useful
to split the model in two parts (W and E) for GEMs. I'm thinking about a
tool, not a script. In this tool, you can add files. Those files are
images that you previously acquired, so the pointing model is calculated
by solving all the images and calculating the positional error. Then,
alternatively, we have a kind of "real time pointing model generation",
where you don't load any image and the scope starts to slew and acquire
images; after all the images are acquired, the images are solved and the
pointing model is generated.

Then we should think how we can handle the calculated pointing model.
It's saved into a process icon? It's saved to a text file? Is it loaded
into the observatory preferences? It can be also useful to have multiple
pointing models available (in case you have a piggyback telescope with a
second camera); in that case, it could be useful to use icons to load
the pointing model you'll be using that night.

I'll be at the observatory from June 22nd to July 1st. I'll go there
again by the end of July. I can test it with a Paramount and a Meade 16"
OTA, and an Astelco mount with a Planewave 20" CDK. Take into account
that I'll be at the observatory also by the en of August, but I'll be on
holidays during September.

V.

On 06/21/2016 05:31 PM, Juan Conejero wrote:

Hi Klaus,

Thanks! That paper is very interesting. See also a nice general
description of the pointing problem by the author of TPoint:

http://www.tpointsw.uk/pointing.htm

The project to implement a pointing modelling tool arises directly
from your idea of differential correction in INDIMount::ExecuteOn().
The mechanics of building a pointing model are essentially the same:
compute differences between observation pointing locations and true
astrometrically solved positions.

An analytical model is very nice, mainly because it attempts to
describe the causes of pointing errors, so it is also a diagnostics
tool. However, I am thinking more on a purely numerical solution,
which provides less information about mechanical issues but is IMO
potentially more accurate and flexible. Basically, we can build an
approximating surface spline (aka thin plate) from measured
differences in horizontal coordinates, then apply the spline to
compute corrections each time we send new coordinates to the
telescope. This is an /empirical pointing model/. It works exactly the
same way as in DBE to build a model of the image background, or in
DynamicAlignment to build an image registration model, for example. I
use surface splines also in StarAlignment to build local distortion
models. The big advantage of surface splines is that they are
extremely flexible, and hence able to adapt to extremely complex
functions. They are also numerically and computationally efficient,
especially as I use them in StarAlignment.

The whole process of pointing model construction can be fully
automated, even using a relatively simple script, with INDICCDFrame
and INDIMount. This could be done right now, in fact. However, we need
several improvements, especially to include atmospheric refraction in
our apparent coordinate reduction model. We should have also
topocentric coordinates to be rigorous. This is the basic idea. Note
that it does not exclude the possibility to generate analytical
models, as described in the paper you've found. I think we should
explore both ways.

Looks not so complicated, but it will be difficult to test ...

That's very true. Hopefully we'll be able to use some telescopes from
our university's observatory. Am I right, Vicent?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AR1Mqw9ivglwoXT1Tu4MkeeYOsXZ6qSVks5qOAPZgaJpZM4I4Vy8.

---

Vicent Peris Baixauli

Astrofotógrafo
Observatori Astronòmic - Universitat de València

Edifici Instituts d'Investigació.
C/ Catedrático José Beltrán, nº 2.
E- 46980 Paterna (Valencia)Spain
Tel. +34 96 354 3819

OAUV: http://observatori.uv.es
Astrofoto: http://astrofoto.es
DSA: http://astro-photographer.org
PixInsight: http://pixinsight.com

---

[vicentperis]

Hi again,

Although this is still not a priority, leave the room to calculate the
atmospheric refraction based on meteorological conditions, when we have
a meteo station monitoring tool. It would be nice if we calculate a
pointing model that's refraction independent, and then make additional
corrections based on the meteo data.

V.

On 06/21/2016 05:31 PM, Juan Conejero wrote:

Hi Klaus,

Thanks! That paper is very interesting. See also a nice general
description of the pointing problem by the author of TPoint:

http://www.tpointsw.uk/pointing.htm

The project to implement a pointing modelling tool arises directly
from your idea of differential correction in INDIMount::ExecuteOn().
The mechanics of building a pointing model are essentially the same:
compute differences between observation pointing locations and true
astrometrically solved positions.

An analytical model is very nice, mainly because it attempts to
describe the causes of pointing errors, so it is also a diagnostics
tool. However, I am thinking more on a purely numerical solution,
which provides less information about mechanical issues but is IMO
potentially more accurate and flexible. Basically, we can build an
approximating surface spline (aka thin plate) from measured
differences in horizontal coordinates, then apply the spline to
compute corrections each time we send new coordinates to the
telescope. This is an /empirical pointing model/. It works exactly the
same way as in DBE to build a model of the image background, or in
DynamicAlignment to build an image registration model, for example. I
use surface splines also in StarAlignment to build local distortion
models. The big advantage of surface splines is that they are
extremely flexible, and hence able to adapt to extremely complex
functions. They are also numerically and computationally efficient,
especially as I use them in StarAlignment.

The whole process of pointing model construction can be fully
automated, even using a relatively simple script, with INDICCDFrame
and INDIMount. This could be done right now, in fact. However, we need
several improvements, especially to include atmospheric refraction in
our apparent coordinate reduction model. We should have also
topocentric coordinates to be rigorous. This is the basic idea. Note
that it does not exclude the possibility to generate analytical
models, as described in the paper you've found. I think we should
explore both ways.

Looks not so complicated, but it will be difficult to test ...

That's very true. Hopefully we'll be able to use some telescopes from
our university's observatory. Am I right, Vicent?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AR1Mqw9ivglwoXT1Tu4MkeeYOsXZ6qSVks5qOAPZgaJpZM4I4Vy8.

---

Vicent Peris Baixauli

Astrofotógrafo
Observatori Astronòmic - Universitat de València

Edifici Instituts d'Investigació.
C/ Catedrático José Beltrán, nº 2.
E- 46980 Paterna (Valencia)Spain
Tel. +34 96 354 3819

OAUV: http://observatori.uv.es
Astrofoto: http://astrofoto.es
DSA: http://astro-photographer.org
PixInsight: http://pixinsight.com

---

[kkretzschmar]

Hi Georg, Hi Juan,
yes I think both approaches and maybe also a combination of both should be
investigated. I can also test it with my backard observatory I have a
perfectly misaligned telescope ;)...

The INDI Eqmod driver has implemented the models which are refered in the
Eqmod paper, I think they are also using the "numerical" approach.

2016-06-21 18:42 GMT+02:00 Georg Viehoever notifications@github.com:

I would very much prefer a model with analytical foundations (I.e. Based
on spherical geometry, coordinate transformations plus some well understood
empirical components for atmospheric aberration), with a thin plate model
on top of it to capture factors that simply cannot be captured this way,
such as mount flexure and temperature effects.

Reasoning: analytical model keeps corrections necessary by thin plates to
a minimum, and allows for analysis of root causes of pointing errors. With
a purely empirical model this is not possible.

Maybe this paper is also useful:
http://eq-mod.sourceforge.net/docs/eqmod_alignment_models.pdf

Georg

Georg Viehöver (georg.viehoever@web.de)

Am 21.06.2016 um 17:31 schrieb Juan Conejero notifications@github.com:

Hi Klaus,

Thanks! That paper is very interesting. See also a nice general
description of the pointing problem by the author of TPoint:

http://www.tpointsw.uk/pointing.htm

The project to implement a pointing modelling tool arises directly from
your idea of differential correction in INDIMount::ExecuteOn(). The
mechanics of building a pointing model are essentially the same: compute
differences between observation pointing locations and true astrometrically
solved positions.

An analytical model is very nice, mainly because it attempts to describe
the causes of pointing errors, so it is also a diagnostics tool. However, I
am thinking more on a purely numerical solution, which provides less
information about mechanical issues but is IMO potentially more accurate
and flexible. Basically, we can build an approximating surface spline (aka
thin plate) from measured differences in horizontal coordinates, then apply
the spline to compute corrections each time we send new coordinates to the
telescope. This is an empirical pointing model. It works exactly the same
way as in DBE to build a model of the image background, or in
DynamicAlignment to build an image registration model, for example. I use
surface splines also in StarAlignment to build local distortion models. The
big advantage of surface splines is that they are extremely flexible, and
hence able to adapt to extremely complex functions. They are also
numerically and computationally efficient, especially as I use them in
StarAlignment.

The whole process of pointing model construction can be fully automated,
even using a relatively simple script, with INDICCDFrame and INDIMount.
This could be done right now, in fact. However, we need several
improvements, especially to include atmospheric refraction in our apparent
coordinate reduction model. We should have also topocentric coordinates to
be rigorous. This is the basic idea. Note that it does not exclude the
possibility to generate analytical models, as described in the paper you've
found. I think we should explore both ways.

Looks not so complicated, but it will be difficult to test ...

That's very true. Hopefully we'll be able to use some telescopes from
our university's observatory. Am I right, Vicent?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#30 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ACDypsu_4CYkyHVpQEowiBULmYMmwFWuks5qOBRggaJpZM4I4Vy8
.

[kkretzschmar]

Hi Vicent,

Would it be possible to add in the EDIT menu an "Observatory preferences"
option?
Yes you are right, this should be top priority. I can add a Observatory
preferences Dialog to enter geographic coordinates and the altitude of the
obervatory. These data are then stored with the CONFIG function on the INDI
server host. These config parameters are then loaded when a device was
selected in the PixInsight processes (maybe optionally).

Regarding the pointing model, ... "real time pointing model generation" ...
Yes this my preferred way of creating a pointing model. With the
possibility to persist the model I think you have everything you need.

It can be also useful to have multiple pointing models available
Yes good point ...

2016-06-21 18:43 GMT+02:00 vicentperis notifications@github.com:

Hi,

Congratulations on the new tool. You have some interesting comments by
Mike Schuster on the PI Forum. The things about the meridian flip can be
tricky because some mounts handle the meridian flip automatically...
Anyway, for all these options and the pointing model I think what we
really need now is some preferences about the observatory. Would it be
possible to add in the EDIT menu an "Observatory preferences" option?

Regarding the pointing model, I was talking with Juan about the numeric
approach to the pointing model. Think also that this can be very useful
to split the model in two parts (W and E) for GEMs. I'm thinking about a
tool, not a script. In this tool, you can add files. Those files are
images that you previously acquired, so the pointing model is calculated
by solving all the images and calculating the positional error. Then,
alternatively, we have a kind of "real time pointing model generation",
where you don't load any image and the scope starts to slew and acquire
images; after all the images are acquired, the images are solved and the
pointing model is generated.

Then we should think how we can handle the calculated pointing model.
It's saved into a process icon? It's saved to a text file? Is it loaded
into the observatory preferences? It can be also useful to have multiple
pointing models available (in case you have a piggyback telescope with a
second camera); in that case, it could be useful to use icons to load
the pointing model you'll be using that night.

I'll be at the observatory from June 22nd to July 1st. I'll go there
again by the end of July. I can test it with a Paramount and a Meade 16"
OTA, and an Astelco mount with a Planewave 20" CDK. Take into account
that I'll be at the observatory also by the en of August, but I'll be on
holidays during September.

V.

On 06/21/2016 05:31 PM, Juan Conejero wrote:

Hi Klaus,

Thanks! That paper is very interesting. See also a nice general
description of the pointing problem by the author of TPoint:

http://www.tpointsw.uk/pointing.htm

The project to implement a pointing modelling tool arises directly
from your idea of differential correction in INDIMount::ExecuteOn().
The mechanics of building a pointing model are essentially the same:
compute differences between observation pointing locations and true
astrometrically solved positions.

An analytical model is very nice, mainly because it attempts to
describe the causes of pointing errors, so it is also a diagnostics
tool. However, I am thinking more on a purely numerical solution,
which provides less information about mechanical issues but is IMO
potentially more accurate and flexible. Basically, we can build an
approximating surface spline (aka thin plate) from measured
differences in horizontal coordinates, then apply the spline to
compute corrections each time we send new coordinates to the
telescope. This is an /empirical pointing model/. It works exactly the
same way as in DBE to build a model of the image background, or in
DynamicAlignment to build an image registration model, for example. I
use surface splines also in StarAlignment to build local distortion
models. The big advantage of surface splines is that they are
extremely flexible, and hence able to adapt to extremely complex
functions. They are also numerically and computationally efficient,
especially as I use them in StarAlignment.

The whole process of pointing model construction can be fully
automated, even using a relatively simple script, with INDICCDFrame
and INDIMount. This could be done right now, in fact. However, we need
several improvements, especially to include atmospheric refraction in
our apparent coordinate reduction model. We should have also
topocentric coordinates to be rigorous. This is the basic idea. Note
that it does not exclude the possibility to generate analytical
models, as described in the paper you've found. I think we should
explore both ways.

Looks not so complicated, but it will be difficult to test ...

That's very true. Hopefully we'll be able to use some telescopes from
our university's observatory. Am I right, Vicent?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
<
https://github.com/notifications/unsubscribe/AR1Mqw9ivglwoXT1Tu4MkeeYOsXZ6qSVks5qOAPZgaJpZM4I4Vy8
.

---

Vicent Peris Baixauli

Astrofotógrafo
Observatori Astronòmic - Universitat de València

Edifici Instituts d'Investigació.
C/ Catedrático José Beltrán, nº 2.
E- 46980 Paterna (Valencia)Spain
Tel. +34 96 354 3819

OAUV: http://observatori.uv.es
Astrofoto: http://astrofoto.es
DSA: http://astro-photographer.org
PixInsight: http://pixinsight.com

---

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#30 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ACDypm_cTeUbEFHnvOm1iiGW8HKpaRGhks5qOBSagaJpZM4I4Vy8
.

[kkretzschmar]

The things about the meridian flip can be
tricky because some mounts handle the meridian flip automatically...

Yes, normally the mounts trigger a meridian flip within a "GoTo" command if
the object crossed the meridian. At least what I have seen with the EqMod
driver, a Slew command "does not" trigger a meridian flip. However a
dedicated flip command on "any" hour angle would be helpful, especially if
you want take a long series of exposures on the same pier side.

2016-06-21 23:10 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:

Hi Vicent,

Would it be possible to add in the EDIT menu an "Observatory preferences"
option?
Yes you are right, this should be top priority. I can add a Observatory
preferences Dialog to enter geographic coordinates and the altitude of the
obervatory. These data are then stored with the CONFIG function on the INDI
server host. These config parameters are then loaded when a device was
selected in the PixInsight processes (maybe optionally).

Regarding the pointing model, ... "real time pointing model generation"
...
Yes this my preferred way of creating a pointing model. With the
possibility to persist the model I think you have everything you need.

It can be also useful to have multiple pointing models available
Yes good point ...

2016-06-21 18:43 GMT+02:00 vicentperis notifications@github.com:

Hi,

Congratulations on the new tool. You have some interesting comments by
Mike Schuster on the PI Forum. The things about the meridian flip can be
tricky because some mounts handle the meridian flip automatically...
Anyway, for all these options and the pointing model I think what we
really need now is some preferences about the observatory. Would it be
possible to add in the EDIT menu an "Observatory preferences" option?

Regarding the pointing model, I was talking with Juan about the numeric
approach to the pointing model. Think also that this can be very useful
to split the model in two parts (W and E) for GEMs. I'm thinking about a
tool, not a script. In this tool, you can add files. Those files are
images that you previously acquired, so the pointing model is calculated
by solving all the images and calculating the positional error. Then,
alternatively, we have a kind of "real time pointing model generation",
where you don't load any image and the scope starts to slew and acquire
images; after all the images are acquired, the images are solved and the
pointing model is generated.

Then we should think how we can handle the calculated pointing model.
It's saved into a process icon? It's saved to a text file? Is it loaded
into the observatory preferences? It can be also useful to have multiple
pointing models available (in case you have a piggyback telescope with a
second camera); in that case, it could be useful to use icons to load
the pointing model you'll be using that night.

I'll be at the observatory from June 22nd to July 1st. I'll go there
again by the end of July. I can test it with a Paramount and a Meade 16"
OTA, and an Astelco mount with a Planewave 20" CDK. Take into account
that I'll be at the observatory also by the en of August, but I'll be on
holidays during September.

V.

On 06/21/2016 05:31 PM, Juan Conejero wrote:

Hi Klaus,

Thanks! That paper is very interesting. See also a nice general
description of the pointing problem by the author of TPoint:

http://www.tpointsw.uk/pointing.htm

The project to implement a pointing modelling tool arises directly
from your idea of differential correction in INDIMount::ExecuteOn().
The mechanics of building a pointing model are essentially the same:
compute differences between observation pointing locations and true
astrometrically solved positions.

An analytical model is very nice, mainly because it attempts to
describe the causes of pointing errors, so it is also a diagnostics
tool. However, I am thinking more on a purely numerical solution,
which provides less information about mechanical issues but is IMO
potentially more accurate and flexible. Basically, we can build an
approximating surface spline (aka thin plate) from measured
differences in horizontal coordinates, then apply the spline to
compute corrections each time we send new coordinates to the
telescope. This is an /empirical pointing model/. It works exactly the
same way as in DBE to build a model of the image background, or in
DynamicAlignment to build an image registration model, for example. I
use surface splines also in StarAlignment to build local distortion
models. The big advantage of surface splines is that they are
extremely flexible, and hence able to adapt to extremely complex
functions. They are also numerically and computationally efficient,
especially as I use them in StarAlignment.

The whole process of pointing model construction can be fully
automated, even using a relatively simple script, with INDICCDFrame
and INDIMount. This could be done right now, in fact. However, we need
several improvements, especially to include atmospheric refraction in
our apparent coordinate reduction model. We should have also
topocentric coordinates to be rigorous. This is the basic idea. Note
that it does not exclude the possibility to generate analytical
models, as described in the paper you've found. I think we should
explore both ways.

Looks not so complicated, but it will be difficult to test ...

That's very true. Hopefully we'll be able to use some telescopes from
our university's observatory. Am I right, Vicent?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
<
https://github.com/notifications/unsubscribe/AR1Mqw9ivglwoXT1Tu4MkeeYOsXZ6qSVks5qOAPZgaJpZM4I4Vy8
.

---

Vicent Peris Baixauli

Astrofotógrafo
Observatori Astronòmic - Universitat de València

Edifici Instituts d'Investigació.
C/ Catedrático José Beltrán, nº 2.
E- 46980 Paterna (Valencia)Spain
Tel. +34 96 354 3819

OAUV: http://observatori.uv.es
Astrofoto: http://astrofoto.es
DSA: http://astro-photographer.org
PixInsight: http://pixinsight.com

---

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#30 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ACDypm_cTeUbEFHnvOm1iiGW8HKpaRGhks5qOBSagaJpZM4I4Vy8
.

[kkretzschmar]

Hi,
last week I could do a second test. Differential correction works also on
the "other" meridian side, as expected.

Additionally, I simulated an alignment process to create a pointing model
with the alignment model which is implemented in the EQMod driver.

So I did the following (manual) steps

For n stars DO

• Goto star
• Aquire a CCD image
• Solve the image with "Image Solver"
• Apply differential correction
• Synch
  ENDFOR

If the alignment stars are close enough (angular distance), so that the
stars appear in the field of view of the CCD chip, then you can increase
the "aligned area" step-by-step. In my case of a telescope on a quite
"flexible" setup it worked nicely, I could cover one-half of one meridian
side.

After changing the meridian side (pierside of GEM changed), the scope was
quite misaligned so that the "alignment star" did not show up in the CCD
image.

Here is a pitfall for the user ... when you use "Slew control" to move the
star (by trial and error) back to the FOV of the CCD chip, then the
differential correction in its current form is not applicable anymore,
since the target coordinates changed. This is maybe what the user will not
consider.

I solved this simply by manually centering and synching again. But maybe we
could change the differential correctioin algortihm when it is applied in a
alignment process, in a way, that it takes the telecsope coordinates from
the "target coordinate" property instead from the current telescope
coordinates.

Aynway with this small workaround I was able to create a pointing model
which could cover the whole sky, so that the stars at least appeared in the
CCD image FOV. With that it is possible to center all objects with the
differntial correction process exactly and automatically ... really cool!

But I believe we can do it better than the current INDI Eqmod
implementation .. and we would do it for all drivers not only a single
one. I'll start with an attempt using the analytical model in a small
javascript script.

For testing telescope pointing models, I can create a dataset of synch
coordinates, i.e. the target coordinates (i.e. the GoTo coordinates), and
the delta coordinates (i.e. the delta on RA and DEC) with which the
telescope has been moved to center the stars. This could be helpful ... I
think.

Klaus

2016-06-20 0:07 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:

Hi Juan,
this night I had the right weather conditions to test your changes. It
works perfectly !!!

• Move from parking position to vega
• Aquired an 2 sec image -> vega was not in the center of the image
• Applied ImageSolver to solve the image
• Then after executing the Mount process to the view with the solved image
  the mount moved to a new position
• Aquired another image -> vega was exactly in the center of the image

I could repeat the same steps to many other objects without any problems,
since my telescope is not really good aligned I always hat to center the
object, but it worked all the time.

Unfortunately I couldn't test the the other side of the meridian due to
occuring clouds. But I dont see any reason why it should not work.

Absolutely great job Juan. I never was that accurate in my attempts.

Btw, I would feel better if you would put your name on the copyright of
the module as well ;)... your contribution to this project is so big ...

Thanks and yes I think we are ready for release of this module ...

Klaus

2016-06-18 10:56 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com
:

Hi Juan,
thanks a lot, this is a great improvement and a must-have for any future
enhancements, especially an algorithm to correct the telescope pointing
error ( misalignment).

Yesterdays weather was not as expected and I could not test the new
module on real stars ... I'll give it a try this night again.

2016-06-17 19:52 GMT+02:00 Juan Conejero notifications@github.com:

Here is a brief description of the main changes and new features I've
introduced in this version.

INDICCDFrameInstance

This process has the following new parameters:

String p_objectName
The name or title of the object or event being observed. Will be set as
the value of standard Observation:Object:Name XISF properties and OBJECT
FITS keywords in newly created images.

pcl_enum p_telescopeSelection
This parameter tells how to select the telescope used for image
acquisition (see the ICFTelescopeSelection enumerated parameter). The
implemented options are:

• ICFTelescopeSelection::NoTelescope. In this mode newly acquired
  frames won't have any property or keyword related to the observation
  position. The OBJCTRA and OBJCDEC keywords provided by INDI (inaccurate)
  will be left intact.
• ICFTelescopeSelection::ActiveTelescope. Select the device
  specified by the ACTIVE_DEVICES > ACTIVE_TELESCOPE property of the INDI CCD
  device being used for acquisition.
• ICFTelescopeSelection::MountControllerTelescope. Select the device
  currently selected in the INDI Mount Controller interface, which is given
  by TheINDIMountInterface->CurrentDeviceName().
• ICFTelescopeSelection::ActiveOrMountControllerTelescope. Select
  the active telescope if available, or the INDI Mount Controller device
  otherwise.
• ICFTelescopeSelection::TelescopeDeviceName. Select the device
  specified by the p_telescopeDeviceName parameter of INDICCDFrameInstance.

pcl_bool p_requireSelectedTelescope
If this parameter is true, the acquisition process will fail if a valid
telescope device cannot be retrieved by the method defined by the
p_telescopeSelection parameter. If this parameter is false, the telescope
device is optional.

String p_telescopeDeviceName
The name of a valid INDI telescope device when p_telescopeSelection =
ICFTelescopeSelection::TelescopeDeviceName (see above).

When a telescope device is available, it is used to retrieve its current
EOD (epoch of date) coordinates just before each exposure performed by
AbstractINDICCDFrameExecution::Perform(). These are apparent coordinates
(since a real telescope always observes the apparent topocentric celestial
sphere), which are converted to geocentric mean positions referred to the
equinox and equator of J2000.0 (ICRS) by an accurate 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). The same coordinates replace the OBJCTRA and
OBJCTDEC FITS keywords provided by the INDI server, which are inaccurate
because they are just precessed from EOD to J2000.0, but include the
effects of nutation and stellar aberration, among other issues.

The main advantages of this process are (1) we always store mean
geocentric 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).

In the current implementation, apparent positions include precession,
nutation, stellar aberration and (for pointing or goto operations only)
proper motions when available. To be rigorous, we should compute
topocentric positions instead of assuming that the observer is placed at
the geocenter. We probably should include also the effect of atmospheric
refraction, which may be tricky. To evaluate the true relevance of these
effects we should perform experimental tests under the real sky. For goto
operations, the corrections for parallax / radial velocity are not
computed, but these are very small in virtually all cases (the largest
parallax is less than 0.75 arcsec) and negligible for instrument control
tasks.

I have based this implementation (see ApparentPosition.h and
ApparentPosition.cpp) on the IAU SOFA software library (
http://www.iausofa.org/). I have solved the inverse stellar aberration
transformation problem using Mathematica version 10.

INDIMountInstance

New parameters:

pcl_bool p_computeApparentPosition
When this parameter is true (it is false by default),
AbstractINDIMountExecution::Perform() will compute apparent positions from
p_targetRA and p_targetDec (obviously without proper motions, which are
unknown at this point) in GoTo and Sync operations. This is very useful
because one can simply send catalog coordinates to INDIMountInstance, e.g.
from a script, and let it manage the mean to apparent coordinate
transformation transparently.

double o_apparentTargetRA
double o_apparentTargetDec
These are read-only output parameters that store the computed apparent
positions after a successful GoTo or Sync command, when
p_computeApparentPosition = true.

CoordinateSearchDialog

This dialog is now largely improved to retrieve additional information
about the objects, including proper motions, parallax and radial velocity,
when available, as well as object type, spectral type and visual magnitude.

When the user performs a GoTo operation from CoordinateSearchDialog (by
clicking the GoTo button on the dialog), or simply uses it to acquire
target coordinates (by clicking the Get button), apparent coordinates are
automatically computed, including proper motions when available.

Apparent positions are being computed with excessive precision in this
implementation, considering the practical limitations of a real instrument
(flexure, mechanical inaccuracies, misalignments to the celestial pole,
etc). However, the calculation routines are quite cheap in terms of
computational resources, and I always prefer to have too much accurate
implementations instead of too little accuracy. Modern hardware is
impressively accurate; see for example the latest ASA direct drive
mounts http://www.astrosysteme.at/eng/mounts.html.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACDypnedXQAJvQ27DXjbIOvR_kdF-VXaks5qMt7LgaJpZM4I4Vy8
.

[kkretzschmar]

But I believe we can do it better than the current INDI Eqmod
implementation .. and we would do it for all drivers not only a single
one. I'll start with an attempt using the analytical model

I did some mesurements and tested the model with a simple least-square fit
in python. Looks not too bad and I'd like to integrate it into the model
(using an abstract class for the alignment method, so that we can exchange
the telescope pointing models easily, e.g. using surface splines).

@juan: I couldn't find a method in the PCL library for fitting linear
multivariate linear regression models. I can use SVD to compute the
Pseudo-Inverse ... but I wanted to ask first ....

2016-06-25 18:38 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:

Hi,
last week I could do a second test. Differential correction works also on
the "other" meridian side, as expected.

Additionally, I simulated an alignment process to create a pointing model
with the alignment model which is implemented in the EQMod driver.

So I did the following (manual) steps

For n stars DO

• Goto star
• Aquire a CCD image
• Solve the image with "Image Solver"
• Apply differential correction
• Synch
  ENDFOR

If the alignment stars are close enough (angular distance), so that the
stars appear in the field of view of the CCD chip, then you can increase
the "aligned area" step-by-step. In my case of a telescope on a quite
"flexible" setup it worked nicely, I could cover one-half of one meridian
side.

After changing the meridian side (pierside of GEM changed), the scope was
quite misaligned so that the "alignment star" did not show up in the CCD
image.

Here is a pitfall for the user ... when you use "Slew control" to move the
star (by trial and error) back to the FOV of the CCD chip, then the
differential correction in its current form is not applicable anymore,
since the target coordinates changed. This is maybe what the user will not
consider.

I solved this simply by manually centering and synching again. But maybe
we could change the differential correctioin algortihm when it is applied
in a alignment process, in a way, that it takes the telecsope coordinates
from the "target coordinate" property instead from the current telescope
coordinates.

Aynway with this small workaround I was able to create a pointing model
which could cover the whole sky, so that the stars at least appeared in the
CCD image FOV. With that it is possible to center all objects with the
differntial correction process exactly and automatically ... really cool!

But I believe we can do it better than the current INDI Eqmod
implementation .. and we would do it for all drivers not only a single
one. I'll start with an attempt using the analytical model in a small
javascript script.

For testing telescope pointing models, I can create a dataset of synch
coordinates, i.e. the target coordinates (i.e. the GoTo coordinates), and
the delta coordinates (i.e. the delta on RA and DEC) with which the
telescope has been moved to center the stars. This could be helpful ... I
think.

Klaus

2016-06-20 0:07 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:

Hi Juan,
this night I had the right weather conditions to test your changes. It
works perfectly !!!

• Move from parking position to vega
• Aquired an 2 sec image -> vega was not in the center of the image
• Applied ImageSolver to solve the image
• Then after executing the Mount process to the view with the solved
  image the mount moved to a new position
• Aquired another image -> vega was exactly in the center of the image

I could repeat the same steps to many other objects without any problems,
since my telescope is not really good aligned I always hat to center the
object, but it worked all the time.

Unfortunately I couldn't test the the other side of the meridian due to
occuring clouds. But I dont see any reason why it should not work.

Absolutely great job Juan. I never was that accurate in my attempts.

Btw, I would feel better if you would put your name on the copyright of
the module as well ;)... your contribution to this project is so big ...

Thanks and yes I think we are ready for release of this module ...

Klaus

2016-06-18 10:56 GMT+02:00 Klaus Kretzschmar <kkretzschmar@googlemail.com

:

Hi Juan,
thanks a lot, this is a great improvement and a must-have for any future
enhancements, especially an algorithm to correct the telescope pointing
error ( misalignment).

Yesterdays weather was not as expected and I could not test the new
module on real stars ... I'll give it a try this night again.

2016-06-17 19:52 GMT+02:00 Juan Conejero notifications@github.com:

Here is a brief description of the main changes and new features I've
introduced in this version.

INDICCDFrameInstance

This process has the following new parameters:

String p_objectName
The name or title of the object or event being observed. Will be set as
the value of standard Observation:Object:Name XISF properties and OBJECT
FITS keywords in newly created images.

pcl_enum p_telescopeSelection
This parameter tells how to select the telescope used for image
acquisition (see the ICFTelescopeSelection enumerated parameter). The
implemented options are:

• ICFTelescopeSelection::NoTelescope. In this mode newly acquired
  frames won't have any property or keyword related to the observation
  position. The OBJCTRA and OBJCDEC keywords provided by INDI (inaccurate)
  will be left intact.
• ICFTelescopeSelection::ActiveTelescope. Select the device
  specified by the ACTIVE_DEVICES > ACTIVE_TELESCOPE property of the INDI CCD
  device being used for acquisition.
• ICFTelescopeSelection::MountControllerTelescope. Select the
  device currently selected in the INDI Mount Controller interface, which is
  given by TheINDIMountInterface->CurrentDeviceName().
• ICFTelescopeSelection::ActiveOrMountControllerTelescope. Select
  the active telescope if available, or the INDI Mount Controller device
  otherwise.
• ICFTelescopeSelection::TelescopeDeviceName. Select the device
  specified by the p_telescopeDeviceName parameter of INDICCDFrameInstance.

pcl_bool p_requireSelectedTelescope
If this parameter is true, the acquisition process will fail if a valid
telescope device cannot be retrieved by the method defined by the
p_telescopeSelection parameter. If this parameter is false, the telescope
device is optional.

String p_telescopeDeviceName
The name of a valid INDI telescope device when p_telescopeSelection =
ICFTelescopeSelection::TelescopeDeviceName (see above).

When a telescope device is available, it is used to retrieve its
current EOD (epoch of date) coordinates just before each exposure performed
by AbstractINDICCDFrameExecution::Perform(). These are apparent coordinates
(since a real telescope always observes the apparent topocentric celestial
sphere), which are converted to geocentric mean positions referred to the
equinox and equator of J2000.0 (ICRS) by an accurate 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). The same coordinates replace the OBJCTRA and
OBJCTDEC FITS keywords provided by the INDI server, which are inaccurate
because they are just precessed from EOD to J2000.0, but include the
effects of nutation and stellar aberration, among other issues.

The main advantages of this process are (1) we always store mean
geocentric 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).

In the current implementation, apparent positions include precession,
nutation, stellar aberration and (for pointing or goto operations only)
proper motions when available. To be rigorous, we should compute
topocentric positions instead of assuming that the observer is placed at
the geocenter. We probably should include also the effect of atmospheric
refraction, which may be tricky. To evaluate the true relevance of these
effects we should perform experimental tests under the real sky. For goto
operations, the corrections for parallax / radial velocity are not
computed, but these are very small in virtually all cases (the largest
parallax is less than 0.75 arcsec) and negligible for instrument control
tasks.

I have based this implementation (see ApparentPosition.h and
ApparentPosition.cpp) on the IAU SOFA software library (
http://www.iausofa.org/). I have solved the inverse stellar aberration
transformation problem using Mathematica version 10.

INDIMountInstance

New parameters:

pcl_bool p_computeApparentPosition
When this parameter is true (it is false by default),
AbstractINDIMountExecution::Perform() will compute apparent positions from
p_targetRA and p_targetDec (obviously without proper motions, which are
unknown at this point) in GoTo and Sync operations. This is very useful
because one can simply send catalog coordinates to INDIMountInstance, e.g.
from a script, and let it manage the mean to apparent coordinate
transformation transparently.

double o_apparentTargetRA
double o_apparentTargetDec
These are read-only output parameters that store the computed apparent
positions after a successful GoTo or Sync command, when
p_computeApparentPosition = true.

CoordinateSearchDialog

This dialog is now largely improved to retrieve additional information
about the objects, including proper motions, parallax and radial velocity,
when available, as well as object type, spectral type and visual magnitude.

When the user performs a GoTo operation from CoordinateSearchDialog (by
clicking the GoTo button on the dialog), or simply uses it to acquire
target coordinates (by clicking the Get button), apparent coordinates are
automatically computed, including proper motions when available.

Apparent positions are being computed with excessive precision in this
implementation, considering the practical limitations of a real instrument
(flexure, mechanical inaccuracies, misalignments to the celestial pole,
etc). However, the calculation routines are quite cheap in terms of
computational resources, and I always prefer to have too much accurate
implementations instead of too little accuracy. Modern hardware is
impressively accurate; see for example the latest ASA direct drive
mounts http://www.astrosysteme.at/eng/mounts.html.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#30 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACDypnedXQAJvQ27DXjbIOvR_kdF-VXaks5qMt7LgaJpZM4I4Vy8
.