Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Platesolved GoTo - A DIY software/hardware project (PS-G2)

  • Please log in to reply
12 replies to this topic

#1 hcf

hcf

    Messenger

  • -----
  • topic starter
  • Posts: 450
  • Joined: 01 Dec 2017

Posted 05 February 2020 - 06:51 PM

PS-G2 : A PlateSolved GoTo

 

Summary:

 

A project to add GoTo to a manual EQ mount using platesolving iteratively to achieve accuracy.

 

 

Background:

 

People have been adding stepper motors to manual EQ mounts to do slewing and guiding and to some degree goto, but it is usually not very accurate without having encoders to provide feedback. This is another way to add feedback to GoTo, to make it more accurate.

I did a platesolved PushTo project about a year ago on my entry level $100 ES EXOS Nano EQ mount, and this is a continuation of that using similar gear to achieve GoTo. This can be done on most manual EQ mounts.

 

 

Gear I used:

 

psg21

 

 

PS-G2 electronics

 

  1. 2 Nema 17 stepper motors Model Number: JK42HM48-1504  Costs about $22 each
  2. An Arduino UNO, a CNC shield and two DRV8825 drivers. All the electronics can be got from ebay for under $15. No soldering needed. You do need a high amp 12V power supply. Mine is 12V 8A.
  3. If you want GoTo for visual, you need a camera. I used a  modded action cam described well in the PSWAI post. If you are doing EAA/AP you don't need this, and can use the imaging camera itself.
  4. A mount side computer running linux. You can use a raspberry pi like box or a laptop running linux. I used an Android TV Box running Armbian which has a performance better than a Pi3B and closer to a Pi4 4GB. Astrometry.net platesolver running natively on the box. Both the camera and the arduino connect to this mount side computer. Some amount of linux skill (using linux) is necessary.

 
  I have had the RA motor for a while to do guiding for AP for a while, and recently added a DEC motor, which as you can see from the post is probably the most terrible way to add a Dec Motor. But even with this setup I can achieve GoTo with an accuracy of 0.2 degrees easily.

 

Software:
  Assuming you already have  RA and DEC drives with an arduino sketch to control them the addition is simple.
 

  • Add a slew command to the arduino code in my case "G x y" where x and y degrees to slew in RA and DEC. The arduino code figures out how many stepper steps are needed and moves the motors by that many steps either simulatenously or one axis at a time. You can also add in corrections for RA drift during slewing and backlash here.
  • A python script running on the linux box, which talks to the Arduino over USB and does the following:
  1. Figures out the RA and DEC to GoTo by looking up a table using the DSO name.
  2. Takes an image and platesolves it to figure out current location. Say this is RA1 and DEC1
  3. Sends the arduino a command "G (RA-RA1) (DEC-DEC1)" to try to move to the destination
  4. Waits for the arduino to finish slewing and goes back to step 2 to try again.
  5. The exit criteria from step 2 is either it gets close enough to the destination (in my case both RA and DEC within 0.2 degrees) or it has finished a maximum number of tries (in my case 5). ie, if it cannot get to within 0.2 degrees in 5 iterations (tries) it quits from the GoTo.

 
  Taking an image from a python script is a requirement of the camera you use. For DSLRs I use gphoto2 and for the action cam I use some JSON commands which someone figured out. If you use a different cam, make sure you can take a picture either from the linux command line or from python.

 

Steps for Visual (with the PSWAI Camera):
  

  • A reasonable polar alignment.
  • Aligning the camera (in my case the PSWAI action cam) to the scope. This can be tricky and I mount the action cam on a Orion precision Slow-Motion adapter which makes it easier. But you could do it with the camera on a  ballhead mount, and a lot of patience. This is important because the GoTo will end up centering the view in the camera, and if the eyepiece view is far from it, you might not be able to view the object in the eyepiece. It is like aligning a RDF but with greater accuracy.

  
Steps for EAA/AP (with a DSLR attached to the scope):
 
   An Accurate Polar alignment, as you need for your EAA and AP setup.
   Since you will be using the imaging camera to platesolve, no other alignment is needed.

 

Python script output
Here is a sample verbose output from my python script running on the mount side computer which talks to the Arduino over USB.
The "cmd > " line is where you type in your target DSO. You can see this output in the sceenshots below. I have added comments to the output below to further explain the steps. All the steps are done automatically without user intervention. You just have to type the name of the target, in this case M47.

