Jump to content

Narrowband

Motorised Dome pointing for side-by-side GEM ?


Mart

Recommended Posts

Summer last year I started a little project to motorise the dome on my observatory. Little did I know that it would get so involved and take so long.


The need to motorise the dome arose when my old LX200 mount finally gave notice and I decided to invest in a new mount - I opted for an EQ8 GEM. I have two scopes which I wanted to mount side-by-side - a 10" Meade SCT and a 4" refractor. I was agog to watch the GEM leaning over as it contorted to slew to a target. By the time I moved the dome to line the slot up with one of the scopes, the scope is leant over and looking through the dome slot at such an angle that I found myself continuously having to nudge the dome round in order to take long exposure photographs. Thus started the project to motorise the dome.


After much mechanical, electrical, electronic and software engineering I now have a motorised dome that my various astronomy software can connect to and command to slew to an azimuth or slave to my scope.


Now for my (current) problem.


In my various software I can configure the dimensions of the GEM within the dome such that the software can calculate the azimuth for the dome slot in order for it to line up with the scope.


However, this only applies for a single OTA neatly arranged symmetrically on top of a GEM - I can find nothing that will handle a lopsided side-by-side scope arrangement on a GEM.


Has anyone had and solved this problem ?


Does anyone have (and is willing to use) the mathematical skills to work out an algorithm to calculate the dome azimuth for this arrangement ? 


Thank you for listening - a problem shared is ... still a problem unless there's an answer.


Martin

Link to comment
Share on other sites

Hi Martin, I'm not sure I recognise the problem. I have two scopes on a side-by-side mounting in the dome. One is an 8" reflector and the other a 6" refractor. This makes the apparent diameter of the single instrument to be about 8+6+spacing or about 18". I open the dome ascom driver from Poth and it does its stuff. POTH works out the heavy trig for dome alignment based on the location of your mount within the dome and distance of your scopes from the RA and DEC axiis and then just tells your dome what azimuth to move to.

Moving 18" of virtual scope is a narrow fit to the 26" slot at some angles but it generally does a good job, made better by more precise measurements of the mount geometry. Have you tried POth to do this yourself ?

You could write the matrix math down for the rotations of a GEM and then turn that into azimuth/alt cords but since ths is what POTh has already done, let POTH do  the work. The source code for POTH is also available if you still want to do it yourself. Look on the ASCOM web site.

regs

Mike

Link to comment
Share on other sites

Hi Mike,

my challenge is that I have an old dome with a much narrower slot opening - just a fraction over 20". When the GEM is slewed over on its side my 10" has to be aimed exactly mid-centre of the opening to see through it and the side-by-side 4" scope is looking at the inside of the dome.

For photographic sessions I have to choose which scope to use and align it to mid-centre of the opening and that's fine with the dome slaved to the scope so long as I keep away for the zenith - but after a meridian flip the geometry is completely wrong and the scope is looking at the inside of the dome again.

I've tried using POTH, MaximDL and CCD Commander to do the maths to control the dome and using the same mount measurements they behave very differently. I've found MaximDL to work best for me so far.

I gave up on POTH as I couldn't get it anywhere near right - it seemed to think the mount was reversed ? Is there a dummy's guide to how to enter the mount dimensions into POTH  and when a dimension is +ve or -ve value.

Many Thanks,

Martin

Link to comment
Share on other sites

I can see the problem here and no amount of fiddling will resolve this if the aperture isn't wide enough to accommodate the width of both instruments in your side by side configuration as a fixed set of datum points for the mount/telescope(s) will assume that the telescope is right on top of the DEC axis.

POTH works very well indeed and slaving is accomplished accurately using it.

You might find this spreadsheet of some interest as it gives the correct positive and negative entries for POTH (and Maxim for that matter, I have tried both) - obviously these figures are specific to my own own automation project but if you would like a copy of the spreadsheet itself to enter your own values, you would be welcome to a copy.

post-1029-0-69001700-1446156633_thumb.pn

post-1029-0-14937200-1446156650_thumb.pn

Link to comment
Share on other sites

Hi,

Interesting topic for me. I am also in the process of automating my 2.2 metre Pulsar dome. I have got as far as installing the dome rotation motor hardware, a stepper motor driving a timing belt glued to the inner dome flange and building the control box that will control the dome rotation and shutter opening.

