improve UI, encapsulation and calculations of 'rotatorsettings'
This commit presents a proposal of a refactor of the rotator control with some new approaches in 'rotatorsettings.cpp' and and some (logical) changes in 'capture.cpp' and 'align.cpp'.
As I stated in this closed commit two months ago that the present implementation is not ideal in serveral aspects. To overcome these shortcomings I defined three main objects for the refactor:
-
Rotator control window
The presentation of the main parameters of rotation should be clear, understandable and illustrative in that way the user is able to recognize the state of the rotator and the camera immediately and relate to the results of a capture. -
Rotator programming
The coding of 'rotatorsettings' should be encapsulated as far as possible to prevent side effects and repeating of code fragments shattered across other places. -
The initialization of 'rotatorsettings' should handled entirely in 'manager' to prevent dangling pointers and to enable centralized management (like filtermanager).
The present commit solves the first and the second object. The third goal is not yet worked out entirely. Nevertheless the present code is working good and tested thoroughly in a productive environment (but not yet with PAA!). It is possible to test the refactor and I would be glad to receive some feedback!
Following some comments about the details:
- Rotator control window
As shown in the illustrations the user interface is very simple and there is only one parameter to set: The "Camera Position Angle". I think this is a very consistent term and easy to understand, so whe can use this well known technical term together with the camera. In the gauge this angle is presented in the same color as the FOV in the planetarium sky and in "viewing direction". This way one can relate and understand this angle intuitively. The rotator angle is presented in gray and also in viewing direction. This angle is calculated from the "Camera PA" and the "Cameras Offset Angle" which is calibrated each time a [Capture & Solve] or a [Load & Slew] is brought into action. For further clarity the rotator angle and the camera offset is displayed again in a information window together with the current pierside. (NOTE: Preliminarily for northern hemisphere only)
| pierside west | pierside east (flipped) |
|---|---|
 |
 |
- Rotator programming
The programming has now two parts: The control and display part (rotatorsettings.cpp) and the calculation part (rotatorutils.cpp). This ensures the encapsulation of the calculation routines. There are three angles the codeing has to deal with: camera position angle, rotator angle and camera offset angle. The camera position angle and offset angle have a "position angle" range whereas the rotator angle is measured in a full circle range. As said before, the user only puts the desired camera position angle and the other angles are calculated depending of the pierside. In contrast to the present solution, where the offset angle is (incorrectly!) changed after a mount flip, the rotator angle and camera offset angle now correctly remain when flipping: Only the point of reference for the rotator angle changes (e.g. from north to south if the mount flips from west to east). Thus the camera position angle flips, when the mount flips, as seen in the illustrations.
Additionaly the commit changes 'align.cpp" a little bit (see RS-LogExample.txt below). Through some replacement of code fragmemts and some small adaptions, every [Load & Slew] now does a calibration of the camera offset, sets the desired camera PA and rotates the camera if necessary and checks if the camera PA is within the acceptable range. The [Capture & Solve] and [Load & Slew] buttons are now disabled, if there is a situation in which it doesn't makes sense to activate them (like a parked mount, telescope slewing, ...).