Failure to solve on Raspberry PI

[nigeldun]

Following on from the indilib forum msgs I’ve finally managed to get an image. It solves using the inbuilt, local astrometry.net and astap on the Pi and also the online astrometry.net and online Watney solvers. However the local Watney just says failed. I have the watneyqd-08-09-20 and 00-07-20 quad dbs installed.

Attached are the fits file and a screenshot of the Pi

[nigeldun]

and the fits file solve1fail.zip

[Jusas]

Hi @nigeldun!

It would seem that you were indeed unlucky with this one. I'm hoping this is more of an exception than the norm for you. Looking at the log, looks like you're using the Internal SEP for star extraction, which is good. Watney also comes with its internal star detection algorithm which is quite crude but most of the time works just fine. When using KStars I've personally used the Internal SEP (with the default settings) with Watney with no problems for 99% of the time - it's good, no doubt about that.

So: internal SEP extractor is good but in case you find better and more consistent success with the Watney internal ("BuiltIn Method") star detector then maybe consider switching to that. I suppose trial and error will tell you which one works better for you. I think your case mostly boils down to pure luck with how the stars were detected and ranked and how the quads were formed from them. When there aren't a lot of stars visible, even a single star can make a big difference.

As you noted, it solved using astrometry.net, ASTAP and the Watney's online solver (it uses the Watney's own default star detector). Also running your sample FITS image through the console solver with default parameters (again using Watney's own star detector) it solved fine. I was actually worried that the bayering pattern in your image would have resulted in less accepted stars but it didn't cause any notable problems.

So as a summary, depending on a lot of things your mileage may vary. Not a very helpful answer I know ;) but it can happen. Maybe tweaking the star extractor profile or picking another profile will help to provide a better experience.

[nigeldun]

hmm, unfortunately I’ve failed every time i’ve tried to use it so it’s not just that particular image. It will be the approx same setup and exposure though so possibly a lack of stars or whatever. Is there a debug switch I can apply to get more detail as it does seem to fail very (very) quickly? Just in case it’s something like a permission’s problem or something else.

[Jusas]

I see. First things first, is your configuration correct? Is the path to the quad database correct? Secondly you can test if the image solves from command line:

cd /path/to/watney
./watney-solve blind -i /path/to/image.fits

Also to get log output, you can use --log-file /path/to/logfile.txt

The image you attached here should solve - it does for me. Also if your configuration is incorrect, it's likely you'll get an error and you can then post it here if it's cryptic.

You can also turn on the logging from KStars. Open Ekos, click the Logs button, make sure it's set to verbose and in Astrometry select LOG_ALL, tick the box to "Separate log file" and set a file name where to write the log. The next solve you make in KStars should then write to the log file.

[Jusas]

Also just in case, the wiki has a quickstart guide: https://github.com/Jusas/WatneyAstrometry/wiki/Quickstart-Guide

[nigeldun]

Ah there’s another logging switch is there. Thought I had turned them all on.

I will give your suggestions a try and see what happens.

[nigeldun]

I’ve tried running watney from the cmdline however it crashes. I’ve deleted and reinstalled both the program and quad db but with the same result. I’ve attached the log file watney.log

[Jusas]

Thanks, this was very helpful. It's indeed a bug - I'll have to take a closer look. Can you tell me which Raspberry Pi you're using, and also the operating system?

[nigeldun]

It’s a Raspberry Pi 4 4gb with astroberry 2.04 installed and updated.

[Jusas]

Oh, one more thing, can you run uname -a in terminal and post the output?

[nigeldun]

astroberry@astroberry:~ $ uname -a Linux astroberry 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux astroberry@astroberry:~ $

[Jusas]

Thanks!

I ran this on my Pi4B running Ubuntu Mate 64bit and that seemed to run fine using the arm64 build. I did run the benchmarks using this setup so I'm fairly sure it's fine. Now going back to my old Pi (it's Pi2 I think, and installed Raspberry Pi OS 32bit on it) I managed to reproduce this bug - this should significantly help to nail this down. So I think the 64bit OS has no issues but the 32bit does.

I can't yet say how easy or quick it is to fix this but now at least I can confirm it and work on it.

[Jusas]

@nigeldun I just pushed a fix, and on my end it looks like this did indeed fix the issue. Can you please confirm by downloading the latest development build (the ones with "latest" in the name), available here: https://github.com/Jusas/WatneyAstrometry/releases/tag/bleeding-cli

I think the one you need is this: https://github.com/Jusas/WatneyAstrometry/releases/download/bleeding-cli/watney-solve-bleeding-latest-linux-arm.tar.gz

If this runs your solve without errors, I'll publish this as a new stable version.

[nigeldun]

@Jusas ok I’ve tried it and it now returns successfully with what are I believe the correct coords. In blind mode it seemed to take a while to solve while in nearby mode it was under 2 secs. For comparison astap took around the same time - I assume doing a nearby solve as well.

[Jusas]

Yeah not to worry, the blind solve is expectedly slow especially on something like the Pi - bottom line is, the problem is fixed. I'll release a new stable version v1.1.2 shortly but you may keep using what you now have as it's effectively the same thing.

Thanks for reporting this because it appears that this was an issue that affected all 32bit ARM processors / 32bit Linux installations running on ARM processors so I'm really glad it was spotted. Testing this on several platforms and operating systems is a lot of work and things like this can slip in unnoticed.

I hope this works out for you, and clear skies :)

I'm closing this issue as the problem is resolved.