The control box is mechanically complete but I am only just starting to write the software I need to make it all happen.

My question is can you tell me exactly how POTH makes available the information on the mount/telescope azimuth? Obviously this is the key to slaving the dome movements to that of the mount.

My solution is to use the Lesvedome system from Pierre de Ponthiere that uses his software to communicate with POTH and then drive a USB breakout board that produces the actual electrical signals to tell my hardware to move the dome or shutter as needed. 

This solution is perfectly good but adds another step in the chain fom POTH to Dome Controller. If I knew how to access the POTH software directly, I could leave out the Lesvedome hardware and software. For info, my controller is Arduino based with an Arduino Mega being in overall charge. Due to my lack of software skills, I also elected to use 3 other Arduino boards to split the overall work into smaller, bite-sized tasks. A Nano is dedicated to producing the pulses for the dome rotation stepper, another Nano monitors the output of a rotary encoder driven by the timing belt and also monitors the motor pulses. It picks up if there is any changes which might mean that the dome has jammed. The fourth board is a Uno with a Zigbee radio module that will handle all the comms to the shutter drive system - which doesn't exist yet.

I am very aware that all this makes for a rather cumbersome system so any ways of simplifying would be great.

To get back to Martin's original post, I don't have an answer but my system is intended to address the same problem by allowing fairly precise azimuth positioning of the dome. By using a stepper, the accuracy is only limited by the lack of circularity of the dome flange that the timing belt is glued to. I expect that I will be able to position the dome to within 0.5 degrees every time. This means that nearly all of the slit width is useable for a side by side scope set up.

Finally, Steve, I would love a copy of your spreadsheet. Very useful!

Regards, Hugh

Link to comment
Share on other sites

My question is can you tell me exactly how POTH makes available the information on the mount/telescope azimuth? Obviously this is the key to slaving the dome movements to that of the mount.

I can't offer much here other than to say that to the best of my knowledge, POTH contributes nothing in the way of actual control, rather, it acts as a common point of contact for the disparate components, in our case here, the mount and the dome rotator/shutter opener. In addition, it also stores the fixed datum points for the telescope's position within the dome giving access to the fixed data and current mount position for the dome controller (LesveDome in my case) so that it can calculate the correct azimuth for the dome aperture.

I think (?) Hugh is essentially confirming my point that the pointing must allow for both telescopes in the side by side arrangement to fit accurately into the width of the current dome aperture. To do this, I believe that you will have to ballast the lighter instrument so that the two extreme outside edges of the telescopes are equidistant from the centre of the DEC axis.

Finally, Steve, I would love a copy of your spreadsheet. Very useful!

I've placed it on my website in the Technical Notes section.

Link to comment
Share on other sites

Steve,

that's great, I'll have another go at measuring up my observatory and trying out POTH.

The measurement I have least confidence in is the U/-D offset from the notional "equator" of the dome - the dome is distinctly not hemispherical. Any feeling for the sensitivity of the maths to this dimension ?

Hi Hugh,

not wanting to discourage you but this project is hard ! Happy to help where I can.

