Astro Tortilla

[technofetishism]

Has anyone here had a play with this piece of software for plate-solve syncs?

Looks to be a good way to improve goto accuracy for those ascom inclined.

Just waiting to get a copy of the astrometry.net index files before hopefully testing it out next clear night.

[technofetishism]

completly sold on this for polar alignment, sub arc minute without too much work.

[alistairsam]

Hi
It does sound good and i do want to try it out.
Is the astrometry.net index a paid product or open source?
Is there a windows version? Didn't see the link for the index files on the site

[technofetishism]

the index files for astrometry.net are free, but not opensource.

http://trac.astrometry.net/browser/trunk/src/astrometry/GETTING-INDICES


Astrotortilla iteslf runs under windows and uses cygwin to do the astrometry.net platesolves.
http://sourceforge.net/p/astrotortilla/home/Home/

The install guide is worth reading as it gets you past a couple potential sticking points.

[SteveInNZ]

Do you have a standalone (no internet required) installation with local indices ? How much disk space does it require all up ?

[technofetishism]

Yeah, standalone. I dont think astrotortilla currently does web lookup.

Im only using the first 1 Gb worth of index files, down to 11 arcminutes, the whole index for all sky down to 2 arcminutes is about 26Gb I think. I might even be able to get away with less, but 1Gb is nothing in the scheme of things


From the README on astrometry.net

---------------------------------------------------------------
Index Filename Range of skymark diameters File Size
(arcminutes) (MB)
---------------------------------------------------------------
index-210+.tar.bz2 60 - 2000 29
index-209.tar.bz2 42 - 60 30
index-208.tar.bz2 30 - 42 61
index-207.tar.bz2 22 - 30 125
index-206.tar.bz2 16 - 22 255
index-205.tar.bz2 11 - 16 526
index-204.tar.bz2 8 - 11 1,023
index-203.tar.bz2 5.6 - 8.0 2,089
index-202.tar.bz2 4.0 - 5.6 4,260
index-201.tar.bz2 2.8 - 4.0 5,878
index-200.tar.bz2 2.0 - 2.8 10,058
--------------------------------------------------------------

[g__day]

Looks very interesting - I think I will try this soon too!

[g__day]

Plate solved a 15 second shot of M20 in under 40 seconds for the first time! Big Whoop!

Also its not too shabby that the raw pointing of the Atlux with a SS2K-PC driving things from under the Sky6 PE and Tpoint. I'd say the the target was only a handful of arc seconds off given the image scale is 20 * 30 arc minutes!


Now I have to learn how to tune AT's parameters are faster! Possibly remove sky catalogues whose imaging scale I won't use. I have now moved the Sky Catalogue (25GB to a SSD), will be keen to see how this speeds thing up!

Software linkage was a tad tricky:
1. The Sky6 points to Vixen SS2K driver using a 70 star Tpoint Model
2. MaxPoint point to "A Sky6 controlled telescope" under ASCOM
3. AstroTortilla (64 bit) points to Maxpoint

Had to do it that way as the Sky's driver hub 32bit model isn't compatible with AT's 64 bit model.

Now have to see what happens when AT updates the SS2K's sync model. I note that the pointing ability of AT seems to be only within 1 arc minute by default - will be keen to see if its practical to go down as low as say 10 arc seconds!

[naskies]

Glad to hear you have success. I've tried AT a couple of times and never had any luck to get it work correctly - it just spends forever trying to plate solve. Any tips?

PinPoint LE (included with MaximDL) works brilliantly for me, provided the reference coordinates are reasonably close. I liked MaxPoint's ability to build a pointing model for the whole sky, but I think it's designed for higher end mounts than the typical EQ6 - every target lands on chip, but it's about ~ 10 arc min out for me.

EQMOD's N-point model, however, works well for me - provided there's a nearby triangle, most of my targets land within arc secs (or 1-2 arc mins) of centre. Having a script that can automatically slew / plate solve / sync (ala MaxPoint's automap feature) using just AT and EQMOD would be great.

[g__day]

David,

I've been using this for a day now, key points I've gained through reading are:

1. Have a shot that includes 30 - 100 stars, do this by maybe taking a 5 - 15 second shot and setting the Sigma parameter to around 70
2. Calculate your imaging scale and set your units accordingly and provide upper and lower bounds; for me that is arcsecperix as unit with a 0.2 - 0.8 range (mine is just under 0.44 arc sec / pixel)
3. I use the parameters other have suggested -H and -L and -r -c 0.02 - seem to work okay
4. I searched originally 180 degrees of sky - will try 30 degree, given my pointing that is still vast versus my current pointing.
5. Try asking on the Cloudy Nights forum for more info; the AT developers seem to hang out a bit there!

http://www.cloudynights.com/ubbthreads/showflat.php/Cat/0/Number/5792902/page/0/view/collapsed/sb/5/o/all/fpart/all/vc/1

Cheers,

Matt

Will try the -3 and -4 parameters next - get RA and DEC from mount!

[naskies]

Thanks Matthew - I'll give it a go if the weather holds up the next few nights. The index downloads are pretty slow (~ 300 kb/s on a 2 Mb/s connection) - I might try asking AARNET if they'll mirror them for us locally since there would be a good academic justification for them too.

[g__day]

Funny one tonight - I tried both x86 and x64 bit versions tonight at the scope. The 64 bit version connects to the Sky6 Telescope via MaxPoint, as this is the only 64 bit driver in the list that will work with 32 bit drivers. The 32 bit version connects direct to The SKy 6 controlled telescope driver.

With correct imaging I got plenty of plate solves - generally about 2 arc minutes off in DEC, however I had the check boxes Sync and re-point ticked and nothing! It said centering but I could detect no movement. I checked the SS2K-PC handcontroller and it still had the three original stars sync-ed - not the new one that had just been plate solved.

Is this most likely a bug in the sync and goto command?

Later I also opened a previous night's image of M20 and issued a solve and goto - it slew the scope considerably and got fair close but not perfect - about 10 arc minutes off I'd guess.

Anyone know what is likely happening or who to ask?

Many thanks,

Matthew

[g__day]

So reading the Astro Tortilla forums - https://sourceforge.net/p/astrotortilla/discussion/issues/thread/b5546e48/ - this may be an issue introduced in the last version of code. One other person has reported Centering working in v0.51 but broken in v0.52 - may try the earlier version when the clouds clear!

BTW

Tried M83 - a 600 second shot on x86 version v0.51 on a dual core Conroe2 2.3GHz machine, Windows 7 sp1 machine with 8GB RAM and a SSD - found 100 objects - took 26 seconds to solve - yah!

[g__day]

It may have been an issue with a switch setting for the ASCOM driver for the SKY - I had sync disabled to protect the Tpoint model - reckon this could have resulted in the behaviour I experienced - will test it later tonight!

[g__day]

So still more errors on the re-centering. I ensure the ASCOM driver was selected for the Sky6 and syncs were enabled, regardless of the Tpoint model, and that the Sky6 didn't ask for syncs to be confirmed.

Solved for M4 - which was a few arc seconds off in RA and an arc minute or two in DEC off, but the sync and re-slew failed. Checking the log it refused the sync because the reported RA DEC had a 44.23" pointing error - wonder what went wrong?

[g__day]

More investigation, I am beginning to suspect that the default driver that The Sky6 uses to connect to the Skysensor2000-PC isn't the latest version (2.0.6) that definitely supports Syncs. The Yahoo ASCOM group and SS2K group both confirm that AT does support sync's to the SS2K with the native driver directly connected, but not through POTH.

Maybe SS2K driver doesn't allow 3rd party software to issue a sync to it?

[g__day]

Folks,

I can report that Astro Tortilla connecting directly to the latest Vixen SkySensor2000-PC driver worked correctly; plate solve, re-sync and slew worked like a charm.

So for my needs I its something within the Sky6 that is disregarding the Sync; have posted a query to the Bisque forums - hope I get an answer!

Clouds rolled in before I could try a sync through the Sky6 using both versions of Vixen driver models (original and latest via Telescope API) with debug on.

Matthew

[g__day]

Tom Bisque got back to me that the Sky6 doesn't restrict or limit sync's - but suggested its not a great idea to pollute your Tpoint pointing model!

Bisque pointed me back at the AT guys to ask them if the error is on their side and suggested I try a simple VB script to confirm the Sky6 does allow (correctly formated syncs).

Will have a go with APT to see if it can issue a Sync to The Sky6 and even confirm that the Sky6 can issue a sync from within itself!

[naskies]

Matthew, any tips for how to configure AT? I had another go after tweaking the settings as you suggest - still no luck plate solving (timeout after 5 mins) even though I gave it the exact coordinates from PinPoint :question:

A bit frustrating really - PinPoint just works for me out of the box, and plate solves everything in about 1-2 seconds max on my 2005 era Core Duo imaging laptop.

[RobF]

How are you with VB.NET Dave? I've got some code for this in my drift alignment program if of any interest. Ironically I wrote this to do a Maxpoint type "brute force" maths versus mechanical weakness approach for my HEQ5Pro, but ended up understanding how to align my mount better and use EQMOD pier-side syncs such that a few sync points and plate solving are all I need. From memory set it up to map about 20 point each side of the pier. From memory the trickiest bit was using astrometry routines to issue alt/az slew commands (which EQMOD doesn't natively recognise- have to convert to RA/DEC before slew).

