Gina

The easiest way of remote controlling the RPi for the ROR is to use a minor sub-set of the KStars/Ekos/INDI system separate from the astro imaging, though I may find out how to combine them later and stop an imaging run if rain is detected, as well as closing the roof. The Astroberry Board INDI driver is easily altered to provide the functionality to control the roof.

Modus Operandi of the RPi control panel will be (3 buttons with lights) :- Button to OPEN the roof - Inactive : Grey - Roof opening : Yellow - Roof Open : Green - Fault when opening RED Button to CLOSE the roof - Inactive : Grey - Roof closing : Yellow - Roof Closed : Green - Fault when closing RED Emergency STOP button - Inactive : Grey - Motor Stopped : Green

I wondered that too.

I did do it with a DSLR some years ago but yes, water cooling a camera on a scope/mount was a bit of a problem.

If ever I buy a Nitrogen 3nm filter it will have to wait at least a couple of months and then I shall need convincing that it would be better than using Ha 5mm - Ha 3nm. Spent this months allocation on a bigger EFW!

I have yet to decide whether to test the Arduino local control first then disconnect and bring the control box back indoors to continue or whether to write the RPi code first and test that indoors before taking the unit out to the observatory. One point is that some of the resting logic levels in the Arduino rely on the RPi so maybe that needs writing before any hardware testing.

Corresponding RPi GPIO lines :- int rpiClosePin = A3; // Remote Close -- RPi GPIO 24 int rpiStopPin = A4; // Remote Stop -- RPi GPIO 23 int rpiOpenPin = A5; // Remote Open -- RPi GPIO 22 // int limClosedPin = A6; // Closed Limit Switch -- RPi GPIO 3 int limOpenPin = A7; // Open Limit Switch -- RPi GPIO 2 // int rpiFaultPin = 13; // Remote Fault Sense -- RPi GPIO 5

The latest version is not quite finished but there are pics of earlier versions on here and I shall certainly be posting pics of this one when it's finished.

Yes, it is. Or rather it will be when I've finished the latest version. It has been in the past. And the results quoted above apply to an earlier version.

Here is a first go at the Arduino sketch. There are a few refinements to add but I think this is the bulk of it. I want to add a timeout to turn the power off if the roof takes too long to open or close. I think the main loop should take only milliseconds in which case I could add in a delay of 0.1 secs and then count in tenths of a second which would be quite adequate for checking timeout. I've kept the code modular for clarity and ease of diagnosis if it doesn't work as expected. // Filename :- ROR_Control_2019-11-20 // bool roofOpen = false; bool roofOpening = false; bool roofClosing = false; bool timerRunning = false; // int Threshold = 400; // 2v analog to digital threshold - 1023 = 5v int currentLimit = 115; // Motor current sense output gives 140mv per Amp 4A = 140x1024x4/5000 = 115 (100 corresponds to 3.5A) int timoutCount = 180; // Timout in seconds - amount of time alloweed to open or close roof int pbClosePin = 3; // Close Push Button int pbStopPin = 4; // Stop Push Button int pbOpenPin = 5; // Open Push Button int detRainPin = 6; // Rain detector // int MotorInAPin = 7; // Motor In A int MotorInBPin = 8; // Motor In B // int MotorCSPin = A2; // Motor Current Sense // int rpiClosePin = A3; // Remote Close int rpiStopPin = A4; // Remote Stop int rpiOpenPin = A5; // Remote Open // int limClosedPin = A6; // Closed Limit Switch int limOpenPin = A7; // Open Limit Switch // int rpiFaultPin = 13; // Remote Fault Sense // // void setup() { pinMode(pbClosePin,INPUT_PULLUP); // Close Push Button pinMode(pbStopPin,INPUT_PULLUP); // Stop Push Button pinMode(pbOpenPin,INPUT_PULLUP); // Open Push Button pinMode(detRainPin,INPUT_PULLUP); // Rain detector // pinMode(MotorInAPin, OUTPUT); pinMode(MotorInBPin, OUTPUT); pinMode(rpiFaultPin, OUTPUT); } // // void OpenRoof() { MotorInAPin = HIGH; } // void CloseRoof() { MotorInBPin = HIGH; } // void StopMotor() { MotorInAPin = LOW; MotorInBPin = LOW; } // void LimitReached() { StopMotor; } // void MotorStalled() { StopMotor; rpiFaultPin = HIGH; } // // // Test all buttons, inputs and rain detector for change // void loop(){ if (digitalRead(pbOpenPin) == LOW) { OpenRoof; }; if (digitalRead(pbClosePin) == LOW) { CloseRoof; }; if (digitalRead(pbStopPin) == LOW) { StopMotor; }; if (digitalRead(detRainPin) == LOW) { CloseRoof; }; // if ((analogRead(rpiOpenPin) > Threshold)) { OpenRoof; }; if ((analogRead(rpiClosePin) > Threshold)) { CloseRoof; }; if ((analogRead(rpiStopPin) > Threshold)) { StopMotor; }; // if ((analogRead(limClosedPin) > Threshold)) { LimitReached; }; if ((analogRead(limOpenPin) > Threshold)) { LimitReached; }; // if ((analogRead(MotorCSPin) > currentLimit)) { MotorStalled; }; } // End