cmd > M47                                              -->> GoTo M47  (User input)
Going to  M47   114.15 -14.5                           -->> Looks up RA DEC of M47
Taking picture and solving                             -->> Takes a picture with attached camera and platesolves it
Current Location  101.817097 -20.838704                -->> Current location where the scope points to
Iteration  1                                           -->> First try
G 12.332903 6.338704                                   -->> Calculates deltas, sends a slew command to Arduino
                                                       -->> Time spent during slewing.
                                                       -->> The script waits for a finish status from the Arduino
Taking picture and solving                             -->> Takes another picture and platesolves it
Current Location  114.49755 -14.851382                 -->> Location of the scope after Try 1
Iteration  2                                           -->> Try 2
G -0.34755 0.351382                                    -->> Calculates new deltas, sends a slew command to Arduino
                                                       -->> The script waits for a finish status from the Arduino
Taking picture and solving                             -->> Takes another picture and platesolves it
Current Location  114.225555 -14.600053                -->> Location of the scope after Try 2
114.15 -14.5 114.225555 -14.600053 -0.075555 0.100053  -->> RA delta= -0.075555  DEC delta= 0.100053 both less than 0.2 (Target reached)
Finished GoTo                                          -->> Finishes GoTo

Here are a couple of screenshots

 

Visual:
Normally the platesolves are done without annotation for speed, but I can do one with annotation. Here is a screenshot of the output of the script run for  M47 (to the right) , with a platesolve with annotation done at the end (to the left). This is  a 2.7 seconds exposure with the PSWAI action cam platesolved by Astrometry.net running locally.

 

M47
 

EAA/AP:
In this case I have a better camera taking the image to platesolve, a DSLR, so at the end when the GoTo is finished, I do a longer 15-20 seconds exposure (shown in the screenshot below) to make sure it got to the right place. The normal platesolving exposures are 1-2 seconds depending on seeing conditions. After you get to this point, you can start the EAA/AP captures and processing.

 

M48

 

Some more screenshots in the album:

PS-G2 electronics
Album: PS-G2
7 images
0 comments

 

Speed and Accuracy:
In most cases I can get to the target on the 3rd try. In my case the RA usually gets to the destination with more accuracy, the Franken Dec motor mount is not very precise, but the amazing part is it still gets to within 0.2 degrees in 3/4 tries. If I had a proper DEC motor like most people have I could probably get to a lot higher accuracy a lot faster.

For visual, alignment of the camera and the eyepiece is important. If the alignment is off by a lot, the GoTo might work, but you still  might not be able to see the object in the eyepiece. The camera mounting also needs to be good for this, so that the camera does not move around. Most of my visual GoTos have been done with a ES 82 11mm eyepiece with Meade Adventure 80 F/5 scope, and I have always found the target in the eyepiece, though not always perfectly centered due to bad alignment. If this happens I realign the camera and the scope on a bright star.
The slew speed for RA is 32x sidereal. I have not played around with the speed much. Maybe it can be improved. One of the advantages of this system is because no star alignment is needed for GoTo, you can loosen the RA and DEC clutches and move the scope by hand to get closer to the target before locking down the clutches and starting the GoTo. This can save on time for visual.
For visual if I want to center the image in the eyepiece after the GoTo has left it 0.2 degrees away. I can just turn off the motor power and move the slow motion controls by hand, the motor couplers make nice knobs. This is possible because the particular motors I have (it may not be true for all motors) can move when power is off. Some people say this is not safe for the electronics because of back EMF the stepper produces, but I have had not had problems doing this for over a year with the RA motor to fine tune framing. And when I wish to be completely manual, I do not attach the arduino to the motor at all.

 

Current Problems/Limitations:

 

