Hello Tom & Jasem
I have managed to get there. I can now see RollOffino in Ekos on Stellarmate on my RPi.
I found that a "build" directory was created in the "Projects" when building the Indi portion of the process. I had to use that "build" directory for the cmake of the Indi-rolloffino.
The command had to be: $ cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug ~/Projects/indi-3rdparty/indi-rolloffino
Now to get the Arduino and Ekos to play. I think I have a connection but not quite the relay control and sensor inputs yet.
Thanks again for all the help you guys have provided.
That is the same directory that the ../ was supposed to point to. So your tree and default working directory is something different than expected. But make a note of how you got it working for the next time.
Look at the INDI window for the roof driver main tab. It will indicate if it is connected or not. The buttons and status lights will show what switches it has detected as closed. Using the park unpark buttons will try to activate relays.
What code are you running on the Arduino and what kind of roof control do you have or intend to get. Are you presently working using a bench breadboard kind of setup?
I do have a connection. I see it in Indi Control panel.
I am using the Arduino with a relay board and sensors connected testing on the bench.
One relay for open another for close and 2 sensors for open and close.
I am using the rolloffino.standard file for the Arduino. That seems the closes match for what I have for testing.
I did manage to see some action on the Arduino today. I set the sensors as expected and Indi sees it as well.
If I hit the open or closed buttons in Indi I see the corresponding relay come on but then the Indi driver Rolloffino crashes and a few seconds later Kstars crashes.
I have attached a zipped folder with log files.
You indicated that I should be able to use the same process from the HOWTO: Building latest libindi and Ekos on a macOS.
I tried that and get a message: "sudo: apt-get: command not found".
Do you perhaps know what I may be doing wrong.
On the MacOS. There is a good chance that the driver code will work on the Mac, but it will need to be built and installed according to Mac procedures. The present directions in the INSTALL file did not include any thought given to how that is done. For example the apt-get is a Ubuntu specific command. I did get a Mac but since you said it was the RPI4 you were going to use I have not done anything with it. If you intend to run a Mac in the observatory I can spend more time learning how to use it.
The files you posted appear to be the rolloff debug logs or fragments of, just showing the commands and results, most ending in timeouts. Was one of them in particular associated with the crash?
Do you have the KStars log associated with the crash? Did Kstars put up a message indicating the driver had crashed?
The only time I have had the driver crash was when the version of indi / Kstars it was built against was different from the one installed. Although that always happened when starting. If the version you built against in the ~/Projects tree was the one that was cloned into ~/Projects/indi then it would have been the nightly build.
The Kstars and indi versions running for the testing should be from a nightly or the current stable release since I have been using the driver on those and perhaps the previous release without a rebuild.
[ Edit ] Working with a breadboard you might be using the command buttons and receiving response with much different patterns and frequency than the normal open or close roof while waiting without requesting other actions going on. So if you encounter a particular button or sequence of steps that can cause the crash it will be helpful in looking for the weakness in the drivers handling of them that results in a crash.
A quick read of the HOWTO and I can say it will be very helpful.
I will work with it and come back with any ideas that may make it easier.
I have attached the log indi log files that show the crashes.
I am using Stellarmate 1.6 and KStars 3.5.5 Stable.build 2021-09-30T19:39:54Z.
I followed this for this link, from the iNSTALL, for the driver building process: indilib.org/forum/general/210-howto-buil...st-libindi-ekos.html
Then followed the INSTALL for the building the indi-rolloffino driver and associated files.
My Ekos Obs and Iindi Control panels are the same as your images.
From your info about what you are running there should not be a version mismatch issue. I don't understand the Ekos live and websocket relationships but no reason to suspect that or Stellarmate related.
If you have the debug log matching the Kstars log there might be additional info there.
From the Kstars log this is a startup situation, not the case where you were able to close relays and read the switches. It is probably the initial connection message that failed although the logging is not clear about that. What is strange is that it is the Arduino returning an error indicating a syntax error for what is probably the driver's initial canned request for its version number. This could happen I suppose if the baud rates between the two did not match or there was some other communication problem.
This initial exchange between the driver and the Arduino is taking place in the context of establishing the initialization and connection between Ekos and the driver. I think the failure to establish this causes the driver to be shutdown.
by the indiserver. Some debug logging might need elevating to error messages if there is anything helpful there.
Meanwhile perhaps you can watch out for communication errors and and see if there are cases that occur other than when first starting.
I updated the roolloff.ino.standard example with the same structure as the .ar1450 and the how-to description. Its setup is now for the Uno model using pullup resistors. Did a basic test of it using a Uno relay shield. There was an issue after uploading the sketch to the Uno the first use of the connection after that took several seconds to respond. The driver was modified to log a warning before continuing instead of an error. Consider running the build again to pick up these modified files.