My first thoughts were to use the same type of rails and drives as my Concorde printer viz. V-Slot aluminium extrusion with Mini V wheels including C-Beam extrusion and gantry plate carriages for the Z axis. I am now looking into higher precision rail systems on a smaller scale. Home made linear bearings using tiny ball bearings arranged in threes around round rods is one option but this means using dozens of ball bearings with every third being adjustable. Although giving high precision, this is very labour intensive and time consuming, even with 3D printed parts. My thanks to @Chriske for this idea. Another possibility, apart from the ubiquitous cylindrical linear bearings on round rods, is these MGN12 rails. A combination approach is also a possibility. I shall be giving this a lot more thought before going ahead and ordering anything.

All this has got me thinking again. Whilst the V-Slot extrusion and Mini V-Slot wheels look fine for my bigger printers (Concorde and Giant) they seem rather "chunky" and not all that accurate for my new Mini printer where I want the very best performance, sacrificing build volume to achieve this. I don't really have the time to produce self-made linear bearings with lots of small ball bearings like Chris and I'm thinking the MGN12 rails might be a reasonable compromise. At least they are metal on metal. Alternatively, a combination of the Chriske method and linear rails may be an option.

I have an ASI178MM in my All Sky Camera and use Peltier TEC to cool the camera casing with water cooling of the hot side and reach -20°C with good results and no misting or frosting of the optics. The camera has a thermal jacket and insulation to separate it from the outer casing and hot side of the Peltier TEC. Though it might seem complicated, water cooling is very efficient and doesn't rely on drawing damp air through a fan. The water cooling radiator, reservoir with pump etc. are inside my observatory with the ASC mounted outside on the roof.

His Prusa Mk3 seems to produce very good results but I don't know how fast (or slow) he prints.

Interesting but the Prusa printer is quite different from mine and indeed from the D-Bot so the comparison may not be valid. OTOH there are situations where a rigid construction can produce conflict as the system is constrained in more than one way at a time. Pretty much what he said in fact. I need to think about all this. I guess some flexibility is needed somewhere.

I've noticed black dust in the V-Slots in my printers too. I think the Delrin wheels do wear with extensive use and I do make extensive use of my printers!

I've been interested in those linear rails and wondering how well they work. I know the cylindrical linear bearings had problems and I soon got rid of them in preference to V-Slot rails. I shall shortly be building a new printer to replace my Mini with the idea of maximum precision for printing smaller parts so if these modern type linear rails are good they would be well worth considering. I look forward to seeing how well you like them Dave.

Ubuntu Mate 16.04 as I recall on the RPi and Linux Mint 18 on my desktop where I run KStars/Ekos.

Oh dear Wim that sounds painful and very annoying!! Hope you get fixed up soon and back in business with your observatory. I've been working on the electronics for the ROR this afternoon in fact.

You can buy Nylon screws.

Oh dear...

Sorry to say, I see one flaw in your design. You are blowing warm air from the hot side of the Peltier TEC over the cold camera and aluminium plate. This will reduce the efficiency of the cooling considerably. Please take this as constructive criticism - I don't want to dampen your enthusiasm.

That looks straightforward enough 😀 but I'll probably try the Ekos guider first. Do you have experience of both/either?

One thing to add to the above list as I go on to longer focal lengths and exposures will be guiding. Done it before but I was using Windows apps then now it's Linux with RPi KStars/Ekos/INDI (server and drivers). Don't expect too much trouble, just need to sort things out.

Astrodon 3nm Ha, OIII, SII, Baader LRGB 1.25" mounted