This is still work in progress, but here are some of the current known limitations. There might be more than I have not realized yet smile.gif

  • No Auto Meridian Flip. You cannot do GoTo across a meridian flip. Because the GoTo works so well, it is easy to get carried away and not notice this. There might be a way to detect this will happen and prevent it.
  • No End Limits for scope movement. Depending on the mount, there are places the scope cannot go. The software  has no clue about that and it is very easy of the scope to get stuck if you are not careful. Getting the scope stuck for a while is bad for the electronics, scope, mount.
  • Time taken to platesolve. On the Armbian box I have, each iteration with taking a picture, platesolving, including overheads is about 15s. But since the iterations are all automated, you can just wait.
  • EQ telescope pointing models can be tricky, and I am not sure I have covered all the cases. There might still be cases where the GoTo does not work/or is inefficient especially near the celestial poles.

Advantages:

  • It is amazing to see it work so well, even with really low precision drive systems. I have had the RA only goto with platesolving done for a long time when I first added the RA drive, but I had to use the DEC slow motion cable to be able to frame objects. Having a full accurate GoTo is very useful especially if you want to do remote EAA. Just like auto-guiding is a savior for low precision drives for AP, the platesolving finally makes DIY drives usable for GoTo.
  • No star alignment needed, so you can move the scope by loosening the clutches to get near target before enabling goto thus saving slew time.
  • If I want to buy a better manual mount next, like a CG4/LX70/Skyview Pro all I need is a few extra brackets to attach the motors. The same hardware will work on the new mount. Everything else is programmable. So it is very very reusable.
  • If you use a mountside computer like me, you can connect to it, to run the script and trigger the slew remotely. For visual, you can use a phone/tablet/laptop to use a terminal client like "connectbot" or  "putty" to login to the mount side computer and run the goto python script.
  • I have not seen many DIY motors attached to Alt/Az mounts, but if you had them, you could use the same principles to add GoTo there if you convert the RA DEC to Alt AZ using pyephem/astropy.

 

C&C welcome, and thanks for reading.


Edited by hcf, 06 February 2020 - 06:01 PM.

  • Jon Isaacs, mikefulb, Mel Bartels and 10 others like this

#2 steveastrouk

steveastrouk

    Apollo

  • *****
  • Vendors
  • Posts: 1,104
  • Joined: 01 Aug 2013
  • Loc: State College, Pa.

Posted 06 February 2020 - 11:28 AM

What limits the speed of the plate solve ?


  • hcf likes this

#3 hcf

hcf

    Messenger

  • -----
  • topic starter
  • Posts: 450
  • Joined: 01 Dec 2017

Posted 06 February 2020 - 12:08 PM

What limits the speed of the plate solve ?

The blind platesolve speed depends on a variety of factors

 

1. The image FOV, a wider FOV is better. This is mainly because it searches in the higher number index files which are smaller.

2. Hardware speed. Not just cpu, but the solver also reads and writes files. It is much faster on linux running on an intel laptop than on a Arm SBC.

3. Number of stars in the image. This is tricky, you can dial it down using --downsample but then it might not be able to solve on a higher index file and take more time and not solve at all. The quality of the image plays into this. Downsample also takes some time, more on SD card based hardware like the Pi/TV Box

 

The overall time also includes the picture exposure duration (2 sec), and transfer of file, For my PSWAI camera, the file transfer is done over 2.4Ghz Wifi which can take a couple of seconds. I use separate flags for platesolving depending on the camera, I tend to be a little conservative and pick flags which work in most sky conditions and sky regions.


Edited by hcf, 06 February 2020 - 01:45 PM.

  • steveastrouk likes this

#4 Jon Isaacs

Jon Isaacs

    ISS

  • *****
  • Posts: 85,766
  • Joined: 16 Jun 2004
  • Loc: San Diego and Boulevard, CA

Posted 06 February 2020 - 12:57 PM

hcf:

 

I really can't comment on your efforts, theyre beyond me technically,  except to say it's very creative and innovative and that I think Plate Solving GoTO/PUSHTO seems like the way of the future.

 

I recently became aware of platesolving telescope pointing with Celestrons Star Sense Explorer. It uses a smartphone and the smartphones camera to plate solve and then tell the observer which way to move the scope.

 

Jon


  • Augustus and hcf like this

#5 Dale Eason

Dale Eason

    Surveyor 1

  • *****
  • Posts: 1,684
  • Joined: 24 Nov 2009
  • Loc: Roseville,Mn.

Posted 06 February 2020 - 02:51 PM