Heck, that was a lot of waffle. Ignore if I missed the mark.....:P

[naskies]

Sounds good! Before the biomedical world, I used to program COM+ components in Visual C++... so it's nice to be on the scripting/user side of that equation :lol:

My main challenge is to get AstroTortilla working :question:

At the moment, I've just been manually adding 4 points for each pier side (three spread out along the horizon plus one near zenith) which gets me pretty close to everything. When I'm about to image a target, a couple iterations of goto-capture-solve-sync seems to get me to within my EQ6's accuracy limits.

[RobF]

Actually you'd need to buy the full version of Pinpoint I've remembered now. Maxim won't let you call plate solving objects etc without that (unless you write keyboard calling scripts which is messy). I just think Pinpoint is the bees-knees in plate solving. I'd only ever tried Elbrus and found it tricky though - never Astro T.

[g__day]

Astro Tortilla seems to plate solve well once you have the image scale set well. My only annoyance with it is that it tries to correct pointing by issuing a sync - and if you're running software with a Tpoint model being protected this is a big no-no! I wish it could determine pointing error and correct without a sync being issued - but the developers say they aren't going to work on these sort of enhancements until after August.

[naskies]

Yep, I really like PinPoint - it's so fast when the target is in the search area.



Hmmm... do you provide the binned or unbinned (x1) image scale for the image scale? Maybe that was causing my grief - I provided the image scale for the 4x binning I use for plate solving, but the range wasn't wide enough to include the 1x binning image scale. I'll give it a go next time.



What about on the T point side? Is there a feature to make it ignore syncs (EQMOD has this feature)?

I'm keen to make AstroTortilla work, as I find EQMOD's model to be very, very accurate for my EQ6 - much more so than a 100 point model in MaxPoint.

[g__day]

The Sky6 can easily ignore syncs, the issue being Astro Tortilla only re-points by saying where do you think you should be - solving and re-sync'ing then going the co-ordinates again - now assuming this coords will be correctly pointed to!

What I would like is it to correct pointing without issuing the sync; say it works out is X off in RA and Y in DEC - then issue a goto currrent RA + X and Current DEC + Y - which should be simple!