Is there any more documentation available for the algorithm/ process or specifications?

[Nathan Aday]

Hey all,

We really appreciate that you've made this stuff open source. I'm working on a project right now involving star tracking softwares and I'm wondering if you have any documents related to the (1) specific algorithm/ flow of processes and (2) specifications or limitations of the code (i.e. max slew rate, max and min number of stars in the catalogue). We have the full github download and got the startracker working on a raspberry pi at the moment. Before we start working backwards from the code and creating the documents ourselves, I figured I could check here first.

Thanks!

Nathan

[Umair Khan]

Hello Nathan,

Full disclosure -- I'm not "officially" connected with OpenStarTracker. I'm in the same boat as you in that I've been working with OpenStarTracker for a while, and the closest thing to additional documentation is probably the paper on OpenStarTracker, which you can also access through its website. It provides a very high-level overview of the algorithm at play. With regards to your second point: if you're doing a lost-in-space solution every time (which is fast enough to be feasible with OpenStarTracker), then your slew rate will be limited by your camera system and how fast it can capture a good image to work with; and unfortunately I don't really know anything about the number of stars in the catalogue, I've just always used the stardb file in the repo. Hope that helps!

- Umair 

[Nathan Aday]

Great I really appreciate it. Just out of curiosity, how fast are you usually getting lost in space solutions? We're getting anything between 1-2 mins but that's probably more a symptom of our pi. But I'm wondering what OpenStarTracker is capable of getting down to.

Thanks again!

[Umair Khan]

That's...disconcerting. I've been running it on a PocketBeagle, which is significantly less powerful than a Pi, and here's the general performance I've been getting:

• calibrate.py (the -c flag) -- takes about 5 minutes to go through seven photos, though I have played around with astrometry and improved performance a little with downsampling
• startracker.py (the -i flag) -- takes about 30 seconds to start up and load the database, then lost-in-space solutions take about 0.5 seconds each for a 640x480 image.

I've found that solution times scale roughly with the number of pixels, so for example a 1280x960 image would take about 2 seconds to solve. But I've never seen 1-2 mins for just a lost-in-space solution. If you're interested in looking at what I'm running, you can check out this GitHub repo, but I haven't touched the back-end at all, only the Python front-end, so I'm not sure why there's such a large discrepancy. Also, be warned that the repo I linked is a bit of a mess and nowhere near as well-documented as it should be :)

- Umair

[Andrew Tennenbaum]

Hi! I’d guess that your exposure  time is too high. Lower the exposure till there’s ~5 stars in the field of view and recalibrate 

--
You received this message because you are subscribed to the Google Groups "OpenStartracker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openstartrack...@googlegroups.com.
To post to this group, send email to opensta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openstartracker/672dda07-99fb-497a-a22d-a35e49f9cae4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Tennenbaum]

It’s a trade off - in general you want to use the lowest exposure where all of the calibration images will still solve