INDIClient version 1.0.14.193 #30
Comments
|
Hi Juan, Thanks a lot! 2016-06-17 15:08 GMT+02:00 Juan Conejero notifications@github.com:
|
|
Hi Klaus,
That would be great! Let me know how it goes. |
|
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 pcl_enum p_telescopeSelection
pcl_bool p_requireSelectedTelescope String p_telescopeDeviceName 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 double o_apparentTargetRA 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 |
|
Hi Juan, Yesterdays weather was not as expected and I could not test the new module 2016-06-17 19:52 GMT+02:00 Juan Conejero notifications@github.com:
|
|
Hi Juan,
I could repeat the same steps to many other objects without any problems, Unfortunately I couldn't test the the other side of the meridian due to 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 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, 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 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.
That's very true. Hopefully we'll be able to use some telescopes from our university's observatory. Am I right, Vicent? |
|
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)
|
|
Hi, Congratulations on the new tool. You have some interesting comments by Regarding the pointing model, I was talking with Juan about the numeric Then we should think how we can handle the calculated pointing model. I'll be at the observatory from June 22nd to July 1st. I'll go there V. On 06/21/2016 05:31 PM, Juan Conejero wrote:
Vicent Peris Baixauli Astrofotógrafo Edifici Instituts d'Investigació. OAUV: http://observatori.uv.es |
|
Hi again, Although this is still not a priority, leave the room to calculate the V. On 06/21/2016 05:31 PM, Juan Conejero wrote:
Vicent Peris Baixauli Astrofotógrafo Edifici Instituts d'Investigació. OAUV: http://observatori.uv.es |
|
Hi Georg, Hi Juan, The INDI Eqmod driver has implemented the models which are refered in the 2016-06-21 18:42 GMT+02:00 Georg Viehoever notifications@github.com:
|
|
Hi Vicent,
2016-06-21 18:43 GMT+02:00 vicentperis notifications@github.com:
|
Yes, normally the mounts trigger a meridian flip within a "GoTo" command if 2016-06-21 23:10 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:
|
|
Hi, Additionally, I simulated an alignment process to create a pointing model So I did the following (manual) steps For n stars DO
If the alignment stars are close enough (angular distance), so that the After changing the meridian side (pierside of GEM changed), the scope was Here is a pitfall for the user ... when you use "Slew control" to move the I solved this simply by manually centering and synching again. But maybe we Aynway with this small workaround I was able to create a pointing model But I believe we can do it better than the current INDI Eqmod For testing telescope pointing models, I can create a dataset of synch Klaus 2016-06-20 0:07 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:
|
I did some mesurements and tested the model with a simple least-square fit @juan: I couldn't find a method in the PCL library for fitting linear 2016-06-25 18:38 GMT+02:00 Klaus Kretzschmar kkretzschmar@googlemail.com:
|
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...
The text was updated successfully, but these errors were encountered: