PS-G2 : A PlateSolved GoTo
A project to add GoTo to a manual EQ mount using platesolving iteratively to achieve accuracy.
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:
- 2 Nema 17 stepper motors Model Number: JK42HM48-1504 Costs about $22 each
- 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.
- 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.
- 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.
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:
- Figures out the RA and DEC to GoTo by looking up a table using the DSO name.
- Takes an image and platesolves it to figure out current location. Say this is RA1 and DEC1
- Sends the arduino a command "G (RA-RA1) (DEC-DEC1)" to try to move to the destination
- Waits for the arduino to finish slewing and goes back to step 2 to try again.
- 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
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.
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.
Some more screenshots in the album:
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.
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
- 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.
- 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.