I am reading the code trying to reverse engineer the algorithms used. Reading code sucks. I find docs on how to use it but not how it works.

Thanks!

If you can share what you're trying to do exactly then we can probably offer more help.

My long tern goal is to learn to help rather than ask for help, My short term goal is to get Ekos to control my CGX mount. I'm brand new to astrophotography so I'm learning everything at once. So part of what I see as problems may just be my bad expectations about how the system should behave. There is clearly an interaction between Ekos tabs and Celestron_aux driver. The driver depends on the alignment module and the aux code which is what actually talks to the mount.

So here is my immediate question. I can "sync" the mount to a location, say Polaris, so the mount knows its current position (encoder values) map to this particular (RA,DEC). I can save this config as the parking position and the mount will reliably slew to this spot on Park. Cool. Now with no other alignment done, I think I could use Kstars to select and 'goto' another (RA,DEC). My expectation is
1. Kstars says to the controller 'goto RA2, DEC2.
2. The controller knows it is at RA1, Dec1 so, to go to RA2 DEC2 it computes the change in RA and DEC to get to RA2,DEC2.
3. The controller says to the mount, thru aux command, to rotate RA by delta-RA and DEC by delta-DEC.
4. The mount knows how many encoder steps per delta-angle so it happily applies the delta-RA and delta-DEC.
Of course the position is close, but not the real location because the single synced position is only roughly aligned manually during setup.

The observed behavior when I try this is mixed. Some times the motion is reasonable but maybe East-West is reversed? Other times, I abort the motions because the scope is going to hit the mount. So which components know what when? The alignment module is keeping track of encoder values, so maybe the mount isn't as smart as I expect and the aux command to the mount is goto RA-endoder value and DEC-encoder instead of apply a delta-angle. Reading the code, or docs (!) can educate my expectations. Or you can spoon feed me! I expect you are going to tell me I have to do the entire alignment procedure first, but why?

My second immediate question is why can't I use the manual slew controls to move the mount. What does a buttons labeled N,S,E,W mean when I have a mount that moves in RA,DEC? Using the buttons doesn't move in a way that makes sense.


Thanks!

So looking at celestronaux.cpp,

<code>bool CelestronAUX::slewTo(INDI_HO_AXIS axis, uint32_t steps, bool fast)
{
// Stop first.
trackByRate(axis, 0);
AUXCommand command(fast ? MC_GOTO_FAST : MC_GOTO_SLOW, APP, axis == AXIS_AZ ? AZM : ALT);
m_AxisStatus[axis] = SLEWING;
command.setData(steps, 3);
sendAUXCommand(command);
readAUXResponse(command);
return true;
};</code>
the aux command really is in 'steps'. So the hand-controller or indi-driver really does have to be smarter than the mount. The mount does not seem to know anything beyond encoder value.
So, my revised expectation is
1. Kstars says to the controller 'goto RA2, DEC2'.
2. The controller knows it is at RA1, DEC1 so, to go to RA2 DEC2 it computes the delta-RA and delta-DEC to get to RA2,DEC2.
3. The controller knows the mount's, encoder-steps per dergree so it commands the mount, thru aux command, to rotate RA by delta-RA-encoder-steps and delta-DEC-encoder steps.

Why does this method use INDI_HO_AXIS and not INDI_EQ_AXIS?

Thank you for investigating this David.

1. Never sync to Polaris or any place very close to it. The math breaks down near the poles.
2. INDI_HO_AXIS is because the controller talks in terms in AZM and ALT axis, it's the same thing.

Assuming you start in the home position, start by slewing to a nearby star about 20 degrees away, Then you can plate-solve to SYNC the mount to this location. You can find more information on how the alignment system works in this INDI Alignment Subsystem documentation. However, due to issues in the default implementation for the alignment subsystem (and apparently nobody understand the details as the original author is no longer active), I added the Nearest Algorithm plugin and set it as default. This does not need any fancy math for the Sky <---> Mount transformations with the built-in and SVD math plugins, it just calculates offsets and apply them.

At any rate, it would be great you can help revive the alignment subsystems in INDI! Let me know if you have any specific questions.

Hi Jasem,
You say "start by slewing to a nearby star about 20 degrees away". I don't know how to do that. I assume that one would use the buttons on the virtual hand controller ( I do not have the physical hand controller connected) but this results in wild results. There is a comment in the code indicating that coordinate handling is not complete for these controls. The goto functions also give strange motions apparently because the driver does not have enough alignment info yet. I'm interested in helping but I have a big learning curve to climb.

It is a big loss if the author of the Alignment module is not active now. I would love more details about the implementation. Reading and learning from code makes a hard task much harder.

You can issue a GOTO directly from Sky Map. I have Advanced VX that I'm connected to it via SkyFi and it works flawlessly. I command it to slew to a nearby star (e.g. Kocab) and it roughly ends up in that position. Subsequent plate-solves would improve its position. The documentation for the Alignment subsystem is already in the link I sent you earlier. Make sure time + location information is correct as that might explain the issue of odd GOTOs.