Tried the polar alignment routine for the first time last night, had a thought / observation and maybe a bug report.

When you get to the correction stage, with the picture showing the correction vector, it should be mathematically possible to translate the picture to a true alt-az picture. And it would be helpful to give correct altitude / azimuth directions, e.g. 20 arcmin up + 15 arcmin left. SharpCap attempts this, but doesn't translate the picture, their up means up on the picture, which the user has to determine by trial and error how that relates to actual mount movement. In the EKOS case, you have performed three solutions and moved the mount in a controlled direction, by then you should know the camera angle in relation to absolute altitude / azimuth. Proper orientation of the looping picture to the adjustments you have to make, and real time numeric feedback on the direction and magnitude of the required adjustments would be a big help.

Also, I'll have to try to duplicate this, but the first time I made it through the routine I had it in Auto and the mount moved West - West. So here I am at 60° west of the pole and made my adjustments. I thought I'd set it to go East and double check. It moved 30° East, solved, and then moved 30° West - back where I started from on the second round. I had to start teardown at that point I will attempt to repeat tonight.

For 1st issue, it's possible to break the RA/DE into AZ/ALT components, but to give real-time numeric feedback is not possible because Ekos wouldn't know by how much you made the adjustments unless it solves the image again which would make this whole adjustment phase crawl. I don't know what is up and right and left when I'm in the observatory, I just adjust the knobs until the star is in the crosshair and that's it.

For the 2nd issue, I can confirm the bug and I fixed it in GIT now.

Thanks for looking at the East-West thing, but take a look at SharpCap. It has real time updating correction vector, numeric error feedback and auto star selection. They hard coded the star solutions near the pole and it solves in under a second.

I tried to use this last night, and I could get to where the mount is slewed the first time and KStars just crashes right after the plate solve. Attached is a logfile from when the issue occurred.

Log file appears OK. The next release of KStars should hopefully have better debugging capabilities (within a week or two). For time time being, please run KStars in gdb so that in case of a crash, you can get the backtrace.
Then run KStars normally, if there is a crash, go back to the console window and type bt to get the backtrace which should help diagnose the problem.

Will do Jasem.

Got it

Thread 13 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffae7fc700 (LWP 15270)]
0x00007ffff2946eb3 in wcsp2s () from /usr/lib/x86_64-linux-gnu/libwcs.so.5
(gdb) bt
#0 0x00007ffff2946eb3 in wcsp2s () from /usr/lib/x86_64-linux-gnu/libwcs.so.5
#1 0x000000000062edd4 in FITSData::loadWCS (this=0x4d51730)
at /build/kstars-bleeding-1NUe18/kstars-bleeding-17.04+201703051022~ubuntu16.04.1/kstars/fitsviewer/fitsdata.cpp:2145
#2 0x00000000006621be in QtConcurrent::StoredMemberFunctionPointerCall0<bool, FITSData>::runFunctor (this=0x4f4b280)
at /usr/include/x86_64-linux-gnu/qt5/QtConcurrent/qtconcurrentstoredfunctioncall.h:183
#3 0x00000000004b4cfd in QtConcurrent::RunFunctionTask<bool>::run (
this=0x4f4b280)
at /usr/include/x86_64-linux-gnu/qt5/QtConcurrent/qtconcurrentrunbase.h:102
#4 0x00007ffff327d2d3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5 0x00007ffff32807be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6 0x00007ffff49bf6ba in start_thread ()
from /lib/x86_64-linux-gnu/libpthread.so.0
#7 0x00007ffff1adc82d in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)

Tried a second time and pretty much got the same error:

Thread 13 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb67fc700 (LWP 17314)]
0x000000000062ed65 in FITSData::loadWCS (this=0x40aaf60)
at /build/kstars-bleeding-1NUe18/kstars-bleeding-17.04+201703051022~ubuntu16.04.1/kstars/fitsviewer/fitsdata.cpp:2151
2151 /build/kstars-bleeding-1NUe18/kstars-bleeding-17.04+201703051022~ubuntu16.04.1/kstars/fitsviewer/fitsdata.cpp: No such file or directory.
(gdb) bt
#0 0x000000000062ed65 in FITSData::loadWCS (this=0x40aaf60)
at /build/kstars-bleeding-1NUe18/kstars-bleeding-17.04+201703051022~ubuntu16.04.1/kstars/fitsviewer/fitsdata.cpp:2151
#1 0x00000000006621be in QtConcurrent::StoredMemberFunctionPointerCall0<bool, FITSData>::runFunctor (this=0x405ab70)
at /usr/include/x86_64-linux-gnu/qt5/QtConcurrent/qtconcurrentstoredfunctioncall.h:183
#2 0x00000000004b4cfd in QtConcurrent::RunFunctionTask<bool>::run (this=0x405ab70) at /usr/include/x86_64-linux-gnu/qt5/QtConcurrent/qtconcurrentrunbase.h:102
#3 0x00007ffff327d2d3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4 0x00007ffff32807be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5 0x00007ffff49bf6ba in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007ffff1adc82d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Ok I have _some_ idea, but still unsure. Can you please accept gmail chat invitation or come to KStars channel on Matrix? riot.im/app/#/room/#kstars:matrix.org

Sure I can join the chat. What time is best?

I'll be there in about 15-20 mins from this post

In Automatic mode it was still reversing directions last night.

libindi-dev (hope that's the correct package) version 1.4.1+r3006~201703222147~ubuntu16.04.1

And is there an option to make the correction vector screen larger?

Thanks,

Dana

KStars 2.7.6 was just release this morning! Please update KStars if you're using it from PPA.

Yes, you can click the "Full Screen" button to get full screen view in the Align Module.