×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Mount Model lets solver crash repeatedly

  • Posts: 149
  • Thank you received: 10
Hello,

today I tried the mount model module with offline solving for the first time. I tried it several times and always the first try on solving offline let the solver process crash immediately.

Also as we were discussing the timeout for offline solving I let the solver run for more than 300 seconds this time and did NOT timeout itself, I had to stop it manually.

I will attach both logs.

Amin
Skywatcher Newton 200/1000, Sharpstar 60ED, Canon Lenses
Skywatcherr EQ-6 R, AZ-GTI
StellarMate @ Raspberry Pi 3B+
ASI 183 MC Pro
ASI 290 MC guiding cam on APM 60 ImageMaster
Sesto Senso 2 Focuser + Astromechanics Canon Focuser

5 years 8 months ago #27823
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
Hello Amin,

Astrometry.net is a great program but it is complex and requires a lot of settings to be right in order to work in offline mode. There are many things that could be incorrect that could cause it to fail. Did you read the Quickstart document that I distributed with the KStars DMG? Did you follow all of the instructions there for setting up astrometry.net for offline plate solving? Are all of the settings correct in the alignment module for doing the offline solving? Is Verbose mode turned on so you can see what is going on? Have you downloaded all the needed Astrometry index files? And a big question, do you have any spaces in the path to where you installed the KStars.app application bundle?

Did you try just a "Capture and Solve?" The Mount Model tool is more complex, but it just basically slews the scope to a series of different locations and then uses "capture and solve" multiple times. Does your offline astrometry.net solve any image using just simple capture and solve? Does astrometry fail or crash immediately or does it try for awhile and then fail? These two possibilities mean very different problems. If it crashes immediately, then it is almost certainly an issue with spaces in your KStars path or one of your astrometry settings has a serious problem. If it tries for awhile to solve and then fails, then it is either that you do not have the right index files or you need to tweak some astrometry settings.

Also I hope you are testing this and setting up plate solving with simulators inside during the daytime before trying it outside under the stars when you could be imaging great things.

Thanks,

Rob
5 years 8 months ago #27830

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
I had difficulties to get the remote solver to work at the beginning because astrometry.net is not clear enough on how it works behind the interface. Once I understood that it had to match rotated and/or reversed star tris and quads in index files corresponding to the actual FOV of my telescope, and that it would spiral from the expected position to find a match, it was easier to speculate on why it would fail.

On my slow 1.6Ghz single-cpu, the solver will take 80 seconds to find a target 9 degrees away, 30 seconds for 1 degree away and 20 seconds for 50 minutes away. Not great but enough for my use.

It really depends on where you point and where you expect to point at the very first solve. The fact that the public web interface of astrometry.net searches the whole sky and catalog is causing confusion when configuring. But in terms of configuration, the only item to work on on a local astrometry.net is the list of indexes.
Be warned that simulators must be configured exactly like your physical setup for this not to become a headache when switching.



-Eric
5 years 8 months ago #27845

Please Log in or Create an account to join the conversation.

  • Posts: 149
  • Thank you received: 10
Thanks for your deliberate replies.

Offline solving worked well for me when doing the usual alignment - except for the timeout that never seem to happen. So I am not sure if my settings are that incorrect. By the way, a software should not crash due to incorrect settings, it should give an error message.

It crashed immediately the first time I started mount model, than tried a second time and did not timeout.

The missing timeout is actually my bigger problem right now as this makes it unusable, because I always risk of getting stuck.

I downloaded all required and recommended files, left out the optional ones. I have a field of view of 45 x 30 arcmins with the cam on the primary scope.

I am not sure about the binning, I left it to 1x1, I use the ASI 183 MC Pro, which has very small but many pixels, do you think, I should try binning 2x2? Would that also decrease the transmission time of the image? So far it takes more than 1 minute to get the image from the Raspberry Pi to my KStars client on my local WiFi.
Skywatcher Newton 200/1000, Sharpstar 60ED, Canon Lenses
Skywatcherr EQ-6 R, AZ-GTI
StellarMate @ Raspberry Pi 3B+
ASI 183 MC Pro
ASI 290 MC guiding cam on APM 60 ImageMaster
Sesto Senso 2 Focuser + Astromechanics Canon Focuser

5 years 8 months ago #27846

Please Log in or Create an account to join the conversation.

  • Posts: 149
  • Thank you received: 10

But this is what it should do in the mount model module, right? Replace the manual star alignment you usually would do with the handset. If it is not feasible to do that offline, because you could be way off, than maybe we should have an option to overwrite the offline solving setting just for the mount model module?