I have been following your work and have a Raspberry Pi 4 that I wanted to try it out on.  I installed the plate solver without index files yet.  Then realized I had no way to try it out without sky images.  I only have DSLR cameras (Canon M6).  Had never tried photo of the night sky with it.  However here in Minnesota the sky has been all clouds.  I eventually plan to use the camera setup you have.

 

Do you have example sky images I could try out and a recommendation for which index files to use?  I'm a software and electrical engineer so I understand most of this. 

 

I plan to use this on my 10 inch F3 dob with no go to.

 

Dale Eason


  • hcf likes this

#6 Augustus

Augustus

    Fly Me To The Moon

  • *****
  • Posts: 9,654
  • Joined: 26 Dec 2015
  • Loc: Stamford, Connecticut

Posted 06 February 2020 - 03:41 PM

hcf:

 

I really can't comment on your efforts, theyre beyond me technically,  except to say it's very creative and innovative and that I think Plate Solving GoTO/PUSHTO seems like the way of the future.

 

I recently became aware of platesolving telescope pointing with Celestrons Star Sense Explorer. It uses a smartphone and the smartphones camera to plate solve and then tell the observer which way to move the scope.

 

Jon

I don't think StarSense Explorer uses the smartphone camera, nor does it need to. The phone's internal compass, GPS and level sensors should be sufficient.



#7 Dale Eason

Dale Eason

    Surveyor 1

  • *****
  • Posts: 1,684
  • Joined: 24 Nov 2009
  • Loc: Roseville,Mn.

Posted 06 February 2020 - 04:26 PM

Off topic a bit but yes the StarSense Explorer uses the smart phone camera and the plate solve data in the app on the phone.  


  • Jon Isaacs likes this

#8 hcf

hcf

    Messenger

  • -----
  • topic starter
  • Posts: 450
  • Joined: 01 Dec 2017

Posted 06 February 2020 - 04:49 PM

I have been following your work and have a Raspberry Pi 4 that I wanted to try it out on.  I installed the plate solver without index files yet.  Then realized I had no way to try it out without sky images.  I only have DSLR cameras (Canon M6).  Had never tried photo of the night sky with it.  However here in Minnesota the sky has been all clouds.  I eventually plan to use the camera setup you have.

 

Do you have example sky images I could try out and a recommendation for which index files to use?  I'm a software and electrical engineer so I understand most of this. 

 

I plan to use this on my 10 inch F3 dob with no go to.

 

Dale Eason

So you are looking at using a PSWAI like PushTo on a manual Dob?

 

Actually even a DSLR can work, if you can mount the DSLR with a long FL lens 200-400mm lens on the Dob. You could even use a ST80 like small scope with the DSLR and mount it on the Dob somehow. I use the PSWAI camera on the Dob because it is much lighter. The trick is to get a large enough FOV for fast platesolving, yet not too large as to make aligning with the small FOV of the Dob a problem.

 

A couple of things to try to get your feet wet with astrometry:

 

You can start by mounting the DSLR on a tripod with a long lens, taking a 1-3s ISO 800 shot with as high an aperture as you can. You will have to focus the lens/scope manually (this can be tricky).  On the pi you can also try gphoto2 to control the camera settings and the shutter through USB connected to the DSLR. Once you have a picture first try to platesolve it on nova.astrometry.net to see if it succeeds.  Only then should you try to solve it locally on the pi.  Get astrometry.net which you might already have done.  I use the wide-field index files. Just grab all of them. Then try to solve an image locally using solve-field on the pi. Of importance are the scale-low scale-high and scale-units flags as they determine which index files get used.

 

 

You can use the jpg from my PSWAI camera to experiment, or just go to astrobin.com search for DSLR pictures with a lot of stars and try them.


Edited by hcf, 06 February 2020 - 04:50 PM.


#9 Dale Eason

Dale Eason

    Surveyor 1

  • *****
  • Posts: 1,684
  • Joined: 24 Nov 2009
  • Loc: Roseville,Mn.

Posted 06 February 2020 - 10:31 PM

Thank you for the additional info.  I do want to use a small light weight camera like the Xiaomi Yi Action Cam that you used.  I just discovered that the camera you used is no longer produced and not available at least from Amazon anymore.  So now have to do more research on suitable cameras and needed hacks to make them suitable.

 

Does anyone know of a similar alternative?

 

Dale



