Thanks for your workaround. I recently fixed up all the precession issues in the Ctrl + M manual set position. It doesn't do nutation correctly if I remember right, so there may still be some small amount of error which should be totally negligible for most amateur use-cases. If you find any precession issues here, please let me know.
I'm not sure where you reported the Flag bug, could you point me to it please? I'll put it on the ever-expanding list of issues on the repo.
Read More...
I believe the wizard is broken, it's not your misinterpretation. See invent.kde.org/education/kstars/-/issues/173
We recently upgraded our DSO storage and retrieval code to work well with the space-partitioning data structure we use. This enables us to do a lot of other cool things (like enable a database of 1 million galaxies), but I suspect it has broken many things; I imagine this is one of the things that's not working because of this change. Please add your feedback to the issue linked above so we can make sure to take it into account when we fix it.
Read More...
I believe this is intentionally designed to limit the number of queries on the database, but I can't remember the rationale for it -- perhaps Valentin or Jasem know.
Read More...
Just in case anyone else encounters this and can rollback to a different version of INDI unlike OP, rolling back to v1.8.6 (both on indi and indi-3rdparty) worked for me. pyindi-client was built from master.
Read More...
I hit the same issue today on ARM (Raspberry Pi 4B+). My best guess is that there has been a change in INDI that breaks PyINDI. For example, I also noticed that `pyindi-client` `master` does not build against `indi` `master` right now. I had to roll back `indi` to the most recent tag to make it build. I will try rolling back INDI further and let you know if I succeed.
Read More...
I managed to generate what seems like a much more useful backtrace by attaching
gdbindi_asi_ccd#0 INDI::StreamManager::setPixelFormat (this=0x0, pixelFormat=pixelFormat@entry=INDI_BAYER_RGGB, pixelDepth=pixelDepth@entry=8 '\b')
at /home/akarsh/devel/kde-devel/src/indi/libs/stream/streammanager.cpp:389
#1 0x0000555d7450b11d in ASICCD::updateRecorderFormat (this=this@entry=0x555d75114158) at /usr/include/c++/10.2.0/bits/unique_ptr.h:173
#2 0x0000555d745104f9 in ASICCD::setupParams (this=this@entry=0x555d75114158) at /home/akarsh/devel/kde-devel/src/indi-3rdparty/indi-asi/asi_ccd.cpp:638
#3 0x0000555d745119f2 in ASICCD::updateProperties (this=0x555d75114158) at /home/akarsh/devel/kde-devel/src/indi-3rdparty/indi-asi/asi_ccd.cpp:300
#4 0x00007f3a9934b71e in INDI::DefaultDevice::ISNewSwitch (this=this@entry=0x555d75114158, dev=dev@entry=0x555d7510dc50 "ZWO CCD ASI290MC-Cool",
name=name@entry=0x555d75107f80 "CONNECTION", states=states@entry=0x555d75111e00, names=names@entry=0x555d75104de0, n=n@entry=1)
at /home/akarsh/devel/kde-devel/src/indi/libs/indibase/defaultdevice.cpp:395
#5 0x00007f3a99354361 in INDI::CCD::ISNewSwitch (this=this@entry=0x555d75114158, dev=dev@entry=0x555d7510dc50 "ZWO CCD ASI290MC-Cool",
name=name@entry=0x555d75107f80 "CONNECTION", states=states@entry=0x555d75111e00, names=names@entry=0x555d75104de0, n=n@entry=1)
at /home/akarsh/devel/kde-devel/src/indi/libs/indibase/indiccd.cpp:1609
#6 0x0000555d7451216f in ASICCD::ISNewSwitch (this=0x555d75114158, dev=0x555d7510dc50 "ZWO CCD ASI290MC-Cool", name=0x555d75107f80 "CONNECTION", states=0x555d75111e00,
names=0x555d75104de0, n=1) at /home/akarsh/devel/kde-devel/src/indi-3rdparty/indi-asi/asi_ccd.cpp:809
#7 0x0000555d7451100d in operator() (camera=..., __closure=<synthetic pointer>) at /home/akarsh/devel/kde-devel/src/indi-3rdparty/indi-asi/asi_ccd.cpp:140
#8 for_each_camera<ISNewSwitch(char const*, char const*, ISState*, char**, int)::<lambda(ASICCD&)> > (f=..., dev=0x555d7510dc50 "ZWO CCD ASI290MC-Cool")
at /home/akarsh/devel/kde-devel/src/indi-3rdparty/indi-asi/asi_ccd.cpp:123
#9 ISNewSwitch (dev=0x555d7510dc50 "ZWO CCD ASI290MC-Cool", name=0x555d75107f80 "CONNECTION", states=0x555d75111e00, names=0x555d75104de0, num=num@entry=1)
at /home/akarsh/devel/kde-devel/src/indi-3rdparty/indi-asi/asi_ccd.cpp:139
#10 0x00007f3a99332105 in dispatch (root=root@entry=0x555d75106a90, msg=msg@entry=0x7ffc13d90540 "") at /home/akarsh/devel/kde-devel/src/indi/indidriver.c:1119
#11 0x00007f3a993328e3 in clientMsgCB (fd=<optimized out>, arg=<optimized out>) at /home/akarsh/devel/kde-devel/src/indi/indidriver.c:894
#12 0x00007f3a99334648 in callCallback (rfdp=0x7ffc13d90db0) at /home/akarsh/devel/kde-devel/src/indi/eventloop.c:347
#13 oneLoop () at /home/akarsh/devel/kde-devel/src/indi/eventloop.c:439
#14 0x00007f3a9933483d in eventLoop () at /home/akarsh/devel/kde-devel/src/indi/eventloop.c:106
#15 0x00007f3a9932cd79 in main (ac=<optimized out>, av=0x7ffc13d90fa8) at /home/akarsh/devel/kde-devel/src/indi/indidrivermain.c:98
#16 0x00007f3a97fc6152 in __libc_start_main () from /usr/lib/libc.so.6
#17 0x0000555d7450a7fe in _start ()Read More...
Hi
I apologize if my question is inane, because I'm rather new to INDI and hardware even though I've worked on KStars for long.
I have an old ZWO ASI 290MC-Cool camera (which is now discontinued), and it was working fine until I had to make a system update during which I also updated `libindi` and `indi-3rdparty` drivers to `master` and built them from source. With this version of INDI, a previously working PyINDI client application exits with the following error message:
Dispatch command error(-1): INDI: <setNumberVector> bogus state (null) for ERATURE
<setNumberVector device="ASI290MC-Cool" name="ERATURE" state="(null)" timeout="0" timestamp="2021-01-09T10:05:42"/>
RecursionError: maximum recursion depth exceeded while calling a Python objectAnd the corresponding output of the `indiserver indi_asi_ccd` command is:
2021-01-09T10:05:37: startup: indiserver indi_asi_ccd
2021-01-09T10:05:42: Driver indi_asi_ccd: Impossible IPState 455801016
2021-01-09T10:05:42: Driver indi_asi_ccd: stderr EOF
<delProperty device="ZWO CCD ASI290MC-Cool"/>
<delProperty device="ASI290MC-Cool"/>
Child process 4121986 died
2021-01-09T10:05:42: Driver indi_asi_ccd: restart #1
2021-01-09T10:05:42: Client 0: read: Connection reset by peerIf I try to fire up KStars (recent git master) and Ekos and try to connect to the running indiserver on localhost, KStars segfaults with the following backtrace (as produced by the KDE Crash Handler):
Application: KStars (kstars), signal: Aborted
[KCrash Handler]
#4 0x00007f1041a7b615 in raise () from /usr/lib/libc.so.6
#5 0x00007f1041a64862 in abort () from /usr/lib/libc.so.6
#6 0x00007f1041dff86a in __gnu_cxx::__verbose_terminate_handler () at /build/gcc/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#7 0x00007f1041e0bd9a in __cxxabiv1::__terminate (handler=<optimized out>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:48
#8 0x00007f1041e0be07 in std::terminate () at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:58
#9 0x00007f1041e0c0ae in __cxxabiv1::__cxa_throw (obj=obj@entry=0x55a8c6b28b10, tinfo=0x7f1041f38208 <typeinfo for std::logic_error>, dest=0x7f1041e21e20 <std::logic_error::~logic_error()>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:95
#10 0x00007f1041e02445 in std::__throw_logic_error (__s=__s@entry=0x55a8c0e35950 "basic_string::_M_construct null not valid") at /build/gcc/src/gcc/libstdc++-v3/src/c++11/functexcept.cc:66
#11 0x000055a8c0c2b6e8 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*> (this=this@entry=0x7ffd1aa051f0, __beg=__beg@entry=0x0, __end=__end@entry=0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>) at /usr/include/c++/10.2.0/bits/basic_string.tcc:212
#12 0x000055a8c0c2b421 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*> (__end=0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>, __beg=0x0, this=0x7ffd1aa051f0) at /usr/include/c++/10.2.0/bits/basic_string.h:247
#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*> (__end=0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>, __beg=0x0, this=0x7ffd1aa051f0) at /usr/include/c++/10.2.0/bits/basic_string.h:266
#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (__a=..., __s=0x0, this=0x7ffd1aa051f0) at /usr/include/c++/10.2.0/bits/basic_string.h:527
#15 INDI::BaseDevice::messageQueue[abi:cxx11](int) const (this=<optimized out>, index=<optimized out>) at /home/akarsh/devel/kde-devel/src/indi/libs/indibase/basedevice.cpp:1233
#16 0x000055a8c069706d in INDI_D::updateMessageLog (this=0x55a8c5605b50, idv=0x7f0ffc002920, messageID=<optimized out>) at /home/akarsh/devel/kde-devel/src/kstars/kstars/indi/indidevice.cpp:310
#17 0x00007f104283c582 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#18 0x00007f10432d9752 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#19 0x00007f104280fa7a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#20 0x00007f1042812573 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#21 0x00007f10428690a4 in ?? () from /usr/lib/libQt5Core.so.5
#22 0x00007f10416578f4 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#23 0x00007f10416ab821 in ?? () from /usr/lib/libglib-2.0.so.0
#24 0x00007f1041656121 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#25 0x00007f10428686e1 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#26 0x00007f104280e3fc in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#27 0x00007f1042816894 in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#28 0x000055a8c046d502 in main (argc=<optimized out>, argv=<optimized out>) at /home/akarsh/devel/kde-devel/src/kstars/kstars/main.cpp:349
[Inferior 1 (process 4125822) detached]and the corresponding output of `indiserver indi_asi_ccd` command is:
2021-01-09T10:16:37: startup: indiserver indi_asi_ccd
2021-01-09T10:16:56: Driver indi_asi_ccd: Impossible IPState -353449800
2021-01-09T10:16:56: Driver indi_asi_ccd: stderr EOF
<delProperty device="ZWO CCD ASI290MC-Cool"/>
<delProperty device="ASI290MC-Cool"/>
2021-01-09T10:16:56: Driver indi_asi_ccd: restart #1
Child process 4125880 died
2021-01-09T10:16:56: Driver indi_asi_ccd: indi_asi_ccd dispatch error: Property WCS_CONTROL is not defined in ZWO CCD ASI290MC-Cool.Can anyone advise me on how to resolve this issue? It appears that we have some regression in the `indi-3rdparty` ASI drivers that may not support this camera?
Thanks for your help!
Read More...
Yes, the DBus interface exposes a good chunk of functionality -- and if something is not there, let us know, it isn't too difficult to add a DBus wrapper to any method existing in KStars.
There is an open-source speech recognition engine called CMU Sphinx, and there's also KDE's speech recognition efforts named Simon. I don't know the state of either project, but I presume they are still not using Deep Neural Networks, and it's very unlikely that they are as good as Amazon's or Google's APIs due to the sheer amount of data they have. Yet, they might actually work pretty well for a small list of known commands, and that was the intention for Simon at least as far as I know.
Regards
Akarsh
Read More...
Hi
Unfortunately, I don't have time to work on this today -- I'm about to leave for an astronomy trip, so there's all the packing and stuff. If I do have time to work on it during the day over the next few days, I will. But if someone else wants to look into it sooner than I can, please do so.
Workaround: Avoid altaz grid and horizontal coordinates.
Some developer information: While I believe that the transition to CachingDms could be responsible for this, I haven't found any immediate evidence. The problem seems to be:
1. A line that returns a Vector2f(0, 0) in Projector::toScreenVec instead of failing an assert and crashing (added in Android transition efforts)
2. A call to NoPrecessIndex::JITUpdate() seems to mangle the azimuth. I guess this is the effect of calling HorizontalToEquatorial and then EquatorialToHorizontal when altitude = 90.0 (i.e. when alt = 90, azimuth is indeterminate).
3. It should be okay to set the azimuth to something finite just so computations don't turn out to become NaN all the time -- but I would refrain from doing it in toScreenVec, since it is called a million times per draw under certain settings.
Regards
Akarsh
Read More...