Mike
Congratulations on getting it all figured out and working. When you update to KStars 3.4.3 and INDI 1.8.6 there will be an error from the roof driver. The roof driver build procedure will need to be repeated. I just made the correction today, it was using a routine which is no longer available to check for a weather alert before opening the roof. The watchdog driver now provides improved handling to protect the observatory against bad weather.
If you wish, I can add your Arduino sketch and any notes about the motor control you provide as another example in the git repository.

Regards
Tom
Tom

Hi there - thanks very much for this! It will save me a LOT of time! Just loaded rolloff.ino.ar1450 on my Mega2560 and only had to change one thing to get it working:

#define SerialUSB Serial

Working on hooking it up to my SainSmart-compatible 8 relay board.

Regards,
Gord

Gord,
Just to make sure you are using a recent version. At the time of this entry the example was for the Arduino Due with its SerialUSB call. Now there is also rolloff.ino.standard, could be an closer match for the Mega without the Due specific selections? Quick link to the overview doc:
filedn.com/lbwlawm4qYUuekxBMA2mvSS/indi/rolloffino.html
The meld editor is a nice way to see the differences.
Regards
Tom

Thanks so much, Tom! Yup, I am using the most recent version from Github. I appreciate the link to the overview doc, missed the HTML doc in the repo!

My plans are to implement this code then add a few things on the Arduino side and modify the INDI driver accordingly

- Rain detector that will force a safe mode to park the scope/roof immediately
- Voltage detection for two power buses, one for telescope and one for observatory where under-voltage on either bus puts the observatory in safe mode (since eventually, my obs will be solar)
- Hall Effect switches on the mount to confirm park - not closed, no roof movement allowed

I can open a pull request for this when it's done to merge if you wish thx!

Gord,
Only just made the connection, I've been following your high speed micro build, even the grass fills in quick.

- Rain detection and closing of the roof can be obtained using the builtin INDI Dome class that the rolloffino driver inherits without any changes to the driver.. Choose a weather driver, the Watchdog timer and alert the weather driver that it is raining. I'm using the WeatherSafetyProxy driver which supports an external local script or a URL interface for notification depending on what you want to do. I did a weather station as a learning project so tied the RG11 into that and updated the weather driver using a URL. I can provide code examples along the path from RG11 to the weather driver.

- Hall effect switches. I just rely on the interlocks provided by INDI between the mount and the roof. I have a simple clasp to lock the roof down which also closes a switch. That switch feeds the driver's Locked state that prevent roof movement commands from being effective. User Christopher's Arduino example (buttons) tied the builtin Lock command/response into the mounts parked condition to restrict movement commands. Some functions might be able to be decided and contained locally meaning in the Arduino.

My preference is to keep the roof driver functionality constrained to just opening and closing the roof. Thinking about what responsibility belongs in the individual roof drivers and what in the Ekos Observatory. Mine is a backyard obs so I have not thought much about the needs of a remote installation. But if the Ekos Observatory does not cater to those needs perhaps drawing up a set of requirements would be helpful. There was a discussion of possible extensions that suggested some independence from or communicating with Ekos. It has to be robust and reliably available. Also if and how it might relate to the scheduler. It could include power management, external monitoring of KStars operational status. Perhaps able to operate the mount and the roof using some minimal secondary shutdown/startup using indiserver drivers in case of KStar crashes. Some kind of resolution script for if the mount will not park and it is blocking the roof with rain forecast. In the meantime, some time back in the forum there was an interesting Python script working with the mount, cameras and so on I could look for. I find myself in the obs quite a bit, why didn't the computer reboot properly and so on. Having to drive 50 miles would get tired.

Regards Tom

Thanks, Tom not sure how high speed my build is since I'm actually disappointed with how slow it's going Just need to weld the pier to the plate and at least I can get the scope back in operation while I work on the observatory electronics!

I guess my theory was I wanted some way to counter a situation where INDI failed by including separate rain and low power close options in the driver with park detection so the roof won't close unless the scope is parked. Then again I guess if the mount isn't parked it's all futile.... food for thought.

Anyways looking forward to getting the whole think hooked up over the next couple of weeks!

There is already the optional protection built in between the roof and the mount. The roof has the Mount Policy propertyand the mount has the Roof Policy property. So a parked roof can prevent the mount from unparking/moving? And the upnarked mount can stop the roof from closing. Adding external sensors to detect park would ensure the mount is not reporting parked state when it is unparked. Don't know if that is a thing or not.

If KStars fails I think the Watchdog driver will go a long way to letting you do a safety shut down using the built in capabilities. indilib.org/aux/watchdog.html.

