Welcome, Guest
Username: Password: Remember me
20 Aug 2017
INDI development team is happy to announce the release of INDI Library v1.5.0. This new exciting release builds on the maturity of INDI Library and comes with many new supported devices and fixes for existing drivers.
Read More...

TOPIC: Remote astrometry solver

Remote astrometry solver 1 year 2 months ago #10302

Do you get the same error from CCD Simulator?

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

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?

Remote astrometry solver 1 year 2 months ago #10307

I did not test the CCD simulator, I'm putting this on my list. But all the issues are probably in astrometry 0.67, or at least in my installation of astrometry 0.67.

I found a first problem in "/usr/bin/image2pnm": the return code of os.system() for sub-executable "/usr/bin/an-fitstopnm" is not properly managed. The actual exit code is 0 (high byte), but the handler rejects the low byte of the exit code, which is -1. The effect is to bail out as if "an-fitstopnm" failed, while the command ran "properly". The low byte indicates signal -1 killed the command. First question unanswered.

There is a second problem in util/ioutils.c in astrometry: the call to waitpid waiting for image2pnm to return fails with -1. Given the situation, there is only one possible reason for this to fail: SIGCHLD. Second question unanswered.

I'll have to dig a bit deeper I think. I don't understand yet why astrometry works properly from the command line and has this behavior when called by indi_v4l2_ccd.

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

Remote astrometry solver 1 year 2 months ago #10315

So the problem is a parent-child issue (as many things in our world).

It appears that when solve-field is called, signal SIGCHLD is masked, thus astrometry's utility function run_command_with_output cannot wait for its subcommands properly. When run from the command line, no problem. When run from indi_v4l2_ccd, problem arises. That's because subprocesses inherit their ignored signals.

I did not look for the sigprocmask call which set the signal to be ignored yet. Instead, I restored the signal default behavior in astrometry before starting a subcommand, and in that situation, solve-field works properly. Didn't say it solved, unfortunately, but the issue seems fixed.

(I attach a capture of my "DMx21AU04.AS". Tonight the sky isn't that clear, but to me the quality of the picture is not good. Certainly not good enough to solve anything. Any advice on how I can better use that camera?)
Attachments:

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

Remote astrometry solver 1 year 1 month ago #10691

Jasem, I'm progressing (slowly) on integrating the remote solver in my setup. I found that:
- There is a problem with the use of noZombies, causing subprocesses that do not configure their signal handlers to fail executing their own subprocesses. I use openrc to launch indiserver as a daemon (eudev adds peripherals using the server fifo, works great). Indiserver's signal configuration is inherited by its drivers. Because of that, when indiccd calls solve-field, the fork/exec and python os.system calls all fail with ECHILD. I'm not entirely clear on this though. I removed the call to noZombies and plan to implement a simple reaper which logs its activity. To be continued.
- When setting the solver to "remote" in Ekos, Ekos sends ASTROMETRY_SETTINGS_BINARY and ASTROMETRY_SETTINGS_OPTIONS to indiccd, incorrectly overwriting what is configured on the remote indiserver host. I think the settings in Ekos should only be used for the offline solver, not the remote. Too bad I discovered this so late.
- I have a few other patches for Astrometry, and a few ideas to develop to improve its efficiency on the mini-pc I use.
Work still in progress :)

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

Remote astrometry solver 1 year 1 month ago #10857

At long last, it works. To summarize what I had to do on my Linux 4.4 mini-pc:
- Fix noZombies into a reapZombies to allow subprocesses to receive their child signal
- Update the Ekos ASTROMETRY_SETTINGS_BINARY to match the remote astrometry installation
- Fix the V4L2 ccd driver to consistently drop incomplete frames from my DMK21AUS04
- Reduce the radius of search and provide a parity to solve-field to improve the reactivity of the solver
I also added a light pollution filter to the ccd to try to improve the quality of the capture, but this greatly increases the exposure, obviously.
As I write, Ekos is endlessly capturing and readjusting its aim, but it's probably because of the very poor alignment I did for the test.
I'll try to consolidate my changes into a pull request in the coming days.
-Eric

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

Remote astrometry solver 1 year 1 month ago #10859

  • H__
  • H__'s Avatar
  • Offline
  • Junior Boarder
  • Junior Boarder
  • Posts: 27
  • Thank you received: 7
Hey congrats !
I've also seen the endless capture and aim readjust. That might indeed also have been before polar alignment. I have some other things to fix before I can try again.
About the stuff you changed; are you preparing a patch file / pull request ?

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

Remote astrometry solver 1 year 1 month ago #10936

Yes I'm preparing a pull request for the signal stuff.
I don't know how to handle ASTROMETRY_SETTINGS_BINARY yet because it's a unique setting in Ekos while there could be multiple remote solvers on multiple indi servers, or one remote solver used by many indi servers, or a fallback situation which the solver switches to the offline one, or to the online one.
For the V4L2 ccd patch, I'd like to improve the text with a few additional things before submitting.
First, right now the V4L2 ccd driver frame drop fix only works in the single-plane uncompressed case, so I need to be careful to avoid regressions.
Second, the log will often tell me the frame was recovered in say 8s while the requested exposure was 10s, so I want to try to reset exposure before starting a new capture to get rid of that properly.
Third, I want to understand why the timestamp located in the frame by the v4l2 driver is offset by ~30s compared to system clock, as this value could also be used to drop frames.
-Eric

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

Remote astrometry solver 1 year 1 month ago #10937

for ASTROMETRY_SETTINGS_BINARY, I could disable auto-updating it and let the user it set.

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

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?

Remote astrometry solver 1 year 1 month ago #10938

I'm not clear on the I/O with fields yet, but perhaps the driver could have an ASTROMETRY_SETTINGS_LOCAL_BINARY which, if empty, would fallback to ASTROMETRY_SETTINGS_BINARY? This would add an additional setting to the list though.

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

Remote astrometry solver 1 year 1 month ago #10940

INDI::CCD is already bloated, so no need to increase complexity. I already disabled updating the binary field from Ekos.

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

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?

Remote astrometry solver 1 year 1 month ago #10970

A few suggestions from my tests:
- it happens that sometimes the solver will just fail for whatever reason related to the quality of the capture, thus it may be useful to retry instead of failing.
- if available, and because it doesn't make any assumption about the capture, it may be interesting to run the online solver to verify the configuration of the optical path in Ekos and issue a warning eventually.
- the "parity" option increases the performance of the solver, so as soon as its value is detected by a successful run, it should be reused afterwards.
-Eric

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

Remote astrometry solver 1 year 1 month ago #10972

1. I usually leave that a bit higher up the chain. So if you use the scheduler and alignment fails, it would retry that. It's not a good idea to put everything right at the driver level.
2. The user can run that now, not sure if it will issue the "focal length" warning for online astrometry though, have to check.
3. Good point, will look into it.

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

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Time to create page: 0.107 seconds

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!


Gallery

Replica

Why INDI

Replica