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...

Akarsh replied to the topic 'Problem importing PyIndi' in the forum. 1 year ago

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...

Akarsh replied to the topic 'Problem importing PyIndi' in the forum. 1 year ago

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

gdb
to the
indi_asi_ccd
process. The same backtrace was reproducible twice while trying to connect to the camera via PyINDI client:
#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 object

And 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 peer

If 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...

Akarsh replied to the topic 'Voice Control of KSTARS?' in the forum. 6 years ago

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...

Akarsh replied to the topic 'Ekos on Mac OS X ?' in the forum. 6 years ago

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...

Akarsh replied to the topic 'Ekos on Mac OS X ?' in the forum. 6 years ago

The CachingDms error is mostly a note for us developers. It has no real consequence on the functioning of KStars. It's just a warning that some trigonometric functions are being pointlessly recomputed, which is expensive if it is happening in the innermost loop with many stars, but is a non-issue otherwise. I've made sure that it doesn't happen in star rendering, which is bulk of the trigonometry that KStars does.

The assert failure, however, is more serious -- and I do not have it on my system. Could you tell me which projection you were using? Were you using Equatorial Coordinates ("Star globe view") or Horizontal Coordinates ("Horizontal View") in the view menu? I don't see that happening on my laptop (in debug mode, the assert failure would lead to a crash, and KStars is not being very crashy on my laptop)

Regards
Akarsh

Read More...

Akarsh replied to the topic 'Ekos on Mac OS X ?' in the forum. 6 years ago

BTW: I just pushed a commit to fix the CachingDms build bug. Thanks for pointing it out. Please see if you can now build.

Regards
Akarsh

Read More...