Perhaps you could write a driver to handle your power detection requirements and it could in turn initiate a shut down by notifying the watchdog like the weather drivers do.

The rain detection might not need special handling, if things are not working normally then the obs should already be shutting down.

If some processing does need to be outside of Ekos for the rain or other reason, it could be handled by a script or external program. I can't find the forum discussion, but attached is a script user Haans provided. I edited it for local equipment. It is interesting, demonstrating what kind of control can be applied. Don't know off hand how much if any of Ekos that needs to be running for it to work. But could always use a script to locate running processes and kill them off before starting a new subset to work with.

Somewhat related:https://indilib.org/about/ekos/153-robotic-observatory-with-ekos-scheduler.html

DBus scripting might be something to research.indilib.org/forum/development/11869-buil...hon-dbus-script.html

Hi Tom,

I just started following this post recently and found out that I could replace the python based "Dome Scripting Gateway" that I use with my "roll-off' with your rolloffino based driver.

My small, remote observatory uses a split roof on rails driven by linear actuators. To either open or close the roof, I need to activate two relays, one for direction that reverses the actuator polarity and the other to provide power. As your Arduino code uses one relay per roof function (one for opening, one for closing), I wonder if you would have any suggestions to implement two relays functions. I could modify the Arduino code so much to make it specific for my need but I ideally want to keep the code structure intact except for the specifics needed for my application.

Thanks for any help,

Gilles

Gilles,

Do you hold both relays on until a fully open or fully closed switch is sensed? If so that would be the first thing to tackle. Most examples assume some controller will take care of stopping the roof. We would need to respond to the driver that the command had been accepted then monitor for when to turn off the relays. Becasue it is relatively a long time to open/close additional requests will be coming in from the driver if only to get the state of the switches. But need a quicker response to a fully closed state than the driver polling so needs to be done locally.

Can we map the commands open, close abort to the relays you presently activate?
Is there a sequencing requirement such as direction before power?

Is it:
Open: Relay 1 close Relay 2 on
Close: Relay 1 open Relay 2 on

Then to stop or abort Relay 2 is turned off and Relay 1 is left in whichever state it was previously set to.

If it is something like the above and movement needs to be stopped when the limit switches are activated it would be good to have an example for that. Be glad to take a shot at it if you are not in a hurry.
Regards
Tom

Hi Tom, thanks for your reply.

I use a 'DIRECTION' as well as an 'ACTIVATION' relay to open or close the roof.

To open, I only activate the ACTIVATION relay as the NC position of the DIRECTION relay wires the power of the linear actuators (I have 2) to extend. To close, the DIRECTION relay is activated prior to the ACTIVATION relay, to reverse the polarity of the actuators, thus retracting it. The actuators have limit switched to turn them off when the end-of-course is attained but I do not have access to those. I know that the roof is opened or closed when the respective roof limit switches are set to ground (pull-up used) but the Arduino code needs to wait a few more seconds as the roof hits the limit switches before being fully opened or fully closed. The opening and closing functions are blocking so I can't really issue an abort or stop command unless I make some changes that may be a bit more complex. I hope my explanations are clear, if not do not hesitate to let me know.

To sumarize:
Open: DIRECTION relay OFF, ACTIVATION relay ON
Close: DIRECTION relay ON, ACTIVATION relay ON
Abort: ACTIVATION relay OFF

Is there a regular polling of the limit switches from the indi driver? If so, I can simplify my code and rely on the driver to know if the roof is fully opened or fully closed. That would simplify things.

Thanks for the help.
Gilles

Gilles, Yes that is clear and the limit switches simplify things. And yes the driver will be polling waiting for the fully opened/closed switches to be set. My initial note for this was to add some extra definitions but I'll ask some more questions when when I walk it through the code a bit. We need to figure out whether its a replacement of the current Arduino code or a merge. If you have local control buttons that need to be retained or other needs, having a copy of the existing code would help with that and minor stuff like pin assignments, active high or low on the switches.

Hi Tom,

Moving forward with the Arduino code. I can set the relays to their correct states for opening and closing the roof, as well as the limit switched status. The remaining issue is to reset the relays to their inactivated states, i.e. NC. I am not sure where in the code I should put the "put relays to sleep" function. I tried where the limit switches are checked but no luck. I need to put that code in a place that gets executed 'often' and need to add a small delay, as the limit switched change state before the roof is fully opened or closed.

I have attached my adapted version of the rolloff.ini.standard code if it may help. And I am running a mock-up Arduino roof controller with LEDs as relay indicators and wires as switches.

Thanks again,

Gilles