#10 hcf

hcf

    Messenger

  • -----
  • topic starter
  • Posts: 450
  • Joined: 01 Dec 2017

Posted 07 February 2020 - 12:32 AM

Thank you for the additional info.  I do want to use a small light weight camera like the Xiaomi Yi Action Cam that you used.  I just discovered that the camera you used is no longer produced and not available at least from Amazon anymore.  So now have to do more research on suitable cameras and needed hacks to make them suitable.

 

Does anyone know of a similar alternative?

 

Dale

Yes, they seem to be rare to find, but you can still find them on ebay once in a while. The 4K versions of the Xiaomi Yi are more popular but I dont think they are as hackable. But you can check on the dashcamtalk forums. The requirements for a cam for this project would be:

 

  • The ability to take longer exposures. Most webcam class of cameras with decent sensors are limited to 0.5 second exposures and that is not enough. You need at least 2-3 second exposures. The Xiaomi Yi can do upto 8 seconds.
  • The ability to change lenses. This means either a M12 mount, or a C mount for the lens.
  • The ability to capture an image from the command line/python on linux. This is a hard one. Most astro cameras these days come with a software and gui but no command line. In addition if you are going to use it on a Pi, they need to have ARM drivers.

 

For non astro cams there are other risks, like being able to turn off any fisheye correction which is common in action cameras. Having fisheye correction will change the projection of the image slightly and cause platesolve to break. I bought the Xiaomi Yi on a gamble because it could support long exposures and was lucky to be able to make it work.

 

Maybe someone with a low end ZWO camera can try a 50mm C mount lens and tell us if it can take images from the command line which can be platesolved. I have heard of a tool called ASISnap for command line capture, which works on the Pi for ZWO cameras, but unsure if it works well on all cameras and is supported.


Edited by hcf, 07 February 2020 - 12:54 AM.


#11 Dale Eason

Dale Eason

    Surveyor 1

  • *****
  • Posts: 1,684
  • Joined: 24 Nov 2009
  • Loc: Roseville,Mn.

Posted 07 February 2020 - 02:29 AM

Thank you once again.  I had come to the same three requirement as your bullet items.  

Before reading your last post.  I have discovered the 4k camera has user selectable shutter speeds of 1/4000 seconds to 30 seconds.  It also has the ability to turn off the distortion adjustment.  I don't yet know about being able to control it with python.  But I'm searching.  It may still have the same features of the original camera.

 

Thanks again for your help and your original posting on this task.

 

Dale


  • Jon Isaacs and hcf like this

#12 Dale Eason

Dale Eason

    Surveyor 1

  • *****
  • Posts: 1,684
  • Joined: 24 Nov 2009
  • Loc: Roseville,Mn.

Posted 11 February 2020 - 10:37 PM

Well since I had such good work with the Canon but it is too heavy I have ordered the 50mm Lens from Alliexpress and the camera from your second vendor.


  • hcf likes this

#13 hcf

hcf

    Messenger

  • -----
  • topic starter
  • Posts: 450
  • Joined: 01 Dec 2017

Posted 16 February 2020 - 12:22 AM

Added an interface for Sky Safari Pro to control the PS-G2. Now I don't have to use the command line for GoTo like before, but can select the desired object on SS6 Pro and click GoTo. Used  a python script implementing a  small subset of the LX200GPS command interface which seems to be the most commonly used interface for DIY. 

 

Tried another experiment with inaccurate polar alignment, just placing the scope and mount at the usual place roughly pointing north without any polar alignment. The Latitude is probably accurate from past usage. Used SS6 Pro to GoTo a few objects. Found everything in the EP with my ES82 11mm on the 80mm F/5 scope even with bad polar alignment. My setup does have wide field views, which probably helped.

 

The camera does get a little inaccurate after a meridian flip, probably due to its high mounting and shift in weight. So have to realign slightly with the scope after a meridian flip.

 

Other than the camera alignment to the scope, no polar alignment, no star alignment needed for visual use, unless you want super accurate tracking. For now, no need to enter date, time, latitude, longitude either. Might need these if I have to do auto meridian flip or slew limits.

 

M50 using PS-G2

Edited by hcf, 16 February 2020 - 12:59 AM.

  • mclewis1 and demon2030 like this


CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics