Even though the Rolloffino does not call for INDI builds is does clone the source files needed for 3rdparty build into a development area.
It would be better/safer if you used another Raspberry Pi as a development machine. Then you know the only two files introduced onto the Stellarmate are the ones you place there.
You do need to build on a Raspberry Pi.
I have not tested with Stellarmate only with KStars/Ekos and ubuntu running on a Raspberry Pi.
Follow the Rolloffino INSTALL directions and run the build on a Raspberry Pi. It will create the files listed at the end of the directions.
- /usr/bin/indi_rolloffino The driver executable
- /usr/share/indi/indi_rolloffino.xml Identifying the roof driver to Ekos.
If you do the build on Stellarmate it will attempt to write them directly. If you built elsewhere on some other Raspberry Pi they would need to be copied to the Stellarmate machine.
So it is not the kind of install that will be modifying libraries and such, adding a couple of files should not harm anything. If in Stellarmate's Ekos profiler you do not see Rolloffino added as an option under Domes, it indicate the above .xml file did not get to the correct place.
Anyone know if there is a problem with these assumptions??
Run with all devices listed in the Ekos profile..
The 11-37-17 logs: On startup it indicated indi drivers were already running, Selected the restart them option.
Auto connect worked except for the FP1 flipflat. Pushed its INDI connect button and that is when it crashed.
The 11-53-28 logs: Manually killed the still running drivers and ran the test again.
All devices connected. Went to the Ekos camera tab. Add a 3 second exposure and a count of 5, then run.
Seemed to complete one image then crash. The drivers left running shown below include the fp1, a ccd driver is missing.
tg@astro:temp$ ps -ef|grep indi
tg 40951 1 0 11:53 pts/0 00:00:00 /usr/bin/indiserver -v -p 7624 -m 1024 -r 0 -f /tmp/indififoa1974ea0
tg 40952 40951 0 11:53 pts/0 00:00:00 indi_lx200ap_v2
tg 40953 40951 0 11:53 pts/0 00:00:02 indi_asi_ccd
tg 40954 40951 0 11:53 pts/0 00:00:00 indi_asi_wheel
tg 40955 40951 0 11:53 pts/0 00:00:00 indi_deepskydad_af3_focus
tg 40956 40951 0 11:53 pts/0 00:00:00 indi_rolloffino
tg 40957 40951 0 11:53 pts/0 00:00:00 indi_weather_safety_proxy
tg 40958 40951 0 11:53 pts/0 00:00:00 indi_watchdog
tg 40961 40951 0 11:53 pts/0 00:00:00 indi_pegasus_ppba
tg 40963 40951 0 11:53 pts/0 00:00:00 indi_deepskydad_fp1
tg 40964 40951 0 11:53 pts/0 00:00:00 indi_astrometry
tg 41249 21094 0 12:00 pts/2 00:00:00 grep --color=auto indi
I don't think I can be much help, not being familiar with Astroberry. As author Is there a way to change the heading of the post to see if someone who recognises the problem sees it? Or does astroberry have a different forum?
What type and model will you be using, also is the Arduino type a Uno?
Yes if you are going to use the rolloff-ino.standard sketch done for a Uno. It maps open, close and abort to relay 1 which is set to use pin 4. It is for a one button controller that has its own limit sensors to stop when end of travel is reached. Depending on the relay you are using it might need a HIGH or a LOW on pin 4 to put to close the NO normally open contact. The default is that a HIGH closes the relay. If yours is the opposite flip the HIGH/LOW codes in the setRelay routine.
Separate open and closed switches are needed to indicate to the driver when the roof is fully opened or closed. With an Arduino open switch values tend to float. Meaning when read one time they might return a high and another time return low. So best to pull the open switch to ground or to the positive power voltage with a high value resistor. 10K ohm is common. Some models of Arduino's like the Mega have internal resistors that can be used. The default code is expecting that a low value will indicate that the switch is closed, so a pullup resistor should be used for the open switch setting. See OPEN_CONTACT_HIGH definition and its usage if you want to change that. The defaults for the opened/closed switches: Opened/switch1/pin A0, Closed/switch2/pin A1.
Off-line testing is not a bad idea to check you have these things reliably working before connecting up to the roof.
It appears to be a somewhat parallel effort to the Rolloffino but for ASCOM. An ASCOM driver plugin, an Arduino sketch using a matching protocol and a commercial controller such as a gate opener. You could take the Rolloffino driver code as a guide or basis for INDI and ask the RRCI author if he could provide one for the RRCI. The communication protocol would be made to match what the RRCI Arduino sketch uses.
Alternatively you could directly use the Rolloffino driver and its matching Arduino sketch along with the same commercial controller. There is some customization of the Aruino sketch needed to define the pin assignment you chose to use wiring up the relay and sensors. Depending on how comfortable one is modifying and loading sketches, help is available. The sources are still at github.com/wotalota/indi-rolloffino I hope at some point to get them into the INDI 3rdparty area. Because I have not yet figured out how to get the HTML sub-directory to display in its finished form in github the following is just a short cut link to the overview doc at filedn.com/lbwlawm4qYUuekxBMA2mvSS/indi/rolloffino.html
Under indilib.org > Devices > Domes some of the other available INDI roof drivers are outlined.
Yes the latest install of 1.9.7 was yesterday, only ppa installs. The machine is relatively new, has been out there about a month with a fresh install of 22.04 so should be pretty clean.
Computer: Intel NUC i5-11, 32GB, M.2 drive.
KStars 3.6.0 stable. INDI 1.9.7
KStars crashes along with the ZWO CCD when taking an image. The other drivers are left running.
Everything is running local on the same machine. Suspecting a corrupted system but purging and reinstalling has not resolved the issue.
Test is to just take 10 images without accessing any Ekos tab except the camera.
Stripped down peripherals to just mount, 2 cameras and images can be taken.
Added back in the following and it continued to work: DeepSkyDad AF3, ASI EFW, Rolloffino, Weather Safety Proxy, Watchdog, Astrometry.
Added DeepSkyDad FP1, and it went back to crashing.
Removed the FP1 and added back in Pegasus PPBA, and it worked
Added back in the FP1 and KStars crashed including the CCD driver.
tg 20962 1 0 12:17 tty2 00:00:00 /usr/bin/indiserver -v -p 7624 -m 1024 -r 0 -f /tmp/indififo0fd45962
tg 20963 20962 0 12:17 tty2 00:00:00 indi_lx200ap_v2
tg 20964 20962 0 12:17 tty2 00:00:02 indi_asi_ccd
tg 20965 20962 0 12:17 tty2 00:00:00 indi_asi_wheel
tg 20966 20962 0 12:17 tty2 00:00:00 indi_deepskydad_af3_focus
tg 20967 20962 0 12:17 tty2 00:00:00 indi_rolloffino
tg 20968 20962 0 12:17 tty2 00:00:00 indi_weather_safety_proxy
tg 20971 20962 0 12:17 tty2 00:00:00 indi_watchdog
tg 20972 20962 0 12:17 tty2 00:00:00 indi_pegasus_ppba
tg 20973 20962 0 12:17 tty2 00:00:00 indi_deepskydad_fp1
tg 20974 20962 0 12:17 tty2 00:00:00 indi_astrometry
Go back to mount & 2 cameras plus FP1. Can take images.
Added DeepSkyDad AF3, ASI EFW, Rolloffino. Crashed during Ekos start leaving just some of the drivers running.
tg@astro:~$ ps -ef|grep indi
tg 21837 1 0 12:39 tty2 00:00:00 /usr/bin/indiserver -v -p 7624 -m 1024 -r 0 -f /tmp/indififod02de891
tg 21838 21837 0 12:39 tty2 00:00:00 indi_lx200ap_v2
tg 21839 21837 3 12:39 tty2 00:00:01 indi_asi_ccd
tg 21840 21837 0 12:39 tty2 00:00:00 indi_asi_wheel
tg 21841 21837 0 12:39 tty2 00:00:00 indi_deepskydad_af3_focus
tg 21842 21837 0 12:39 tty2 00:00:00 indi_rolloffino
tg 21843 21837 0 12:39 tty2 00:00:00 indi_deepskydad_fp1
tg 21928 21094 0 12:40 pts/2 00:00:00 grep --color=auto indi
This starup issue is not new this time it took 5 tries before Ekos could finds its way through the startup.
After getting through startup, running the test KStars & CCD driver crash.
Go back to all drivers except FP1 run 100 images worked okay.
Add in FP1 run 10 image test original problem KStars & CCD driver crashed. Changed FP1 polling to 10 seconds no difference. Tried to run the test with the FP1 disconnected but the CCD tab just hung indicating preparing. FP1 was reconnected during the hang and KStars crashed.
Although it is always KStars and the CCD driver that crashes it does not appear to be a problem with ASI libraries or the driver. During this testing FP1 was always involved but seems to need some help from its friends. It is odd that a unused dust cover would be a factor. Lacking a resolution I might put a Raspberry Pi in the obs to run the drivers to get them off the Ekos machine and see if it improves stability.
The square(s) come from defining fields of view FOV in KStars. I tested and the red telescope position comes from setting KStar > Settings > INDI > Telescope crosshair check box.
Do not have anything of much use to suggest. Can you determine if the CCD driver starts up and runs prior to attempting to connect to it? Is it failing to start, crashing when attempting to connect or just siting there unresponsive? If you still have the terminal connected or can ssh over to the miniPC:
ps -ef | grep indi to see if it is running.
Anything of interest in the KStars or indi logs?
Not familiar with webmanager but running the indiserver directly one can have it generate a log file.
Is it required to run the Pegasus for some reason, are you still connecting the camera through it. If for power, you could test the camera without the cooler. For the mount you could use a simulator. Just try to get recognised connecting to different hubs and a reboot.
I don't recognise INDO perhaps it is INDI? As you say indiserver should be installed: ls -l /usr/bin/indiserver.
I had assumed connect the camera directly meant connect a usb cable directly between the miniPC and the camera, not via Pegasus UPB to rule that out.
I have had similar symptoms with the ASI camera, but having difficulty remembering specifically how it got resolved.
Sometimes the linux USB assignment seem to get hung up in some way. I assume you have rebooted the miniPC.
Then I would define a new Ekos profile with minimal equipment and disconnect the usb cables for the unused equipment. Perhaps just the mount and the camera. Reboot miniPC and see if the camera comes up. If it does add back in the removed peripherals.
Is the mount tracking, if not try enabling tracking. In the attached, used KStars to unpark and then move the mount away from the meridian.
I would tend to approach it using new interrupt routines. Setting the relays to a neutral state could be fired by your fully opened, fully closed switches not the delayed polling from the driver. I'd like to do a generalized version of this but wouldn't get to it until maybe the weekend. If you need an extra delay after the switches close then instead of the interrupts perhaps just add switch checking in the loop routine. You could set a flag to let the loop routine know movement has started could also indicate whether opening or closing. The loop period could be shortened when waiting for movement than the normal nothing happening loop timer.