I can't quite picture your system model but here's an outline of the bits in my systems that control the dome if it helps (I ought to draw a picture - maybe later, I'm meant to be fixing a plumbing problem on our central heating at the moment):

CCD Commander - a script runs my photography session and talks to lots of other software, tells MaximDL what to point the scope at

    |

    v

MaximDL -  controls the scope, camera, guide camera and dome, the dome is set to "slave" to the scope. MaximDL works out where the dome needs to be to line up with the scope. MaximDL sends an ASCOM "SlewToAzimuth" command to the dome every second

    |

    v

ASCOM Dome Driver - converts the "SlewToAzimuth" command from MaximDL into the specific command strings that my dome understands

    |

    v

Arduino Dome Rotator - receives the command string to rotate the dome to a specific azimuth, works out how many motor steps that will take and starts stepping

    |

    v

L297 Stepper Motor Controller - takes a step pulse from the Arduino and turns it into the appropriate motor phase waveforms
    |

    v

L298 dual bridge driver - takes the motor phase waveforms and drives constant current to the stepper motor windings
    |

    v

4Nm Stepper Motor - steps
    |

    v

100:1 gear box - drives a pulley
    |

    v

pulley drives the belt to turn the dome

For me to use POTH I'll use MaximDL to control the scope, POTH will "listen" to where the scope is pointing and I'll have POTH talk to the ASCOM Dome Driver. From your description, if you want to connect the POTH directly to your dome controller you would have to write an ASCOM Dome Driver to join the two up.

I guess the Lesvedome systems has its own ASCOM driver and your controller is talking to the Lesvedome systems. In which case, to use POTH you just select the Lesvedome driver to talk to the dome ?

Good luck,

Martin

Link to comment
Share on other sites

The measurement I have least confidence in is the U/-D offset from the notional "equator" of the dome - the dome is distinctly not hemispherical. Any feeling for the sensitivity of the maths to this dimension ?

I think this is the least critical measurement and it makes no allowance for the 'lip' at the bottom of the open dome aperture so I would just measure the height of the wall/dome roof junction and use that.

Link to comment
Share on other sites

Hi,

Steve - many thanks. I had not visited your website before, what a little treasure house of useful things it is. I shall be a frequent visitor.

Martin - many thanks to you as well for a very helpful reply. 

1) ASCOM Dome Driver - converts the "SlewToAzimuth" command from MaximDL into the specific command strings that my dome understands

    |

    v

2) Arduino Dome Rotator - receives the command string to rotate the dome to a specific azimuth, works out how many motor steps that will take and starts stepping

This is what I need to understand. What transactions happen to go from Step 1 to Step 2. How do you actually read the command strings from the ASCOM dome driver software? I am happy to write the Arduino software stuff and am slowly slowly plowing my way into C++ - my previous attempts at programming were in Visual Basic before it went all Object Oriented so it's all very new to me but basically doable.

Regards, Hugh

Link to comment
Share on other sites

Hi Martin,

I see now. Its not that you don't have the aperture or pointing, its more that due to the distance of the telescopes from the centre of the dome, the aperture can be at an angle which reduces its apparent width below your working aperture.

As Steve has mentioned, I suggest that you might also need to optimise your mount by reducing the distance that the dec head sits from the top of the  RA axis (which reduces the apparent angle of the slot to the scope) and centering the large scope on the dec axis and getting your guide scope in snug as close to the on-axis position as possible.

The only issue I have found with POTH is making sure that POTH has its view of which side of pier you're on set correctly. There is a hot key to force this but I'm not sure I recall it working for me. Otherwise, a few measurements and your largely done. I have also had success with Maxim to do this directly.

regards

Mike

Link to comment
Share on other sites

All of the software pre-written will assume that the optical axis of the scope system, whether a single or side-by-side is centred over the mount and will calculate the geometry based upon this. If then at some scope mount positions the slot isn't wide enough to accommodate the entire width of the system then simply, the slot isn't wide enough and the only way to fix this is to reduce the spacing between the telescopes. Offsetting isn't going to work as t some positions of the dome/mount the slot will appear narrower still.

If you're using the Levesdome system then you'll need to build the dome motor and sensor system such that it complies with the specification of the Levesdome controller. The manufacturer will have some documentation that describes how it expects the drive electronics to work. The only choices you have to make here is how you're going to comply with these requirements. However, the plus side of this is that the manufacturer will have done the hard work and written the ASCOM dome control driver. All you have to do is point POTH or Maxim to the ASCOM driver and set the physical parameters.

If you decide to build your own dome controller then you will also have the task of writing the ASCOM driver to match. The website has a developer download which has all the interface specifications and has driver templates that you can modify. The drivers task is to take a standard set of dome commands that all ASCOM compliant programs are aware of and turning them into the commands that your dome hardware understands.

Which course to take depends upon where your skills lie and your assessment of your abilities and the task required. In my case, I'm an electronics engineer by training but lack skills in both programming and mechanics. For me, the path to success lay in letting Pulsar install the whole system.

Kind regards

Andrew

Link to comment
Share on other sites

Hi Hugh,

as Andrew describes, the ASCOM site has developer downloads and a couple of very good tutorial videos that are worth stepping through if you want to go down the DIY path - http://ascom-standards.org/Developer/DriverImpl.htm

