Jump to content

NLC-Banner.thumb.jpg.acb5ba835b9e8bf0718b90539633017d.jpg

800mm Telescope Project


Michele Scotti
 Share

Recommended Posts

3 hours ago, Rusted said:

Reversible synchronous or DC motor? Please keep those pictures coming! We are all here to learn!  :thumbsup:

BBAstrodesign motors are brushed DC from Pittman GM8224D309-R1 rated at 19.1V. 

Here is it disassembled to take out the 2 gear pairs - pls don't tell it to Mel! 

pitt1.JPG.f20a7b91516b18cc6139ebd135ee35b1.JPG

I'm here to share, discuss and learn too ;)

Link to comment
Share on other sites

10 hours ago, vlaiv said:

Could you go a bit more into detail regarding precision of motors.

9000:1 is total reduction of motor spin right?

Let's say that you need to move thru 90 degrees in altitude. You also want at least 0.1" precision in altitude position (to be able to guide properly, and possibly you will want more precision).

This gives you 100 revs per degree, or 1.6666 revs per arc minute, or 0.027777 motor revolutions per arc second, so we are looking at 0.002 revolution of a motor per "step".  That is something like 0.72 degree precision on motor shaft, or 1/500 accuracy. I guess that should be doable with 10 bit encoder on shaft if we are talking about servo motors.

 

Let me quote an example from the Si-Tech manual which is somehow similar to my set-up:

" With a Pittman servo that is labeled 10:1 gearbox, and 500 count encoder, and I attached it to the 360 tooth worm gear on my mount via a 1:2 cog belt drive. So what do I enter for the RA motor ticks/rev? 500 (encoder ticks) x 4 (quadrature) x 10 (gearbox ratio) x 2 (cog belt reduction) x 360 (worm gear drive) = 500 x 4 x 10 x 2 x 360 = 14,400,000 ticks per rev That‟s a lot, but it‟s actually about what you want to shoot for. You want to shoot for at least 10 ticks/arcsecond. This example has about 11.1 ticks/arcsecond. More ticks/arcsec is good, but you trade off slew speeds with a steeper gear ratio."

 

Hope this helps?

 

Link to comment
Share on other sites

6 minutes ago, Michele Scotti said:

Let me quote an example from the Si-Tech manual which is somehow similar to my set-up:

" With a Pittman servo that is labeled 10:1 gearbox, and 500 count encoder, and I attached it to the 360 tooth worm gear on my mount via a 1:2 cog belt drive. So what do I enter for the RA motor ticks/rev? 500 (encoder ticks) x 4 (quadrature) x 10 (gearbox ratio) x 2 (cog belt reduction) x 360 (worm gear drive) = 500 x 4 x 10 x 2 x 360 = 14,400,000 ticks per rev That‟s a lot, but it‟s actually about what you want to shoot for. You want to shoot for at least 10 ticks/arcsecond. This example has about 11.1 ticks/arcsecond. More ticks/arcsec is good, but you trade off slew speeds with a steeper gear ratio."

 

Hope this helps?

 

Well, at least we agree on minimum accuracy needed, that being 1/10 of arc second :D.

But from what I can tell, you have very high gear ratio after that. I'm not sure if you were recommended 9000:1 because of motor torque - it needs a lot of reduction for small motor to move such a large scope. But let's run precision calculation again with this new info.

So motor has about 10:1 gear reduction (and it better be smooth since encoder is pre reduction from what I understand in your quote).

