The cause seems to be a regular call to the infamous astroplan package, even just for what I thought a simple calculation. I have updated that package too and it does not seem to improve - rather the opposite.
I thought a delay in INDI event processing would cause missed events, but why does it cause this type of python exception?
OK. I have done some cleaning, even tried a new installation of Astroberry... It looks like completely random crashes, both run manually and at the startup.
Hi, I have a rather complex pyindi script that I have no problems to run manually, but when started on system boot (rc.local or systemd service), it usually fails (only occasionally/randomly it starts). Until lately, it worked (mostly) also on startup, but suddenly (after latest Astroberry updates?) it usually fails and I have to restart it manually.
It always fails with the following message:
Traceback (most recent call last): File "/usr/local/lib/python3.7/dist-packages/PyIndi.py", line 1081, in <lambda> __getattr__ = lambda self, name: _swig_getattr(self, BaseClient, name) File "/usr/local/lib/python3.7/dist-packages/PyIndi.py", line 80, in _swig_getattr raise AttributeError("'%s' object has no attribute '%s'" % (class_type.__name__, name)) AttributeError: 'BaseClient' object has no attribute 'removeDevice'
Dispatch command error(-1): No device available and none was created <defNumber name="%g" label="" format="%g" min="-32767" max="32767" step="0"> 0 </defNumber>
I didn't start Ekos. I just started KStars. But I have to admit I am completely confused of how it is configured. Does it always start its own instance of INDI server by default? Where can I turn it off? I always just use the device manager to manually connect to the running INDI server at localhost - I wonder whether that cannot just happen automatically on start? The documentation just describes how to connect and change the modes manually, but I cannot see any setting for automatic connection/setup.
I had a closer look at my DIY thumb joystick and not only its resolution is very poor, but it has terrible dead zones at the edges of its range. Maybe it is rather problem of the Arduino controller and its A/D converter. Anyway, the only plausible solution to use the range of values would probably be to divide it into three zones. The outer would incrementally increase the slew rate (let's say in 0.5s intervals?), the medial would just keep the movement and the inner one would incrementally decrease the speed until it stops completely. The Arduino could emulate the speed change commands as button presses. However, it does not seem to be of any use with the current speed limits and the automatic go-to system is the only way to control large scale slews at the moment.
I found no closer description of the "ramp up" process of slew speed in the documentation. May be one could find inspiration in the ASCOM source code? At the first look it seems to define 5 speeds: 0 (stop), 0.6x (guide), 5x (center), 50x (move) and 600x (slew 2.5deg/s). (The base being the sidereal rate.) Does anyone have any experience with the ASCOM implementation and how it actually behaves?
So, I have not found anything useful using logs, so I just wrote a simple python script that turns on the "USEJOYSTICK" switch and put it into /etc/rc.local. Stupid workaround, but it works (with a slight delay after bootup).
I have tried testing my thumb joystick, fighting with its random deviations, which make everything more complicated. I am thinking of several methods how to control the speed without additional buttons. But for casual visual observations, it seems I would be happy enough just using the highest speed currently available. Higher speeds are not supported (and I do not dare to implement them now) and lower speeds do not currently seem to be necessary (the iExos-100 is not that much robust and stable for such delicate fine-tuning anyway, and for astrophotography a remote control by a computer seems more useful than manual joystick).
I was just a bit surprised yesterday: after slewing to some position in the sky using SkySafari, I started KStars at the Astroberry desktop and at that moment the mount driver got reset, thinking it is pointing to the NCP. Any idea why?
Oh, it looks like the problematic update was indi-astroberry-diy 2.5. The indi web manager wasn't able to change the profile, but after I manually removed the "Astroberry Board" driver from .indi/profiles.db, everything seems to work again.
I just did apt update now and after reboot INDI won't start. The syslog is full of the following failures:
systemd: Started INDI Web Manager. indi-web: Traceback (most recent call last): indi-web: File "/usr/local/bin/indi-web", line 10, in <module> indi-web: sys.exit(main()) indi-web: File "/usr/local/lib/python3.7/dist-packages/indiweb/main.py", line 315, in main indi-web: start_profile(profile['name']) indi-web: File "/usr/local/lib/python3.7/dist-packages/indiweb/main.py", line 99, in start_profile indi-web: indi_server.start(info['port'], all_drivers) indi-web: File "/usr/local/lib/python3.7/dist-packages/indiweb/indi_server.py", line 74, in start indi-web: self.start_driver(driver) indi-web: File "/usr/local/lib/python3.7/dist-packages/indiweb/indi_server.py", line 37, in start_driver indi-web: cmd = 'start %s' % driver.binary indi-web: AttributeError: 'NoneType' object has no attribute 'binary' systemd: indiwebmanager.service: Main process exited, code=exited, status=1/FAILURE systemd: indiwebmanager.service: Failed with result 'exit-code'.
WARNING: terminating indiserver failed code 1
Setting the SlewRate according to the magnitude of the joystick inTelescope::processNSWE() e.g.:
After a long search for the code where the driver integrates the joystick controller, I found (surprise! surprise!) that it's all just inherited from the default INDI::Telescope implementation. Finally, a lot of the undocumented settings make some sense to me, as well as the terms "angle" and "magnitude". On the other hand, most of the limitations seem to be based here. Since it is the work of Mutlaq personally, the reason is definitely NOT any lack of competence in this case... The "magnitude" plays no role - it just starts movement when above 90% (and stops when below 50%?). So, trying to program the joystick to work around the INDI system seems as crazy as just playing with the code of the method Telescope::processNSWE() myself. Or maybe is the whole idea of mine to control the speed by the magnitude of the joystick just for some reason bad?
The problem might have been that I misunderstood the documentation and turned into the debugging mode where there are completely different commands with low-level effects on basic settings. But that is just another reason not to trust myself. Nobody really told me what happened, they just sent me a new mount.
I only tried the mount twice since I bought it and I have had problems with a proper polar alignment and with keeping it. I still need to learn. But I wished to be able to move the mount freely manually even without the goto, just to be on the safe side if I give up fighting in the fields and forests. I have read the higher speeds need to be turned on gradually (and I do not suppose the mount does it automatically, so I expect it to be the reason it is not implemented in the driver yet).
The ability to move both axes at once should not be a problem, though. Currently the driver denies the second movement, because the mount "is currently slewing". I suppose it is not desirable to start movements when the mount is slewing automatically to some target position. So, if it is possible to differentiate between the goto-slewing movement and the manual one, it could be enabled easily. I will have a look.
However, those are all just minor details one can live well without. I guess the most serious limitation of the driver is currently the lack of support for the INDI alignment subsystem...?
Maybe the joystick is not available at the moment the INDI drivers start and turns off again? I noticed that happens with the mount as well. It is not a plug and play system, it only tries once...?
Yes, I would like to contribute, I just do not trust myself. My first experiments ended with a damaged mount and I had to return it. I only tried to telnet and query the firmware version and still the mount stopped working. A discouraging experience. So, when I see something is not implemented by a more competent person, I am afraid there might be some good reason for that. I will try to get deeper into the INDI system, if I can, but I will surely always try to raise questions before trying to actually "fix" something that should not be played with for some good reason.
I really like the whole INDI system architecture, but I still wonder about some details of the implementation, such as the array-like implementation of switches and the reason for such implementation decisions (what happens if I try to switch on more then one option? etc.). I should probably get some time to study the documentation closer before trying to hack something (and break it).
Another limitation: when using the joystick, I actually cannot move the other axis while one is moving, only one axis movement at a time is possible. Is this a purpose as well?
Also, the joystick gets never connected to the PMC8 driver automatically - I always have to trigger connect manually after start. Saving the settings does not help. The worst thing is reconnecting the joystick, then I have to go to the joystick driver settings (not PMC8) and manually disconnect and connect again. Well, I know, nothing is perfect and I can make some scripts, I am just not sure whether to report such minor issues to someone.
Finally SOLVED! I still have no idea where the configurations is stored, but it can actually be changed very easily by the VNC control panel accessible on the desktop, via the small VNC applet on the right top of the screen. When the "VNC Server" window opens, click the menu button in the right top corner of the window and select "Options" from the menu. It will ask for your user's password and then open the Options dialog. Select "Expert" panel on the left and then find "Authentication" in the list of parameters on the right. Set the value manually to "None" and confirm that you are sure you really want to disable the authentication. Click "Apply" or "OK" and you are done.
That's right. GPSD autodetects USB connected GPS automatically and adjusts to its parameters, without any configuration. However, I had a problem with a Prolific PL2303 USB-to -serial adapter - it always stopped working with GPSB after some 8-15 seconds of successful communication. Still don't know if it is a specific problem of the combination of GPSd and PL drivers or whether my PL adapter is just defect, but it seems to work well under other circumstances, e.g. when just dumping the serial messages to the console.