×

INDI Library v1.9.2 Released (14 Sep 2021)

Bimonthly Stable INDI Library release introduces new drivers and fixes for existing ones.

Re:New Polar Alignment Scheme and Features

  • Posts: 246
  • Thank you received: 45
Hi Jasem
I was using the manual slew option. The spin box had whatever was the default but obviously is not used for manual slewing.
With the near pole method it asked me to slew 89,260.7 degrees. At first I thought it was using European decimal notation till I saw the ".7" .
Locale is English, specifically LANG=C.UTF-8
-- Ken
RPi3 Ubuntu Server 20.04, Windows 10 AMD64, AAEON UP Core Ubuntu Desktop 20.04
Avalon M-Uno, EQ6 Pro, Atik420, ASI1600MM-C, ASI120MM-S, DBK21AU04, ZWO EFW, Optec TCFSi
Vixen R150S, GSO RC8, ST80
8 months 1 day ago #66222
The topic has been locked.
  • Posts: 657
  • Thank you received: 308
FYI, I submitted a fix to the Polar Alignment Assistant (PAA) for an issue related to the rendering of the correction triangle. This fix is detailed in  invent.kde.org/education/kstars/-/merge_requests/198 and has already been merged into the KStars source code, though as I write this is not yet in any nightlies. This will likely fix the triangle-rendering issue reported by @rbarberac and also by Jasem. I'm hoping my fix from last week solved the east/west issue reported by @rugbyrene (and seconded by Jasem). Assuming these are indeed fixed, I'm not aware of other issues with the new PAA code (Jasem is looking at the "manual issue" brought up by @kengs).

While I was testing that fix, I ran polar alignment using my telescope 18 times over the course of an hour in several different ways:
  • rotating East, starting by pointing near the northern pole,
  • rotating West, starting by pointing near the northern pole,
  • rotating East, starting East of the meridian at about DEC=60
  • rotating West, starting West of the meridian at about DEC=60
All my tests went well.

I have a couple things to mention, not directly related to my changes:
  • I once got a "Solver Failed" during PAA, and when that happens, the system doesn't gracefully retry. You need to stop the PAA process, and restart it. I'd like to correct that, but it may not be right away, as I want to make sure this system works, and this state machine can be tricky.
  • I noticed that my system started up with 8x mount speed. Perhaps that was due to some debugging I was doing previously, but if you notice the slew going very very slowly, check that menu item on the polar-alignment tab.
  • I removed the "flip the correction vector" option. I don't think it makes sense any longer, and would confuse the interface. If you feel you need to reverse the correction vector, please contact me and I will try and fix the underlying issue.
Please let me know if you see any further issues.
Orion Atlas Pro, William Optics ZS105, Moonlight V2 focuser
ZWO ASI1600, OAG & Filterwheel, Astronomik Filters, QHY 5L-IIm guidecam.
KStars/Ekos/Indi on RPi4 w/SSD
Ekos Projects: Terrain Backgrounds, Polar Alignment, Analyze, Linear Focuser, SEP MultiStar & GPG Guiding, FITS autostretch.
The following user(s) said Thank You: rbarberac
8 months 9 hours ago #66253
The topic has been locked.
  • Posts: 777
  • Thank you received: 101
I did have some clear sky down at sealevel last night, so I decided I have a try using the new PA with my Star Adventurer and the ASI183MC with an Canon 135mm lens.
The sky view from my terrace is hugely limited, basically only ENE to SSW and up to zenith :ohmy: But enough for testing PA.

I had to use the telescope simulator, as the mount doesn't have any connection to the computer, and switch off position hinting for the solver. Amazingly, even with only image scale limits it was blazing fast, solving in a second or so. But without a compass or view to polaris, my initial orientation was largely off.
Without mount control/info I had to use the 'manual slew' option, and hand-turn the SA to various positions.
As it was the first time using refresh/move it took me three tries before I touched the Alt/Az knobs, and re-did the measurement a few times with different pointing positions. The nice outcome was that the determined PAE was quite consistent - though at 17 degrees.... It took me several additional rounds of measure-align, including repositioning the tripod because I hit the alignment limits of the mount. I eventually got the error down to 15'. Trying better was somewhat futile, due to the (in)stability of the photo tripod I used. But all in all a very pleasant experience :cheer:

One thing I noticed was that - especially for the large error - the movement direction of the star when tuning the mount orientation did not really match the guide lines plotted. So I wondered if there might be still some (small) error in the coordinate conversion that shows up at larger offsets. However, while writing this, I realized that I had used the observation coordinates of the observatory, some 30km away from here. Would that affect things? In principle I'd say no, as you can PA without knowing where you are?

So if weather cooperates I'll try that again tonight, with proper location and the new code. Because of course as soon as I had finished PA last night the clouds rolled over again... :sick:
I didn't have debug on, so I assume the logfile isn't too helpful..

Cheers,

Pit
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
8 months 44 minutes ago #66270
The topic has been locked.
  • Posts: 657
  • Thank you received: 308
Pit,

Thanks for the challenging test!

Re the lines not matching the star movement, my guess is this: You have a huge error, 17 degrees. I implemented drawing a straight line in image space (2D projection of the actual 3D curve) between the start point and the solution point. This projection is likely fine for most use cases, but when your error is that large, the projection probably doesn't match the geodesic as well as you'd like. You're the expert in this kind of math, so let me know if you disagree.

I'd expect that this isn't a problem as (a) it led to the solution iteratively anyway, and (b) with a compass and an astro setup, most folks should start much closer to the solution, even with that poor a view of the night sky.

If there was good reason, I could switch from a single projected line, to a series of line segments that better match the geodesic, but I think that would be overkill for almost all use cases. Again, let me know what you think.

Hy
Orion Atlas Pro, William Optics ZS105, Moonlight V2 focuser
ZWO ASI1600, OAG & Filterwheel, Astronomik Filters, QHY 5L-IIm guidecam.
KStars/Ekos/Indi on RPi4 w/SSD
Ekos Projects: Terrain Backgrounds, Polar Alignment, Analyze, Linear Focuser, SEP MultiStar & GPG Guiding, FITS autostretch.
7 months 4 weeks ago #66287
The topic has been locked.
  • Posts: 117
  • Thank you received: 1
Hy,

I managed to get out last night and test out the PA routine. I was able to really dial in my PA like never before so thank you! And with GPG enabled I got sub-arc second guiding. I’ve never had that before.

I do have an enhancement suggestion. Would it be possible for the display to auto zoom once you get within a certain pre-defined PA error? It would work similar to what is implemented in the iOptron iPolar software, where as you are making adjustments it will present a zoomed in sub-window which allows you to make even finer adjustments. I realise we can manually zoom but it requires us to stop making adjustments, zoom in, pan around to find the adjustment vectors and return to making adjustment.

It’s a little thing that would make the process easier.

Rene
Sky-Watcher AZ-EQ6
Sky-Watcher Esprit 100
Sky-Watcher EvoGuide 50 (guide-scope)
ZWO ASI294MC Pro
ZWO ASI120MM mini (guide cam)
Pegasus PPB
Pegasus Focus Cube v2
7 months 4 weeks ago #66372
The topic has been locked.
  • Posts: 777
  • Thank you received: 101
Sorry for the silence. No news here, the clouds are back, and the road to up above the clouds is closed due to landslides :ohmy:

Your explanation of the deviation seems very sound! I agree that the test was really a challenge, especially as my compass is in the observatory, and not here :P . But such extreme settings often help to pinpoint problems.
I absolutely agree that it's not really needed to change the plotting. If one gets such large corrections an iteration is needed anyhow, and that one will have better matched movement paths. So all fine for now. I'll pester you again once I find more silly ideas ;)
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
7 months 4 weeks ago #66374
The topic has been locked.
  • Posts: 657
  • Thank you received: 308
