No, no rotator in my case.
I remember flipping the image of the first post in H and V in the integrated fits viewer to match the sky map, which is equivalent to a 180º rotation (IIRC) but now, taking a look at the fits file with an external viewer I just have to flip H (exchange left to right) to match the rotation of the sky map. This is weird.
Anyway, after flipping in H, I've been visually matching the two images in gimp and the difference in rotation is about 65 degrees between them.
Here it is (attached in a tar.bz2). Note that this is not exactly the correspondig fits of the previous images (as I've shot it again), but it's very very close.
Here is my position (it's approximate, as this is a public forum, but it should be close enough to do calculations):
It seems that the frame outline that ekos paints on kstars sky map when you solve an image using astrometry has wrong rotation.
This is the fits image, flipped H and V (to match sky map) because I use a newtonian.
Nevermind, it resolved itself when I started from scratch, completely removing the build directories for indi and kstars and starting again with cmake, make, make install. Whatever the problem was, it went away with the old builds.
Now I have a second system with exactly the same problem and I hope to apply the same "solution".
This is a regular PC running Debian testing (buster), it's not a raspberry pi.
Yes, i use cmake with -DCMAKE_INSTALL_PREFIX=/usr both for libindi and kstars.
When compiling and installing libindi everythings seems ok to me:
(...) [ 99%] Built target indi_paramount_telescope [100%] Built target indi_gemini_focus Install the project... -- Install configuration: "Debug" -- Installing: /usr/bin/indiserver -- Installing: /usr/lib/x86_64-linux-gnu/libindiclient.a -- Installing: /usr/include/libindi/baseclient.h -- Installing: /usr/lib/x86_64-linux-gnu/libindidriver.a -- Installing: /usr/lib/x86_64-linux-gnu/libindidriver.so.1.5.0 -- Installing: /usr/lib/x86_64-linux-gnu/libindidriver.so.1 -- Installing: /usr/lib/x86_64-linux-gnu/libindidriver.so -- Installing: /usr/bin/indi_imager_agent -- Set runtime path of "/usr/bin/indi_imager_agent" to "" (...)
xxx@yyy:~$ ls -l /usr/lib/x86_64-linux-gnu/libindidriver.so.1.5.0 /usr/lib/x86_64-linux-gnu/libindiclient.a -rw-r--r-- 1 root root 5467400 oct 12 18:18 /usr/lib/x86_64-linux-gnu/libindidriver.so.1.5.0 -rw-r--r-- 1 root root 1310550 oct 12 18:18 /usr/lib/x86_64-linux-gnu/libindiclient.a
(...) -- Checking for module 'libindi' -- Found libindi, version 1.5.0 -- Found INDI: , /usr/include/libindi -- Found INDI Client Library: /usr/lib/x86_64-linux-gnu/libindiclient.a -- Found INDI: /usr/lib/x86_64-linux-gnu/libindiclient.a, /usr/include/libindi (...)
xxx@yyy:~$ ldd /usr/bin/kstars|grep -i indi xxx@yyy:~$
This is weird. I compiled the last version of kstars from git. Ekos and indi are "gone": there are no icons for them. I thought something funny was going on with the toolbar, but if I edit it, there are no actions available (for ekos or indi). Also, in the menus, I can't find any entry for them.
Otherwise kstars runs fine.
Previously, I had already compiled the last version of libindi from git.
Obviously I must be doing something wrong because I seem to be the only one who has this bug. I can't find any other reference.
Thank you very much.
Tested, and works great. Many thanks!
I've done a git pull and a clean compile just to be sure. The bug it's still there.
However, to trigger it, it seems that you have to first complete the process to the east, and only then the 2nd rotations to the west will fail on successive attempts.
In the Polar Alignment Assistant (beta), if "auto" and "west" are selected, 2nd rotation is east insted.
1.- Start ekos. Telescope and CCD simulators are ok (plus GSC). Go to PA Assistant.
2.- Click "Start" then "Capture".
3.- Select "West", check "Auto Mode" and click "Rotate".
4.- The mount rotates west. A capture is made and solved.
5.- The UI now shows "east" selected instead of "west". The rotation is made east instead.
6.- The process completes but the result is wrong.
Maybe the radio button state in the UI is not saved between rotations.
Is posting bug here in the forums ok? What's the preferred method? Bugtracker or something?
Hi. I may be wrong here, but if you introduce a negative angle in the Mosaic job creator UI, in the "rotation" field under "1. Equipment", it is handled as positive, i. e. -33 is handled as +33.
The solver reports my rotation as -22 but this (see attachment 1) is what I got after running the mosaic job (quick composition with ds9 using wcs data from the resulting fits files). As you can see, the rotation of the individual frames is different from the whole mosaic. I am guessing that the problem comes from the mosaic job creator ignoring the negative angle.
Also, a couple of minor things.
- On the right, the display of the mosaic and the objects is a bit buggy. Ofter, it leaves out parts of the mosaic, the object, etc (see attachment 2).
- The "tab" order of the "rotation" field is wrong, it should come after "Pixel size - H" but comes after "overlap" in "FOV".