I developed my own simple protocol to talk between the ASCOM Driver and my Arduino - from the Arduino end it's "just" a matter of doing serial reads and writes. You parse what you receive from the ASCOM driver to work out what command it sent and then send back an appropriate response. The great thing about using Arduino is that you can just use a dumb terminal on your PC to talk to the Arduino - so I would write some dome code and then test it out by sending and receiving commands using the terminal. Only when I was totally confident that the Arduino was doing what I intended did I then start to develop the ASCOM driver.

The downside of this approach is that I found the ASCOM commands weren't quite what I was expecting and I had to rework some of my simple protocol and Arduino code. But you live and learn. 

Regards,

Martin

Link to comment
Share on other sites

Hi Mart,

Thanks for that. I will look at the ASCOM site and see if I can glean anything. I am happy enough with parsing the information obtained froma serial read, what I'm having difficulty in understanding is how my Arduino will know where to read the data from.

When you say - "dumb terminal on your PC" do you mean the window that you open when you want to say, read values during debugging? I'm sorry if this is all a bit elementary but I am very new to the wonderful world of Arduinos.

Thanks again, Hugh

Link to comment
Share on other sites

Hi Hugh,

I think you said you had a number of Arduino modules doing different things. You connect the one you use as the controller to your PC with a USB cable - as you do to download the code and run the window to read values during debugging. That window terminal on your PC is connected to the USB port that's connected to the Arduino board - so what you type into the terminal is sent down the USB cable to the Arduino and the messages from the Arduino come back up and are displayed in the window.

When you connect the ASCOM driver to the Arduino, you open the setup dialogue and select the USB port that's connected to the Arduino - so now the ASCOM driver is talking to the Arduino.

Here's a code snippet from my driver:

    Public Sub Park() Implements IDomeV2.Park
        Dim s As String = "GOPARK#"
        objSerial.Transmit(s)
        objSerial.ReceiveTerminated("#")
        TL.LogMessage("Park", "Completed")
    End Sub

My protocol uses a "#" character to delimit my commands, so this command sends a text string "GOPARK#" to the Arduino.