While testing some new polar alignment code this evening, I came across an interesting screenshot I wanted to share.

I positioned the telescope to point just North of the Equator, and just West of the Meridian (and I'm in the Northern Hemisphere).
I ran polar alignment with two 30-degree slews going West. I had intentionally messed up my polar alignment by about 1/2 degree.
Looking at the log, spot of the 3rd PAA image is azimuth 253.934 altitude 23.5716.




What I wanted to point out, is that the correction triangle is telling the user to use the altitude knob to move the star along the yellow line seemingly AWAY from the ultimate target. When the user reaches the end of the yellow line, then adjusting the azimuth knob would bring the star along the green line to the target. It turns out that there are spots in the sky where azimuth and altitude corrections at the pole map to surprising directions like this. This is the reason I originally came up with the idea of introducing a correction triangle.

In fact, I followed the directions given, and the resulting correction worked fine. I verified this by re-checking polar alignment at the pole.
Hy
Orion Atlas Pro, William Optics ZS105, Moonlight V2 focuser
ZWO ASI1600, OAG & Filterwheel, Astronomik Filters, QHY 5L-IIm guidecam.
KStars/Ekos/Indi on RPi4 w/SSD
Ekos Projects: Terrain Backgrounds, Polar Alignment, Analyze, Linear Focuser, SEP MultiStar & GPG Guiding, FITS autostretch.
The following user(s) said Thank You: Jasem Mutlaq, Ken Self, Jim, Brian, Peter Sütterlin
7 months 3 weeks ago #66502
Attachments:
The topic has been locked.
Bravo Hy! Great work on the PAA tool! I wonder if this could be remotely related to why the direction for the correction vector was reversed for some users before you introduced the triangle?
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
7 months 3 weeks ago #66512
The topic has been locked.
  • Posts: 42
  • Thank you received: 5
Just a side question. Is the alignment done on the real or refracted pole? I ask because last night I ended up with a really good polar alignment (19" error in azimuth and 17" in altitude), I saw no DEC drift, phd Guiding Assistant reported 0-0.1' of polar alignment error, but I still saw about 1"/min drift in RA when pointing near the meridian and at 40-45* altitude. To my understanding it may (or may not?) be due to refractive effects (I checked with some simulators and the residual alignment error alone would not account for that drift). Any suggestion on that? Thanks
7 months 3 weeks ago #66648
The topic has been locked.
  • Posts: 777
  • Thank you received: 101
Difficult question, especially for the new PA scheme.
If you align 'the old way' looking at the pole, you'll align to the refracted pole (AFAIK there's no code in to compensate refraction). Depending on your latitude that might not be much difference anyhow, but it could explain why you get good alignment but still see drift at meridian/zenith.
In principle, if you use the new code with low declination locations, like drift align it should align to the real (unrefracted) pole and give you no drift at meridian/zenith, but a larger error if you verify the PA at the pole, and possibly lead to image rotation when imaging at the pole.

At least, that's (my) theory about it. I intend to verify it, but so far had no chance to do it :pinch:
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
7 months 3 weeks ago #66657
The topic has been locked.
  • Posts: 246
  • Thank you received: 45
Good article on the subject here: canburytech.net/DriftAlign/DriftAlign_3.html
-- Ken
RPi3 Ubuntu Server 20.04, Windows 10 AMD64, AAEON UP Core Ubuntu Desktop 20.04
Avalon M-Uno, EQ6 Pro, Atik420, ASI1600MM-C, ASI120MM-S, DBK21AU04, ZWO EFW, Optec TCFSi
Vixen R150S, GSO RC8, ST80
7 months 3 weeks ago #66659
The topic has been locked.
  • Posts: 42
  • Thank you received: 5
Yes, it’s from that article that my question arise. I also used the attached spreadsheet to check the drift induced by alignment error vs refraction.
7 months 3 weeks ago #66660
The topic has been locked.
Time to create page: 1.101 seconds