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

Electronic Finderscope for visual

  • Please log in to reply
12 replies to this topic

#1 knight_parn

knight_parn

    Mariner 2

  • -----
  • topic starter
  • Posts: 212
  • Joined: 03 Oct 2018
  • Loc: Peterborough, UK

Posted 21 December 2020 - 11:08 AM

Just want to share this little diy project I've been doing recently. It's a portable solution for highly accurate GOTO (plate solve) for visual users. It works in a similar way to Celestron Starsense, but costs a lot less and supports any mounts that can be used with INDI. I'm sure someone must have done it before, but I'd like to share my experience.

 

20201221_122632.jpg

 

The parts that I've used are:

  • a spare Altair Starwave 50mm guidescope (also works with Skywatcher/Orion/Celestron 9x50 finderscope and a C mount adapter)
  • RPi 4B 4GB (In fact the 2GB model is sufficient. It's just that I only had a 4GB one laying around)
  • RPi HQ Camera with a 1.25 to C adapter
  • Pimoroni Pi4 case + PiHut camera plate
  • 5V/3A USB powerbank
  • 16GB MicroSD card

The above cost about £200 altogether and if I were to the SW 9x50 finder and a RPi 4B 2GB instead, I could shave off another £40 (or £80 if you've already got a spare 9x50 straight-thru finder).

 

The software components here are INDI, KStars/Ekos and ASTAP/Astrometry.net. These should be quite familiar to anyone who does imaging. I used the Astroberry image to install them onto my RPi. But they can also be installed separately through ubuntu or Raspberry Pi OS (aka Raspbian).

 

Here are the steps I've taken to make it work:

  1. Flash the MicroSD with the Astroberry image
  2. Connect to the access point "astroberry" on my laptop (It's a lot more convenient to use a laptop for the initial configuration. After that a tablet or phone would be fine)
  3. Access the desktop via the browser NoVNC (a VNC viewer can also be used as an alternative)
  4. Make the RPi connect to my home wifi temporarily in order to get all the updates via apt
  5. Enable "Direct Capture" in the RealVNC server on the RPi
  6. Align the finderscope to my main scope by using the preview of the RPi HQ camera. The preview can be accessed with either the raspistill executable (no reticle) or my own python script (red reticle overlay on the preview). Attached File  efinder_preview.zip   773bytes   13 downloads
  7. Create an INDI profile of the mount and the RPi HQ camera (as Guider not the main CCD). Then connect
  8. Enter the correct focal length and aperture of the telescope and guidescope (206.6mm for my Starwave 50mm. 180mm if using 9x50 finderscopes)
  9. Find a target to view through KStars
  10. Go to the Alignment tab in Ekos. Open options and select local ASTAP as the solver (or astrometry.net if the required index files have been downloaded)
  11. Set action to "slew to target", exposure to 5 sec, bin to 1x1, scope to Guidescope and FOV to 104' x 78.6' (Can be calculated with many fov calculators available online e.g. astronomy.tools)
  12. Start "Capture & Solve"

The plate solve will make sure the target I've chosen is going to be right in the centre of my eyepiece. So no 2/3 star alignment is required. Plate solving with ASTAP on a RPi 4B is very quick, just a couple of seconds. It's also doable on a RPi 3B/3B+, but the UI in VNC is a little sluggish. RPi 3A+ is a no go due to insufficient RAM (512MB only) unless KStars/Ekos is offloaded to a laptop, but then it's no longer as portable.

 

If you'd like to give this a try yourself, a few things to remember:

  • 5V/3A power source is recommended even though I've also tested with a 2.5A power supply and it worked. If your field battery is big enough to support both the mount and the RPi, a powerbank will not be required.
  • Both INDI and alignment preview maintain an exclusive access to the camera. So make sure these two programs don't run at the same time.
  • Polar Alignment in Ekos also works. But unless you have a big screen tablet, it will be very difficult to see the correction vector (certainly not possible on my 7" tablet). In my case, my iEXOS-100 was only roughly aligned to the NCP
  • Plate solving only works with either ASTAP or astrometry.net. The new internal solver introduced in a recent version of the KStars/Ekos always fails.
  • Bin must be set to 1x1 or else Ekos will replace your correct FOV with a wrong calculated value which makes plate solving fail.
  • Mount model works only intermittently. Since you're already using plate solving to center the target, don't bother with it
  • The plate solving can fail occasionally. When that happens, just do a "clear all" in the solution table and re-issue another "capture & solve".
  • Sometimes the target is already in the centre after the 1st solve, but Ekos will attempt more corrections. When it happens, just click/tap on the "Stop" button.

 

If anyone has already tried this before, I'd like to hear your experience and if you've got any suggestions to improve it further.


Edited by knight_parn, 21 December 2020 - 11:26 AM.

  • astrokeith, Oregon-raybender, synfinatic and 6 others like this

#2 meansrt

meansrt

    Mariner 2

  • *****
  • Posts: 275
  • Joined: 05 May 2020

Posted 21 December 2020 - 11:11 AM

Very cool! I love DIY ideas and have been looking into switching to the Pi from Arduino so I may give it a try!



#3 hcf

hcf

    Viking 1

  • -----
  • Posts: 802
  • Joined: 01 Dec 2017

Posted 21 December 2020 - 12:09 PM

Nice project !

 

Here is something similar, I did for a platesolved Goto DIY motorization of a manual mount using an action cam and 50mm lens and stepper motors.

 

It connects to Sky Safari Pro for the user interface for GoTo, and does platesolving to center the target "under the hood" automatically on a GoTo.

 

Total cost of camera,lens, electronics, stepper motors, Pi about $200. The entry level manual EQ mount cost me about $100. The camera+lens can also be used for a PushTo connected to Sky Safari for other non motorized scopes using similar concepts.

 

https://www.cloudyni...-project-ps-g2/

https://www.cloudyni...sual-astronomy/


  • knight_parn likes this

#4 Gobo333

Gobo333

    Explorer 1

  • *****
  • Posts: 68
  • Joined: 20 Sep 2019
  • Loc: Los Angeles, CA

Posted 24 December 2020 - 01:09 AM

Poked around same concept with an ASIair & mini guide scope. Works great!  I actually found the 30mm mini scope plate solved WAY faster than the same camera in an ST80. 

 

 

Attached Thumbnails

  • 72B2AE26-0A5D-495C-8C9F-C098D3DE4AC2.jpeg


#5 astrokeith

astrokeith

    Viking 1

  • -----
  • Posts: 555
  • Joined: 14 Mar 2010
  • Loc: Surrey, UK

Posted 30 December 2020 - 11:03 AM

Just want to share this little diy project I've been doing recently. It's a portable solution for highly accurate GOTO (plate solve) for visual users. It works in a similar way to Celestron Starsense, but costs a lot less and supports any mounts that can be used with INDI. I'm sure someone must have done it before, but I'd like to share my experience.

..........

If anyone has already tried this before, I'd like to hear your experience and if you've got any suggestions to improve it further.

Hi,

I was intrigued by what you had done and thought I would have a go at it too.

I'm new to Astroberry (bit of an Indigo person!), and finding it very non-intuitive. Basically I'm stuck.

 

I've got Astroberry flashed in, seems to run well on a RPi4B 4GB

I can see my RPIcamera is working as I can test it from the command line.

I'm guessing I havent set up the Indi profile correctly.

Under Configure Equipment i've got my scope entered OK

I've gone to Device Manager in KSTARS and the 'RPI Camera' is listed in the Local/server tab. IS this driver right as its not 'HQ'

So far no choices about main scope or guider.

I open EKOS

I've created an EKOS profile putting the RPI and scope as guider.

In EKOS I've only got three main table. setup - scheduler - analyse. I dont have the 'capture - align - guide' ones etc. (I'm looking at a KSTARS manual on-line)

If I try 'start' anyway - i get an error "Driver indi_rpicam was not found on the system. Please make sure the package that provides the 'indi_rpicam' binary is installed"

 

Update:

I downloaded the indi rpicam driver directly from the indi site. Now I have an Indi Control Panel. :-)

 

I now have more to play with so I'll see how I get on.

TIA

Keith


Edited by astrokeith, 31 December 2020 - 09:35 AM.


#6 astrokeith

astrokeith

    Viking 1

  • -----
  • Posts: 555
  • Joined: 14 Mar 2010
  • Loc: Surrey, UK

Posted 31 December 2020 - 12:54 PM

Moved on a bit since my last post.

Understanding Astroberry is key. Its not intuitive and so progress is slow. I can see it is powerful though.

 

I can now capture FITS images from the RPi HQ camera. Hurrah!

 

Whilst researching some of the background to plate solving, I can see now I might want a cutdown solution. Astroberry is more than I need, or rather it will complicate the final solution.

 

I have a Goto Dob (18" F4.7) driven by ScopeDog (similar to ServoCat), using a Nexus DSC for scope orientation and SkySafari for overall control.

 

My perfect solution is going to be to electronically insert the RPi & its camera/viewfinder between the Nexus DSC and ScopeDog.

I'll write a program that intercepts the serial data coming out of Nexus before sending it on to the scope (ScopeDog).

That way I'll know where the rest of the system 'thinks' it is pointing.

I'll put an extra button at the eyepiece. When the scope has gone to the commanded position, I can if I want, press the button and the RPi will take an image and plate solve it using the RA & Dec it is expecting.

This will give me a displacement (error in actual pointing)

I can use the displacement to send adjustment signals to ScopeDog either via its handbox controller (easy), or via a spare USB port.

 

I enjoy looking for the really hard to see targets. often they take some time to see, even when they are in the field. This was I'll know the field is right and can concentrate on looking.

 

I can see that over the course of a night, I could build up a map of pointing errors. This could help with scope upgrades.



#7 astrokeith

astrokeith

    Viking 1

  • -----
  • Posts: 555
  • Joined: 14 Mar 2010
  • Loc: Surrey, UK

Posted 31 December 2020 - 12:57 PM

Key to this is capturing the RPi HQ image in FITS format.

 

The RPi captures and saves it as a RAW 16bit image file. I just have to find a way to convert it.

 

Anyone done this - otherwise I can see myself writing my own python routine (definitely beyond my current programming capability!)



#8 hcf

hcf

    Viking 1

  • -----
  • Posts: 802
  • Joined: 01 Dec 2017

Posted 31 December 2020 - 02:43 PM

Key to this is capturing the RPi HQ image in FITS format.

 

The RPi captures and saves it as a RAW 16bit image file. I just have to find a way to convert it.

 

Anyone done this - otherwise I can see myself writing my own python routine (definitely beyond my current programming capability!)

You should be able to solve jpeg images using a copy of astrometry.net running locally on the pi.

I would think, raspistill should be able to get a  jpeg image from the HQ camera.

 

I did a platesolving pushto and a platesolving goto  using astrometry.net and python scripts with Sky Safari Pro as the user interface. I used an inexpensive IP cam, but the Pi HQ camera and a 35-50mm lens should work as well.

 

Links are in my prev post.


Edited by hcf, 31 December 2020 - 07:53 PM.


#9 astrokeith

astrokeith

    Viking 1

  • -----
  • Posts: 555
  • Joined: 14 Mar 2010
  • Loc: Surrey, UK

Posted 01 January 2021 - 07:52 AM

You should be able to solve jpeg images using a copy of astrometry.net running locally on the pi.

I would think, raspistill should be able to get a  jpeg image from the HQ camera.

 

I did a platesolving pushto and a platesolving goto  using astrometry.net and python scripts with Sky Safari Pro as the user interface. I used an inexpensive IP cam, but the Pi HQ camera and a 35-50mm lens should work as well.

 

Links are in my prev post.

Thanks for this reply ( i had seen your earlier postings - nice work)

 

I saw that all the index files on astronomy.net were fits, so assumed I would have to work in 'fits' space. I can definitely get .jpg from the raspberry HQ camera. I'll look into this. Could simplify things a lot. The more I read the astronomy.net website info, the more I think I am better off without astroberry.

 

My current goto system gets to within about 20 arcmin, most of the time. As I said I'm usually looking for really faint objects, or parts of objects. I currently spend a lot of time checking the field is right, re-centering etc, before I get around to looking for the target.

 

I was hoping to have a very small field of view in my 'finder scope/camera' say about 1deg max. This would make the 'auto-entering' really accurate. I guess small field of view means longer to plate solve, but it takes me 10 minutes sometimes to check and correct a field manually so I'm OK.

 

My scope is a Dob, so Alt Az of course. So my captured images will be rotated. I can work out what it is if that helps the solver? Similarly once I have a solve, the answer in RA & Dec, will need to be converted to Alt Az - no problem as I'm doing this all the time in my ScopeDog.

 

As I will always be only be 10's or arcmins away, I can use my standard slow motor speed to adjust. Biggest issue may be backlash in the drives (Planetary gearboxes on the nema steppers)

 

For info here's a couple of photos of my rig,

Attached Thumbnails

  • IMG_3783.jpeg
  • IMG_3791.jpeg

  • Joko, hcf and Gobo333 like this

#10 hcf

hcf

    Viking 1

  • -----
  • Posts: 802
  • Joined: 01 Dec 2017

Posted 01 January 2021 - 12:15 PM

One of the issues with a  smaller FOV for the E finder, is it will need a longer lens which will be heavier. You might also need a longer exposure to get enough stars to solve.

Platesolving will take longer, but you can specify the approx location (the target) and search in a nearby radius to speed things up (-ra -dec flags to solve-field). Because my finder FOVs are larger (5x7 deg), and solving is fast, I don't need to do this, and do a blind platesolve every time.

 

You will also have to align the e-finder to the main scope FOV accurately (and keep it aligned), which can be a challenge for the accuracy you desire. I use a Orion Precision Slow-Motion Adapter, but it adds to the weight.

 

The rotation angle of the image should not matter, you are getting the coordinates of the center of the image. Regarding Alt/Az vs RA/Dec there are two ways to do corrections to a GoTo.

 

1. Offset slew: This is what I do for my PS-G2, this figures out the delta and does an slew with the correcting offset. This would need you to convert RA/Dec to Alt/Az. pyephem/Astropy packages can help you do this.

 

2. Sync and GoTo: Once you figure out where the scope is pointed using platesolving, you do a sync/align telling the controller where you are at. Then you do a GoTo slew to the target again. This might not need you convert RA/Dec to Alt/Az if your controller can do Syncs and GoTos to RA/Dec coordinates.


Edited by hcf, 01 January 2021 - 09:32 PM.


#11 astrokeith

astrokeith

    Viking 1

  • -----
  • Posts: 555
  • Joined: 14 Mar 2010
  • Loc: Surrey, UK

Posted 01 January 2021 - 01:02 PM

Thanks

I have an old Vixen 70S I intend to try out first. It has really stable offset adjustment built in which I've tested before.

Weight is of no issue - the Dob OTA weighs about 40kg and in fact has a 2kg counterweight at the bottom I can swap for the efinder.

 

I can handle the maths easy enough to do the coordinate conversion and calculate the correction drive pulse lengths. I'm thinking at first I will add a simple ST4 style guider input into my ScopeDog and 'nudge' the scope to the corrected position via that. This will require no software mods to ScopeDog - it works well and is stable so I dont want to mess with it unless I have to.

 

The SkySafari - Nexus DSC combination provides a Align/Sync function, which I can carry on using. Having done a 'goto' they will be thinking I am still on that target even after the efinder has done its correction, so I can use their align/sync.

 

I think next stage is to capture a set of test images with the RPi HQ camera and Vixen 70S which I can then use to experiment with. I need to buy a C mount to 1 1/4" adapter first - though I had one.

Attached Thumbnails

  • IMG_4025.jpeg

  • knight_parn likes this

#12 bentleyousley

bentleyousley

    Sputnik

  • *****
  • Posts: 42
  • Joined: 05 Aug 2011

Posted 08 January 2021 - 10:50 AM

 

 

My perfect solution is going to be to electronically insert the RPi & its camera/viewfinder between the Nexus DSC and ScopeDog.

I'll write a program that intercepts the serial data coming out of Nexus before sending it on to the scope (ScopeDog

 

 

I have a similar ServoCat/ Nexus DSC /Sky Safari setup and I've worked on-and-off trying to do an automated dob plate-solve system with INDI/RPi. One thing I've found, is that if you use an LX200 configuration on INDI and on SkySafari _and_ connect both the RPi and SkySafari via WiFi to the Nexus DSC, any scope movement or sync command will be received and cause an update on all of the components. In other words: if you do a GOTO on Sky Safari,  Nexus will begin the slew _and_ INDI will update (and vice versa).

 

I mention this because you may want to try this before spending time programming a complex serial-send/receive routine. 

 

This is exciting stuff. HCF has done some terrific work in this area. He recently referred me to this thread:

 

 

https://www.cloudyni...ble/?p=10663301

 

 

I contacted Gord(the author) and he is working on refining his INDI script to include features such as:

 

   Automatic offsetting of the camera to accommodate imprecise alignment between the visual telescope and the camera telescope.

 

   Automatic plate solve and position correction after a slew.

 

   System defeat switch for manual slewing.


  • hcf likes this

#13 knight_parn

knight_parn

    Mariner 2

  • -----
  • topic starter
  • Posts: 212
  • Joined: 03 Oct 2018
  • Loc: Peterborough, UK

Posted 29 January 2021 - 03:43 PM

Update 29 Jan 2021:

20210129_174950.jpg

 

Made a couple of modifications:

 

1. Changed the optics from an expensive 50mm guidescope to the cheap SW 9x50. Now the eFinder is in its absolute minimum cost config.

 

2. The more important change is the addition of the physical GPIO button. Now instead of going through the overwhelming UI of Kstars/Ekos just for plate solving, all I need to do is to issue a "Goto" to a target, and then press the physical button to plate solve and centre the target. Kstars/Ekos still needs to run on the RPi for my python program to talk to it via DBus.

 

I actually tried with direct INDI connection with another python program I wrote. GOTO and image capturing were working fine, but I could not get ASTAP cmdline to plate solve consistently. Maybe I'll look into local astrometry.net cmdline "solve-field", but it seems a lot more complicated than ASTAP.

 

Ekos plate solve has a tendency to enter an endless loop of capture & solve because it thinks the accuracy hasn't been met despite the fact the target is already centred in the eyepiece. I made my python program so that it will abort after the first solve if Ekos is stuck in the loop. If it turns out that the target is still outside of the fov (very unlikely), I can always manually do another solve by pressing the button.

 

Now the problem is to find an android based INDI client that offers both GOTO and basic telescope controls with simple UI. So far there are 3 potential candidates: Kstars Lite, Telescope.touch and SkySafari 6 Plus. Kstars Lite is no longer supported and very slow, so it's out. Telescope.touch is a new program made by a very bright chap on INDI forum. It's based on INDI Java library, so has very good potential. But at this early stage it cannot even perform "Goto" without crashing. SkySafari 6 Plus isn't free and comes bloated with many features that aren't required for my particular use. Anyone got any good suggestions on this?


Edited by knight_parn, 29 January 2021 - 03:48 PM.

  • bentleyousley likes 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