At the Arduino, I'm listening for serial data to be received:

  if (Serial.available() >0) 
  {
    cmd = Serial.readStringUntil('#');
this puts into my string variable cmd the text "GOPARK". I then have some conditional logic looking to see which command it is:
else if (cmd=="GOPARK") 
    {
      bCmdMatched = true;
      if (eDomeState == stationary)
      {
        goPark(); // Dome in Tracking mode so command is to Go Park
        Serial.print("0#"); Serial.println();  // Command complete response to ASCOM Driver
      }

so if it is "GOPARK" I call a subroutine "goPark" which does the actual parking of the Dome. When that routines finished I then send the text string "0#" back from the Arduino to the driver to tell the driver the command has completed - if you look at the driver there's a line waiting for "#" character to be sent by the Arduino

    objSerial.ReceiveTerminated("#")

The driver then carries on with whatever it needs to do next.

Hope that gives you an idea.

Regards,

Martin

Link to comment
Share on other sites

Hi Martin,

Many thanks for that, it does help. My set up uses an Arduino Mega as the main controller. I needed a lot of pins as in addition to controlling the dome and shutter via connections to the Velleman USB breakout board that is used in the LesveDomeNet system, it is also a safety monitor with inputs from an Aurora cloud and rain sensor, a separate Hydreon rain sensor and a relay in my UPS PSU that informs when we have a power outage - almost weekly where we live. The Mega also interfaces with a manual control front panel with far too many LEDs.

In addition to the Mega, there is a Nano that generates the pulses for a Leadshine stepper driver, a Nano that takes the input from an optical rotary encoder connected to the dome drive belt and also an optical position sensor- these signals are needed by the LesveDome system - but also allows me to check that the dome hasn't stalled and to shut down the dome motor if it has. Finally there is a Uno with an Xbee shield that will provide wireless comms with another Uno/Xbee in the battery powered shutter drive whenever that gets built.

All the Arduinos are hooked up using I2C.

To date, I have just got the dome part of the system working from the manual control panel. Next will be to set up the automatic control from the LesveDome / Velleman board. A bit easier as the signals are continuous and don't need debouncing. After that I need to finish the hardware for mounting the rotary encoder and the home position sensor. At which point, given a fair wind and a lot of luck, I will have a useable system, albeit without shutter control.  

So, I hope you can understand my interest in how I can get direct ASCOM comms with my Mega. I haven't yet looked at the lins you sent as I have needed all my limited skills to get my basic system running - as at about 6 pm this evening !! I finally persuaded AccelStepper to play nicely with Wire.h.

Regards, Hugh

Link to comment
Share on other sites

I admire your determination to use your own Arduino controller - building my own shutter control board was fun enough and that has no micro-controller!

Unfortunately, I can't add to the Arduino discussion but can confirm that having LesveDome in the system is a good move as it works well and is well supported be Pierre.

Sent from my iPhone from somewhere dark .....

Link to comment
Share on other sites

Hi,

Steve,

I'm glad to hear that the LesveDome system works well. That is the route I am taking for now. In the future I will have a look at writing my own Arduino dome driver, but at present it would just be a huge distraction.

Martin,

I watched Tom How's video with interest and also played around with Visual Studio. Tom's video reminded me of the feeling I used to get towards the end of holidays in France that I was -almost - on the point of understanding the language. Of course, when push came to shove, I didn't understand a word!

Regards, Hugh

Link to comment
Share on other sites

Back to the start of this discussion and my problem of pointing the dome with side-by-side scopes on a GEM.

I've reworked the measurements in my dome and used Steve's spreadsheet (thanks Steve) to get the signs the right way up ... and my dome still doesn't line up with the scopes. I tried MaximDL and POTH. I prefer MaximDL as it tells me the "target" azimuth it's trying to get to for the given scope azimuth. With POTH I can only see the dome's current azimuth - so I don't know where it's actually trying to get to but it's not in line with the scopes.

I've just connected the ASCOM telescope simulator to MaximDL and slewed the scope to 90 deg Azimuth, here's the EQMOD telescope data, the Dome view from MaximDL and the Slaving Parameters in MaximDL:

post-4540-0-80413300-1447514666.png
post-4540-0-34594300-1447514684.png
post-4540-0-08957500-1447514691.png

What puzzles me is that I've pointed the telescope to 90deg Azimuth, the GEM is leaning back so the scopes are "south" of the mount pivot point so I would expect the Dome Target to be greater than 90deg Azimuth - but the Dome Target is 74deg, i.e. north of the mount pivot point.

I'm wondering whether there's something really obvious I'm missing ? 

NB my location is 52 deg N  (51.965183, -2.691222)

 

post-4540-0-80413300-1447514666.png

post-4540-0-34594300-1447514684.png

post-4540-0-08957500-1447514691.png

Link to comment
Share on other sites

I couldn't get the EQASCOM Simulator to work straight away for this quick test so I simply selected the ordinary telescope 'simulator' that you get with ASCOM/MaxIm DL and using your methodology I got the following result:-

post-1029-0-51033300-1447523352.png

Why is your target altitude a minus? Could this have some significance?

Link to comment
Share on other sites

Even more puzzling.

I've just connected to the "Telescope Simulator for .NET" and slewed to "Kappa-1 Cet/96 Cet/HIP15457 (Star)". The scope and dome data look similar to yours:

post-4540-0-56130600-1447525180.png
post-4540-0-63975000-1447525178.png

I then connected to the "EQMOD ASCOM Simulator" and again slewed to "Kappa-1 Cet/96 Cet/HIP15457 (Star)". The scope data looks the same but the dome data is completely different ????

post-4540-0-53977900-1447525179.png
post-4540-0-93359500-1447525177.png

I changed nothing else - so it looks like the EQMOD driver is confusing the calculation of the Dome pointing somehow ?

post-4540-0-93359500-1447525177.png

post-4540-0-63975000-1447525178.png

post-4540-0-53977900-1447525179.png

post-4540-0-56130600-1447525180.png

Link to comment
Share on other sites

Ahah, there was something obvious I was missing.

Always upgrade to the latest version of your software.

ASCOM-talk forum advised that there was a problem with side-of-pier flagging in earlier versions of EQMOD which probably account for the wrong geometry I was seeing. I've upgraded to the latest version of EQMOD ASCOM and the Dome Target Azimuth looks much more sensible.

Now I'm just back to my original problem - how can I adjust the Dome pointing to centre either of my side-by-side scopes to the Dome opening.

(Note to self, always check software versions ...)

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.