500 x 4 x10 x 60 x 60 x 2.5 = 180000000 (and that is quite a lot) - that is 555.555 ticks per arc second (if I'm not mistaken).

As far as precision goes - that is exceptional, but more precision you add, lower your slew rate. Do you have any idea of what the max RPM is on this motor?

Found it - it says here: http://siderealtechnology.com/MotorSpecs.html

"Maximum RPM with SiTech ServoII controller (24 volt Supply Before Reduction): 10,000"

That is 166.66 revolutions per second. One revolution is 1.6666 arcminutes, so it's 277.777777 arcminutes per second, or 4.63 degrees per second. Ok, that is actually quite fine (if my calculation is correct).

As far as I can tell, Alt drive calculations are quite ok.

What I'm worried about next is smoothness of the drive components (any little bump is going to be amplified significantly at those reduction ratios), and lack of absolute encoders.

We should discuss how much exact positional information impacts on tracking and guiding rates in alt az. This is also very important, as you can't expect 0.1-0.2" RMS tracking/guiding error if drive itself makes wrong move because it does not know exactly where it is pointing.

 

  • Like 1
Link to comment
Share on other sites

4 hours ago, vlaiv said:

That is 166.66 revolutions per second. One revolution is 1.6666 arcminutes, so it's 277.777777 arcminutes per second, or 4.63 degrees per second. Ok, that is actually quite fine (if my calculation is correct).

Thanks for estimating the slewing speed - hadn't done it yet! 👍

4 hours ago, vlaiv said:

and lack of absolute encoders.

Haven't said that 😉 The challenge is to implement something affordable  which I haven't figured out yet. Clearly the encoder on the motor is good but what you need is really the one on the axis - Si-Tech can handle both, I suppose even together

Link to comment
Share on other sites

On 30/08/2019 at 16:32, Michele Scotti said:

Haven't said that 😉 The challenge is to implement something affordable  which I haven't figured out yet. Clearly the encoder on the motor is good but what you need is really the one on the axis - Si-Tech can handle both, I suppose even together

If I may add my experience here with trying to add an absolute encoder to my Sitech controlled DIY fork, I bought a Gurley encoder as specd for Sitech (not cheap), and mounted it via a flexible shaft coupling to the RA axis, the body of the encoder was solidly mounted by bracket to the bearing block. I must have some axial offset in the centering of the encoder, it gives differing RA speed, dependant on pointing position, so will have to go back to the drawing board in its implementation.

EDIT The encoder is not ABSOLUTE, don't know why I called it that!!!

Huw

Edited by Horwig
Wrong information
Link to comment
Share on other sites

1 hour ago, Michele Scotti said:

Haven't said that 😉 The challenge is to implement something affordable  which I haven't figured out yet. Clearly the encoder on the motor is good but what you need is really the one on the axis - Si-Tech can handle both, I suppose even together

I'm going to expand a bit why absolute encoders are necessary for Alt-Az type mount if you want accurate tracking - it is not the same as with GEM mounts where you increase precision of tracking - it is for accurate tracking with AltAz.

Maybe diagram is going to explain it better - I'm going to exaggerate curvature of things so you can see more easily what is going on.

image.png.a771f4737cac0f25129fed79a34ddbbd.png

Imagine scope can't precisely determine Az position - there is certain error. Scope is just a tad past meridian, but "thinks" it is pre meridian in position. Software will tell scope that Alt should increase a bit, but in reality needed Alt position will decrease a bit - tracking will create error in Alt because it is going "the wrong way", and guiding will combat this instead of only correcting things it should correct.

Similar thing applies to guiding as well - it needs to know direction of vector - where Alt is pointing and where Az is pointing in order to give proper corrections - if orientation of scope's Alt/Az is different from that of guide system - wrong corrections will be given and guiding will not work to optimum - it is what happens in GEM mounts when you have wrong guider calibration.

Difference between GEM guide system and Alt/Az system is that Gem guide system in principle needs calibration only once (although people do it every time when changing target / part of the sky - good practice because of cone errors and fact that RA/DEC axis are not always perfectly at 90 degrees to each other). With Alt/Az - you need constantly changing calibration, and software needs to track this and change things, but in order to do so accurately it must know exact pointing of the scope.

This is why you need absolute encoders. Not sure what is needed precision of such encoders, but we might be able to calculate drift rates depending on guide command cycle length and position in the sky.

Link to comment
Share on other sites

20 hours ago, Michele Scotti said:

Drive and tracking - I'd start stating that backlash is the foe.

We are adopting a brushed motor system from BBAstrodesign. The overall recommended reduction sits between 3000:1 and 10000:1.

It's a lot of reduction....But this is where the the dobson configuration nicely pairs with the friction drive concept. The set-up couples a stainless steel rail on a 1200mm diameter rocker with a 20mm h6 ground bar which offers a 60:1 no-backlash as a last stage. A compact low-backlash worm gear reducer for another 60:1 coupled with a 2.5:1 belt and pulley stage completes the drivetrain. Total ratio (60x60x2.5) is 9000:1. Please note that the motors come with a built in 10:1 gearbox that has few gear pairs - too much of backlash imho- conversely the belt will have a tensioner so that the main source of backlash is in the 60:1 worm-gear. Ideally I'd adopt an harmonic drive but it's pretty pricey and those I've found, come with a specced max 30' backlash which translate to 0.5arcsec on the scope axis - hopefully well manageable.

I don't see adopting clutches. That's a limitation but if the slewing is 3deg/s then we'll use a bit of patience.

Pic#1 of the mirror box with two main elements "pacman" - the rails is not present in this model version

Pic#2 The actual rails - 2mm stainless steel. 2 pre-rolled arches for the Altitude and 3 sections for the Azimuth bearing. A full circle would have set us off a fortune - and there's a trick for a smooth section transition.

 

Addendum: last but not least a quick check on the herztian contact stress - just to make sure that the rail and roller will keep their integrity over time and won't have trail and indentations on the surface.

Rollers are fairly small in diameter (22mm) just like the ground bar (20mm) to achieve an high ratio for the no-backlash last stage of the drivetrain - and the smaller the diameter of rollers the higher the stress. I felt important to check this tricky aspect as it can compromise the accuracy over-time.

The altitude one sees an easier life as the track is at least 50mm wide and there are 4 contact points. The load on azimuth is spread on 3 set of rollers instead so the stresses are higher.

121843593_hertzianaltituderoller.JPG.9adb1cb45cf589893e44ef5df55c51a9.JPG       hzaz.jpg.f14c3a83d4b95efbe3dab179588b38d9.jpg

Link to comment
Share on other sites

21 hours ago, Horwig said:

If I may add my experience here with trying to add an absolute encoder to my Sitech controlled DIY fork, I bought a Gurley encoder as specd for Sitech (not cheap), and mounted it via a flexible shaft coupling to the RA axis, the body of the encoder was solidly mounted by bracket to the bearing block. I must have some axial offset in the centering of the encoder, it gives differing RA speed, dependant on pointing position, so will have to go back to the drawing board in its implementation.

 

Huw

great feedback - I've always been very worries about placing the absolute encoder anywhere else than solidly on the main axis.

Out of curiosity how much a Gurley set you off? Is the 10k or 500k cpr? 

Link to comment
Share on other sites

20 hours ago, vlaiv said:

I'm going to expand a bit why absolute encoders are necessary for Alt-Az type mount if you want accurate tracking - it is not the same as with GEM mounts where you increase precision of tracking - it is for accurate tracking with AltAz.

Maybe diagram is going to explain it better - I'm going to exaggerate curvature of things so you can see more easily what is going on.

image.png.a771f4737cac0f25129fed79a34ddbbd.png

Imagine scope can't precisely determine Az position - there is certain error. Scope is just a tad past meridian, but "thinks" it is pre meridian in position. Software will tell scope that Alt should increase a bit, but in reality needed Alt position will decrease a bit - tracking will create error in Alt because it is going "the wrong way", and guiding will combat this instead of only correcting things it should correct.

Similar thing applies to guiding as well - it needs to know direction of vector - where Alt is pointing and where Az is pointing in order to give proper corrections - if orientation of scope's Alt/Az is different from that of guide system - wrong corrections will be given and guiding will not work to optimum - it is what happens in GEM mounts when you have wrong guider calibration.

Difference between GEM guide system and Alt/Az system is that Gem guide system in principle needs calibration only once (although people do it every time when changing target / part of the sky - good practice because of cone errors and fact that RA/DEC axis are not always perfectly at 90 degrees to each other). With Alt/Az - you need constantly changing calibration, and software needs to track this and change things, but in order to do so accurately it must know exact pointing of the scope.

This is why you need absolute encoders. Not sure what is needed precision of such encoders, but we might be able to calculate drift rates depending on guide command cycle length and position in the sky.

Well I see that you are making a good point for the absolute position - I still haven't figure out the implementation of this aspect completely though. 

Link to comment
Share on other sites

I'm not getting the necessity of abs encoders on the alt az mount unless you mean you only need to calibrate once if you don't move the scope? They'd still need calibrating though. A multi star calibration with any type of encoder would sort out the geometry of the mount relative to sky wouldn't it? Of course you'd need encoders on the output to compensate slippage of the friction drive

Link to comment
Share on other sites

1 hour ago, Michele Scotti said:

great feedback - I've always been very worries about placing the absolute encoder anywhere else than solidly on the main axis.

Out of curiosity how much a Gurley set you off? Is the 10k or 500k cpr? 

The Gurley I'm using (or not at the moment) is the 320K pulse R158 encoder, and it's £882

Huw

  • Like 1
Link to comment
Share on other sites

29 minutes ago, markse68 said:

I'm not getting the necessity of abs encoders on the alt az mount unless you mean you only need to calibrate once if you don't move the scope? They'd still need calibrating though. A multi star calibration with any type of encoder would sort out the geometry of the mount relative to sky wouldn't it? Of course you'd need encoders on the output to compensate slippage of the friction drive

There are couple of ways you can determine mount pointing with encoders:

Motor shaft encoders / tick counting - this is for example how Heq5 mount does it. It measures motor shaft position / number of revolutions. It would work perfectly if gearing from motor to last stage was perfect - no periodic or non periodic of any sort. But there is difference between what motor shaft outputs and the position of the scope in the sky, and while you think you are pointing at certain spot - you are pointing to somewhere else.

Double low resolution encoders - it's like low bit counter / high bit counter, or if you are not familiar with that, best way to explain it would be - one encoder keeps "hundreds" and other keeps position within a hundred (0-99) when you combine them you get actual position - it's a bit like old analog clock - small hand will give you hour and large hand will give you minutes - combine the two you will get exact time. A bit more precision over precious - motor shaft option, but how much precision depends on resolution of encoder on main shaft (hour hand).

Absolute encoder on the main shaft. It does not need to be absolute encoder, but it needs to have sufficient precision to determine exact shaft position - something like 28bits to have arc second / sub arc second precision in pointing.

I assume that we want to reach a sort of precision that is needed for given requirements - that means imaging at around 0.75"/px. This means that you want guide performance of about 0.1- 0.2" RMS. You want to be able to have something like 10 seconds between guide exposures. In these 10s max that mount can deviate from true position should be around 0.3". Which then translates in max drift rate of 0.03"/s. This is very precise tracking.

Problem with Alt-Az type mount is that your speed in Alt and speed in Az are not constant - they change every second, and depend on where scope is (or better - should be). This is not so with EQ type mount. In normal operation, RA motion is constant, and DEC motion is 0 - wherever you are pointing. If mount makes tracking error - and goes a bit "forward" or a bit "backward" that will not impact DEC rate - it will remain 0. Similarly if there is drift in DEC because poor polar alignment, RA rate of motion will not be affected by this.

With Alt-Az type of mount - change in position requires correction of both Alt rotation rate and Az rotation rate to properly keep correct pointing. If there is error in any of these two, scope will be pointing at the wrong place, but will think it is pointing elsewhere and will change Alt and Az rate accordingly which in turn will make it drift more - further from wanted position, and again it will calculate improper tracking rates and drift more ....

For this not to happen, you need most precise encoders that you can have - and those would be full resolution encoders (either incremental or absolute) on Alt and Az axis of the scope.

 

Link to comment
Share on other sites

15 minutes ago, vlaiv said:

For this not to happen, you need most precise encoders that you can have - and those would be full resolution encoders (either incremental or absolute) on Alt and Az axis of the scope.

Yes- I was just questioning the need for absolute encoders - nice if the scope never gets moved but not really a necessity. Also resolution doesn't equal accuracy and like Horwig mentioned mounting accuracy can throw everything. Heidenhain (and others I'm sure) make some huge encoders for CNC machines etc which benefit from their diameter and very thick accurate glass grating  

Edited by markse68
  • Like 1
Link to comment
Share on other sites

This is what the professionals buy when they want a 800mm 'scope.

Just throwing this up, no I don't suggest you need all of this, just fillet it to your needs. If you have anyone who can make you DD motors for both axes I would seriously consider it.

Link to comment
Share on other sites

Just to clear things up, in my post above, I called the Gurley encoder an absolute encoder. IT IS NOT, what I'm sure I meant to write was mount encoder as opposed to a motor encoder.

I'm not sure where my brain was when I wrote that post, apologies to those I mislead.

Huw

Link to comment
Share on other sites

1 hour ago, markse68 said:

Yes- I was just questioning the need for absolute encoders - nice if the scope never gets moved but not really a necessity. Also resolution doesn't equal accuracy and like Horwig mentioned mounting accuracy can throw everything. Heidenhain (and others I'm sure) make some huge encoders for CNC machines etc which benefit from their diameter and very thick accurate glass grating  

There are some DRO systems out there that might be interesting with sub-micron resolution magnetic or optical strips that do not look outrageously expensive. It would need some DIY to integrate of course.

Link to comment
Share on other sites

7 minutes ago, Michele Scotti said:

There are some DRO systems out there that might be interesting with sub-micron resolution magnetic or optical strips that do not look outrageously expensive. It would need some DIY to integrate of course.

1um will be provide 0.1" resolution with about 2 meter radius. Might be feasible to put it in 1-1.5m diameter if you have sub-micron resolution and are happy with about half to quarter of arc seconds in angular precision. Not sure if those linear encoders can bend?

Link to comment
Share on other sites

5 hours ago, DaveS said:

This is what the professionals buy when they want a 800mm 'scope.

Just throwing this up, no I don't suggest you need all of this, just fillet it to your needs. If you have anyone who can make you DD motors for both axes I would seriously consider it.

That kind of execution is always inspirational - the trick is to trickle down to DIY level of course with some limitation.

DD motors are awesome but im not aware of any control unit available at amateur level. I reckon the motor itself is suitable for DIY. Wrt encoders I still need to figure out if anything is available at reasonable price 

Link to comment
Share on other sites

The attached pic of CAD model is the result of few months of work and the best of our engineering knowledge. We are currently working on a major update revision. The description below is about the new design so sorry for some mismatch.

1896281524_TelescopeCADv12.JPG.975b3d9963cf85d2a878b627ccef5a50.JPG

I reckon the structure is pretty typical for a Dob in this class. A simplified/integrated rocker box swivels on two ground bars - that's a smart design I've seen on few motorized Dobs. Those bars are supported with heavy-duty bearing on a rotating table that provides the azimuth axis. Under the Az table three 'legs' are housing the roller bearings to allow the azimuth rotation - this is like a big Lazy Susan bearing.
I suppose one could look at the structure as two big 1200mm bearings.

The upper cage is again a structure as simple as possible with 2 identical hexagonal elements connected through 3 pillars and a plate that serves as mounting support for the focuser/derotator. Pillars and plate provide the attachment for the spider that holds the housing of the secondary mirror assembly.

To connect the upper cage and the rocker box we adopt a truss arrangement. 6 vs 8 beams configurations were compared eventually in favor of 6. The idea is to optimize the number mainly due to the cost of 1.5m poles.

We use FEA to validate the structure. The performance of a telescope hinges on its ability to perform tracking to the specified purpose. That's where the structure itself plays a crucial role.
Ideally, what you are looking for is stiffness, and that's to be insensitive to external perturbations and to be positively reactive to inputs such as tracking, PEC and autoguiding. In other words, a gust of wind shouldn't upset the tracking and if guiding corrections are imparted the reaction shouldn't over or undershoot.

If you want to have something stiff but lightweight then your main engineering parameter is called structural natural frequency - or heigenmodes. In practical terms, if you tap on a mount you want the oscillation to be small and dampen out as quickly as possible.

And the only way to predict it properly is Finite Element Analysis. We didn't want to spend any significant amount of money before knowing that the mount is fit for purpose. The gifs are showing exaggerated oscillations of structural frequency - the higher the frequency the stiffer the mount.

The target is a bit tricky to set as there not much literature out there. There are definitely papers about big meters class telescopes but not for our purpose although the spirit is the same for any telescope. For our project I set the target to 25Hz.

 

The first iteration showed 19Hz and 20Hz for the first 2 modes. The third mode -related to the mirror cell support- is over 30Hz so it's ok.

  image5.gif.f3d71d991e1c99abdb15e6036ba63956.gif    image3.gif.d1564e930348be5831331e4be09979d3.gif

 image8.gif.ec72b01a747f1b0b35a67d7392e73b05.gif

  • Like 1
Link to comment
Share on other sites

2 hours ago, Chriske said:

Michele,

Did not read it all, so sorry if this has been mentioned before.
To find out what the best support for your primary mirror should be, you could use PLOP software.

No worries  - I like to double check my work.

PLOP carried out some time ago -27 is the winner

Capture.JPG.9609b0b47b495ebf8804097c083dade3.JPG

And done some FEA on the triangles:

1043499876_100N8mm.thumb.jpg.41724530a1eb3e1cbd336409d976434d.jpg

Link to comment
Share on other sites

On ‎28‎/‎08‎/‎2019 at 16:45, Michele Scotti said:

I'm focusing on developing a system capable of imaging on deep-sky objects i.e. able to robustly track for several minutes with sub-diffraction pixel sensing system.

Excuse my ignorance, but I have still not grasped the justification for this project. We imaging newbies are constantly told that one does not need a large telescope for deep-sky imaging, that an 80mm aperture APO will do just fine.   Even the massive WASP sky-survey looking for exoplanets used arrays of small optical elements.   I saw a spare element on display at the Open University and it looked small enough to put under my arm.

Apparently when a University department wants a research telescope or two, the stock response is to order up a 16" fork-mounted Meade and a dome. The OU has one.

Yes I know that giant optical telescopes are used for probing the furthest reaches of the universe, but these are mounted on mountain-tops far from light pollution and far from persistent cloud cover, or even in space. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • 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.