Ways to improve speed of source extraction during solve-field?

[Umair Khan]

Hello everyone,

I am fairly new to the whole astronomy scene, so apologies if this is a basic or strange question. I'm working on the star-tracking system for a nanosatellite being built at Portland State University, and we're using astrometry.net (command line) to calibrate our star tracker.

Right now, we intend to run the star tracker on a BeagleBone Enhanced. We want the ability to re-calibrate our star tracker while in space should anything go wrong, so this entails running solve-field on 5-10 images on the BeagleBone. It currently takes about 17 minutes to do so (with --skip-solved, --no-plots, and --cpu-limit 60). I've tried --scale-units, --depth, and --resort to improve this number with no appreciable results.

I've noticed that the vast majority of the time is taken up by the source extraction. Once the sources are identified, actually solving the image only takes about a minute, which is acceptable. So I was wondering if anyone here had any advice as to how to improve the speed of the source extraction when using solve-field. One constraint is memory - we're limited to about a gig of RAM, so anything memory-heavy solutions are probably not feasible.

Thanks in advance for any advice.

[Bryan]

Umair

I suggest --downsample 2, if not already set at that.

Also, set Scale Min and Scale Max to values about 30% below and above your system's FOV

Bryan

[Umair Khan]

Thanks for the suggestions, Bryan. It is pretty late in my time zone, so I will try these tomorrow morning and see how it goes.

[Dustin Lang]

I would be very happy to hear more details about this star tracker and nanosats, if you can tell us anything!  We love to hear about where the system is being used, and if you are actually flying the code in orbit, that would be a record.  We have done high-altitude balloons, the SOFIA observatory, and an experiment aboard the International Space Station (but they telemetered the images and ran our code on the ground, so it doesn't count!), but never actually in orbit, so far as I know!

You can add "--uniformize 0" to skip another step that you might not need.

As mentioned, "--downsample 2" will help the speed, and might help the robustness.

The built-in source detection is fairly standard, and you can experiment with it using the "image2xy" program.  In short:

- estimate noise in the image

- median filter to subtract background

- smooth by Gaussian

- find peaks & deblend

- measure peaks

Some of these steps can be short-cutted if your images are clean.

Another option is to plug in your own source detection (eg, if you have a Source Extractor config file that does what you want, or custom code for detecting stars in your images).

If you have an idea of what your images will look like and can share them, we might be able to make more suggestions.

cheers,

--dustin

[Hans]

Hi Umair

Bryan wrote on 20180625:
> I suggest --downsample 2, if not already set at that.

Go further than that, downsample to where you still have enough stars (and
certainly not too many) and can still solve the field. I use --downsample 6 or
sometimes even 8. I found aiming for some 20 stars in your field works well.
That greatly speeds up source extraction.

For the solve field there's other interesting options that you can use :

> Also, set Scale Min and Scale Max to values about 30% below and above your
> system's FOV

and add pointing hints.

-- Hans Lambermont

[Umair Khan]

Thank you to everyone for all the responses! I just tried adding --downsample 2, and that reduced the calibration time from 17 min. to 4 min. I will continue to experiment with this further and also try scale min, scale max, and the other things mentioned thus far.

In response to Dustin, the satellite I'm working on is open-source, so I can tell you basically everything :)

This is our group's Getting Started page, which contains some basic information about the CubeSat format and OreSat in particular. In a nutshell, we're working on a 2.5U CubeSat that's scheduled for launch sometime in 2019/2020 through NASA's CubeSat Launch Initiative.

With regards to the star tracker specifically: we're basing our star tracking system off of OpenStarTracker, which is being developed in conjunction with the Nanosatellite Lab at the University of Buffalo. Part of the setup process for OpenStarTracker involves getting some baseline calibration data from a more computationally-intensive, but reliable, star tracker, which in this case is astrometry - hence why I'm asking questions about how to improve its speed. While our goal is to pre-calibrate the tracker before sending the satellite into space, we want the ability to recalibrate OpenStarTracker in space, meaning that yes, astrometry will be running in orbit.

We took our first photos out in the Oregon desert with a prototype setup a couple months ago, an album of which can be found here. We anticipate pictures taken in space to be pretty similar to this - if anyone here knows for sure that they won't be, please let us know!

Thanks again to everyone.

- Umair

[Dustin Lang]

If you add "-v" (verbose), or experiment with image2xy, you should be able to find out which parts of the source detection are taking the most time.  I can maybe suggest other things you can try if you tell me what is taking the most time.

cheers,

--dustin