×

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

Bi-monthly release with minor bug fixes and improvements

On Raspberry PI, the solver does not work with the Ekos alignment module.

  • Posts: 173
  • Thank you received: 24
I am using Stellarmate.
INDI is 1.9.9 and KStars is 3.6.2.

When I run the solver on the Ekos alignment module on the Raspberry PI, it stays running for a few minutes and then fails.

The alignment log in the Ekos debugger shows 4 threads started and 3 threads terminated immediately after the solver run started.
No further details are shown in the log.

If I start the same Raspberry PI INDI in Web Manager and use Windows KStars, the solver succeeds.

The execution conditions, such as the device, Index file, object to be photographed, exposure time, etc., are the same for Raspberry PI and Windows KStars.

What else should I investigate?
1 year 3 months ago #88935

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

  • Posts: 437
  • Thank you received: 31
I assume this is the same as my original issue.

Solver is not working.

Paul
Last edit: 1 year 3 months ago by Paul.
1 year 3 months ago #88938

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

  • Posts: 173
  • Thank you received: 24
I have already seen your post.
It is very similar in terms of external observations.
I put it in a separate thread just in case because there is no evidence to determine if the actual cause is the same.
And it would be confusing to post in your thread if it was a different cause.
1 year 3 months ago #88939

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

  • Posts: 173
  • Thank you received: 24
The investigation is in progress, but here are a few things we found out.

The solver succeeds when the Solving method is set to "Online Astrometry" or "Local Astrometry."
However, "Local Astrometry" is too slow to be practical.

"Internal Solver" is taking even longer: 8 minutes have passed and it is still not finished.
It is not a blind solver.

After reading the index files, the process continues to think for a while.
Also, when I look at the processes with ps -efL, one of the kstars threads has a high CPU load.
I know that this thread is stellarsolver by tracing it with gdb.
stellar+ 84265 4889 84265 17 21 20:24 pts/3 00:15:18 kstars
stellar+ 84265 4889 84268 0 21 20:24 pts/3 00:00:03 kstars
stellar+ 84265 4889 84271 0 21 20:24 pts/3 00:00:00 kstars
stellar+ 84265 4889 84340 0 21 20:24 pts/3 00:00:01 kstars
stellar+ 84265 4889 84375 0 21 20:24 pts/3 00:00:00 kstars
stellar+ 84265 4889 84377 0 21 20:24 pts/3 00:00:00 kstars
stellar+ 84265 4889 84378 0 21 20:24 pts/3 00:00:00 kstars
stellar+ 84265 4889 84394 0 21 20:24 pts/3 00:00:00 kstars
stellar+ 84265 4889 84913 0 21 20:25 pts/3 00:00:13 kstars
stellar+ 84265 4889 84920 0 21 20:25 pts/3 00:00:04 kstars
stellar+ 84265 4889 85021 0 21 20:25 pts/3 00:00:00 kstars
stellar+ 84265 4889 85044 0 21 20:25 pts/3 00:00:04 kstars
stellar+ 84265 4889 85047 0 21 20:25 pts/3 00:00:04 kstars
stellar+ 84265 4889 85123 0 21 20:25 pts/3 00:00:12 kstars
stellar+ 84265 4889 85178 0 21 20:25 pts/3 00:00:05 kstars
stellar+ 84265 4889 85709 0 21 20:25 pts/3 00:00:00 kstars
stellar+ 84265 4889 100637 0 21 20:46 pts/3 00:00:04 kstars
stellar+ 84265 4889 100638 0 21 20:46 pts/3 00:00:04 kstars
stellar+ 84265 4889 100639 0 21 20:46 pts/3 00:00:04 kstars
stellar+ 84265 4889 100640 0 21 20:46 pts/3 00:00:04 kstars
stellar+ 84265 4889 137995 84 21 21:38 pts/3 00:10:48 kstars <- this is stellarsolver's thread
1 year 3 months ago #88958

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

  • Posts: 173
  • Thank you received: 24
This issue has been resolved.
"StellarSolver Options" and "Scale & Position" were returned to default to allow realistic speed in plate solving.
1 year 3 months ago #88960

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

  • Posts: 437
  • Thank you received: 31
tkakura,

If you have solved this by setting the values back to the defaults then this is probably a different issue to the one I have.Would it be possible to say what the values were that caused the issue.

Paul
1 year 3 months ago #88984

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

  • Posts: 173
  • Thank you received: 24
Solver now succeeds when I change it back to the default, but I have not investigated the cause.
However, I am not sure which item made Solver succeed.

See the attached figures for the changed values.
When I reverted to the defaults, they changed from Fig.1-1 to Fig.1-2 and from Fig.2-1 to Fig.2-2.。


Fig.1-1 StellarSolver Options on solver errors


Fig.1-2 Default value StellarSolver Options


Fig.2-1 Scale and Positoins on solver errors


Fig.2-2 Default value Scale and Positinos
1 year 3 months ago #88990
Attachments:

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

  • Posts: 1208
  • Thank you received: 559
A Common issue/solution is that the wrong scale or position is passed to the solver, causing the solver to spin its wheels looking in the wrong place or at the wrong scale. Thus, often when people have solving issues, unchecking Use Scale and Use Position helps. That said, in @tkakura's screenshots he shows unchecked Use Position and unchecked Use Scale as failing. Note that in his screenshots, the failing positions and scales values are quite different from the successful ones.

@Paul, you should know what your true scale and true approximate position is, so make sure those are about right if you do use Position and Scale, and see if it works. It could be your system was somehow initialized to a bad value. I have definitely seen cases where for whatever reason, the scale is filled in with a wrong scale, and if use-scale is checked, the solver has no hope of succeeding. Also, make sure you're in focus.

A Raspberry Pi 4, being a slower CPU, could use the position and scale to improve response time, but only if they're reasonably accurate.

If things don't work, can you upload (e.g. google drive with a link here) an image you can't solve. That is, capture an image with the same exposure/binning/focus as align uses.

Hy

PS "Blind solves" and non-blind solves aren't really that different. That is, the solvers find star patterns in the test image and then search for those patterns in their data files. So, they all start somewhere. I suppose the difference between a blind and non-blind solve is that in the blind solve, the solver starts at some random place (like RA=0, DEC=0, scale=1) and then continues looking at all possible scales and positions. With non-blind solves the start from the suggested position and scale and searches nearby before looking further away (within the constraints given, e.g. possibly the high/low scales, possibly the search radius, the runtime constraint). In the align module, I believe if you don't check use-position, the solver will start from where the telescope module claims it's pointing (so it's not really "blind").
1 year 3 months ago #89005

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

  • Posts: 437
  • Thank you received: 31
This should probably go on the original issue.
I think my issue is a software issue as it did not happen prior to recent updates.
The build is from Sunday and is still failing.
I have set values back to defaults.
To clarify this further, the telescope is pointing in the approximate postion and does solve once, using blind solving (which it never used to do) it does this in about 1.5 seconds.
Any further attempts to solve always fail.
Paul
1 year 3 months ago #89013

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

  • Posts: 173
  • Thank you received: 24
So my case is not a bug but simply a misconfiguration.

I usually have no problem with Windows KStars as a client, so I had no idea that the Scale & Position setting of KStars on my Raspberry PI was improperly set.
1 year 3 months ago #89024

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

Time to create page: 1.186 seconds