Double checking stars, false detections and angular rates

Karl Gudmundson

unread,

Mar 13, 2019, 6:00:40 AM3/13/19

to OpenStartracker

Hi!

Thanks for doing this project, I think I'm starting to get the hang of it :). I have some questions regarding the topics in the title. First of all, the match_near function, does it just confirm the solution from match_lis? I have some images that won't solve for some reason, but I have realized that the program actually does solve them in many cases using match_lis, but match_near rejects them as solutions. The orientation seems to be the same most of the times, so I would guess that it is the correct one.

Some other of my images are solved "completely", i.e. by match_near as well, but sometimes there are some false detections among the correct ones, where the orientation is completely off. I would guess that the best way to solve this is to use some filter solution which rejects the outliers, or do you have any other idea?

Lastly, there seems to be a part where you try to solve the angular rate between images. It does some calculations, but does not provide any angular rate. Is there a lot to add to actually get an angular rate measurement? Do you have any references on how to do it?

Thanks in advance!

/Karl

Andrew Tennenbaum

unread,

Mar 13, 2019, 1:28:41 PM3/13/19

to Karl Gudmundson, OpenStartracker

Hi - great to hear! So match_near is used to search a subregion of the catalogue - it gathers all of the stars from the catalog in the vicinity of the specified coordinates, and then matches against that. This is used as a way of refining the results from match_lis. In the current configuration, match_lis only checks the brightest MAX_FALSE_STARS+REQUIRED_STARS - the rational for this is performance. Once this is done, we use match_near to identify all of the stars in the image. This is not essential, but is useful in order to further refine your attitude estimate. In cases where there are false negatives, I would take a look at two things:

1. how many stars were identified in the winning solution (lis.winner.size())

2. what is the match certainty (lis.p_match)

the key lies in this line in match_lis: if lis.p_match>P_MATCH_THRESH and lis.winner.size()>=beast.cvar.REQUIRED_STARS:

p_match is computed with the assumption that the photo given is an undistorted photo of the night sky containing only real stars. REQUIRED_STARS is a bandaid around for when these requirements are not met - IE the earth is obstructing the field of view

if you are getting false positives at a rate higher than 1-P_MATCH_THRESH, then there is something funny going on...

If you have some idea of where you are pointing, you should use match_near rather than match_lis - just be sure to check p_match, and the number of stars in the image. This will have better performance that match_lis + a filter, both in terms of speed, matches, and false results

For calculating angular rate between images, take a look at extrapolate_images and extrapolate_matrix. Time is in microseconds since unix epoch, and angular rate is in radians per second

--
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/e49d145f-1d1e-4c6d-ac17-bb556345c704%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Karl Gudmundson

unread,

Mar 14, 2019, 12:08:03 PM3/14/19

to OpenStartracker

Okay, got it! I haven't had the time to look into this properly yet, but I'll get back to you if I have any questions when I have checked out the number of stars identified and p_match.

As for the wrongly calculated orientations, I think I actually do get them at a higher rate than 1 % of the times for certain datasets. Maybe it has to do with the quality and/or the calibration of the images? I must also admit that I have done some changes to the code, so it might actually be something I have done wrong.