Skybadger Observatory
This is the website of Skybadger.net, dedicated to all aspects of Astronomy from the Skybadger observatory : observing, imaging, building instruments and getting results.
This is the website of Skybadger.net, dedicated to all aspects of Astronomy from the Skybadger observatory : observing, imaging, building instruments and getting results.
In setting up an automated observatory, one of the requirements if its fully automated and remote, is that I need some way of controlling and viewing the status of the component parts.
Node-Red is a drag and drop programming environment underpinned by the NPM software management tool and Node.js javascript hosting tool.
Fortunately, a lot of the complexity is kept from us by providing a set of drag and drop operators that are then wired together
with operators and graphical cables that turn them into flows of p[rocessing of input into output.
Find Node-red here : Node-Red
A flow is a set of nodes wired together to process inputs and outputs sequentially. The inputs are typically data from the
nearby devices used as sensors and their state reports as well as services used to tell these devices what to do.
Flows are used to manage:
An example of the dahsboard is the device health graph - each device checks in every 60 seconds in response to a heartbeat issued by node-red.
The graph increases throughut the day aand resets at midday. Some devices are on all the time and some onl;y when the dome is actively observing.
On the right side of the image above, devices have been turned on in preparation for an imaging session,
compared to the few devices left on all the time.
As part of setting up an automated observatory, one of the instruments we will need is a way to look at the sky and the environment around us so we know its safe ( in the expensive sensitive equipment meets rain and weather sense) to operate This is then used to control when the observatory operates by combining: - the input from a Sky Quality Meter (SQM Meter) which measures the sky brightness in lux and Magnitudes/square arc-second - the input from a weather station - safe operating windspeeds and maximum gusts - presence of rain - forecast presence of cloud - ambient temperature and sky temperature - Input from a clock - is the time of day sensible to oibserve this object ? As shown in the picture above, the driver is implemented using Node http request objects to handle the observing condition attribute requests. The attribute values are read from the cached values on the flow which are updated every time a MQTT reading comes in. The values are prepared and turned into a json response which then are all returned via the same response object. In Voyager, this is setup as an observing conditions driver which is pointed at the alpaca web service instance that is the node flow.
The Node-red safety driver implements the ASCOM Alpaca Safety REST service using the Node http request handlers.
The safety config sets the settings that determine the safe condition for observing.
In this case, the difference in temperature between sky and ambient, the minimum sky termperature considered safe,
the maximum wind speed considered safe, the rain and cloud limits considered safe and the sky temperature we consider guaranteed clear.
If any value breaks these limits, the condition is NOT 'safe'.
Voyager as my imaging session manager, calls the Alpaca interface every 30 secs or so to determine the safe conditions and with a non-True response, implements the non-safe observatory protection mechanisms.
Essentially, close the shutter and turn off tracking.
When the safety condition is clear and it becomes safe to observe again, Voyager will wait a pre-determined number of minutes to confirm the state is a brief occurrence and then re-open and continue tracking from wher it left off.
Closing the shutter can be expensive in terms of battery power so it cannot happen continually throughout the night, the main reason for the added delay. If it does, we might get to the point where there is no
battery to drive the shuuter closed while it starts to pour down.
End of night operations close the dome, park the scope and turn the dome to maximise illumination to the solar panels.
The Message Queue text transfer ( MQTT ) service built into node-red provides a means of transferring short messages between components Each device implements a listening service which waits for messages from the centre such as the heartbeat and when received, reports its data back to the centre in the form of sensor data, system health status and any persistent data for preserving though power cycles. The structure and types of data exchanged are shown below.
