Thursday, 30 June, 2022
Song of the Day: Under the Bridge - Red Hot Chili Peppers
Figured out my DCM to Roll/Pitch/Yaw conversion issue this morning. Turns out the DCM in the matlab version was the transpose of what I figured it would be, so all of my indexes were off. Once I got the indexes figured out, my code started reporting values that agreed with the matlab script’s.
Once that was in place, I started messing with the python scripts so that I could analyze the amount of the celestial sphere that was visible.
Immediately, I became aware of a few issues with my code. I wasn’t wrapping the frames around the edges of the map, so large sections of the dataset that I was using were not being represented at all. This was simple enough to fix. Only a few modifications to my code. The dataset I was using quickly brought another problem to my attention, however.
The images I was using were largely taken around the northern and southern poles of my map, and I was trying to perform an area calculation. One of the main issues with representing a 3-dimensional sphere on a 2-dimensional rectangle is that sections of the map get scrunched up, while others get spread apart. This is the same issue that occurs with maps of the world. The poles become over-represented, while along the equator becomes under-represented. Obviously, since I’m performing area calculations, that’s no good for me.
After a lot of thought, and some input for my mentor, I came across the concept of a Spherical Segment. Using this, I was able to calculate the surface area of a horizontal stripe on a sphere, and divide by the number of vertical sections to obtain the surface area of each of the spherical rectangles that I had essentially broken the celestial sphere into. By applying this value as a weight in my calculations, I was able to apply more weight to the images taken towards the equator, and less towards those taken at the poles, thereby fixing my area calculations.
I am left with the small issue of not being able to properly spread images across the poles correctly, as I am still limited by my cartesian coordinate system, but I think that this solution works well enough as to provide a lower bound to the amount of sky used in flight.
It appears that I’ll be spending some time next week creating a presentation of the work that I have done here to show to the rest of the opnav department! I’m sure I’ll be spending some more time looking over the whole thing and see if I can’t find/fix some more flaws in it’s design.