If I remember correctly the worst distance the online solver calculated was something about 1700 arc seconds.
Skywatcher Newton 200/1000, Sharpstar 60ED, Canon Lenses
Skywatcherr EQ-6 R, AZ-GTI
StellarMate @ Raspberry Pi 3B+
ASI 183 MC Pro
ASI 290 MC guiding cam on APM 60 ImageMaster
Sesto Senso 2 Focuser + Astromechanics Canon Focuser

5 years 8 months ago #27850

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
Hi Amin,

To begin to investigate your problem we need to see what is happening. I need to clarify some things you said,

You keep saying "it crashed" but I am still not clear on what you mean. Remember there are multiple programs involved here. Do you mean that kstars itself crashed? This would mean that all of kstars crashed and disappeared from your screen. Do you mean that astrometry.net crashed? This could happen and kstars would still be open. When you say "crashed" are you meaning that the process abruptly stopped with a fault or do you mean that it just did not solve the field? As to an error message, depending on what happened, which program "crashed," and why it crashed, there may or may not be able to be a message. If an error is caught, then a program doesnt actually "crash" per se, it could just print an error message.

What do you mean the usual alignment? Do you mean that you used kstars to slew to a star or object, then you pressed the "capture and solve" button in the align module to plate solve the field and tell your mount where it is using the offline solver?

What so you mean by the timeout? Are you plate solving and then waiting 5 minutes for it to finish? Is it going through the list of index files and printing all the ones it tries? A plate solve should pretty much always take less than one minute if everything is configured right. Most of the time its a couple of seconds.
5 years 8 months ago #27852

Please Log in or Create an account to join the conversation.

  • Posts: 149
  • Thank you received: 10
Hi Rob

The plate solving only crashed. KStars itself remained open and started a new try immediately, which never times out. MacOS itself displays a popup message with the text KStars crashed with an error log (my file "solver crash") that should help to investigate the root cause.


Exactly, either manually or via the scheduler, both works fine - except for the missing timeout.

I am referring to the timeout set in the config for 300secs when the off-line solving process should be stopped with "solver failed". You can see in my 2nd file "solver log" in the first line, that I actually manually aborted offline solving after 383 seconds. With a timeout set to 300secs, it should have aborted it automatically before.
Skywatcher Newton 200/1000, Sharpstar 60ED, Canon Lenses
Skywatcherr EQ-6 R, AZ-GTI
StellarMate @ Raspberry Pi 3B+
ASI 183 MC Pro
ASI 290 MC guiding cam on APM 60 ImageMaster
Sesto Senso 2 Focuser + Astromechanics Canon Focuser

The following user(s) said Thank You: Rob Lancaster
5 years 8 months ago #27854

Please Log in or Create an account to join the conversation.

  • Posts: 125
  • Thank you received: 24
Did you try 2x2 or 3x3 bin? for plate solving this should help in speeding up the process.

Also if you can attach the ekos debug log that should help understanding what is the command sent to solver process.
5 years 8 months ago #27860

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
Amin,

Thank you for the clarifications, they will help with diagnosing the issue. We don't have control over astrometry.net's error messages or crashing, since we dont write the program, we can only try to deal with it and prevent it from happening. The good news is that it doesn't normally crash, there are a narrow set of things that can cause it to crash and we can figure out what it is.

Does it successfully solve and print out that it found a solution every time you hit capture and solve manually, or does it ever crash then?

Yes, astrometry should time out after the 300 second limit, we should look at whether we set the option correctly, but if we did then its an issue for astrometry.net. But definitely don't let it go that long Amin, it should solve much faster if settings are right.

Did you turn on verbose logging in the astrometry options? That will help big time. You need to see what it is doing. We need to know when it fails. If it is right away and it doesnt show a long list of files it is searching, then we have a clue.
5 years 8 months ago #27876

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
"With a timeout set to 300secs, it should have aborted it automatically before."

For the sake of precision, actually no. This is documented as cpu time, not system time. Because most of the preliminary work to searching is loading indexes, that timeout is actually a lot more than 300s. "A lot more" depends on the system on which solve-field executes. On Linux, one can use the command "time" to measure the user-space cpu activity duration of a command.

Why this weird configuration setting? Probably a way for services to focus on resources instead of latencies.

-Eric
5 years 8 months ago #27880

Please Log in or Create an account to join the conversation.

  • Posts: 2876
  • Thank you received: 809
Interesting, I didn't know that Eric. I will have to see if they have documented this about the timeout. I would have assumed just like Amin, that the timeout of 300s means 5 actual minutes.
5 years 8 months ago #27882

Please Log in or Create an account to join the conversation.

Time to create page: 0.288 seconds