Bumps in GoFast

logicbear

New Member
There have been lots of discussions about bumps in Gimbal, but I couldn't find much about bumps in GoFast. Some have claimed that there aren't any so I thought I'd take a look. I first pulled up sitrec for gofast , expanded "Show/Hide" and clicked on "Graph" to see what the pod roll might predict about it:

gofast_sitrec_roll.png

Based on that I expected to see some bumps around the time where the pod is rotating, at 16-18 sec and near the end of video, but not so much during that long flat period in between. Then, just eyeballing the video that's exactly what I saw. Of course these bumps were much smaller than in Gimbal, but GoFast is in NAR 1x, more zoomed out, so a degree of tracking error should translate into at least twice as large a movement in this image than in Gimbal's NAR 2x. It's also possible that edges aren't quite as steep as in Gimbal sometimes, perhaps due to GoFast looking down, panning away from the singularity.

It was then suggested that these were somehow an illusion caused by missing/duplicated frames, or compression artifacts. The former shouldn't make an object that's perfectly tracked / centered in the image move, and in either case it would be odd for it to affect particularly parts of the video that correlate with some rotation, but I decided to investigate further. I downloaded the original GoFast video from here , extracted the frames with ffmpeg, and I've looked at those frames a lot since then but I've yet to find any duplicates or obvious missing ones. Maybe some people were looking at a different version ?

I wrote some code to track the object and plot its vertical movement. While the pod is tracking the object in white hot mode there is almost always only one, occasionally at most two adjacent pixels that have the highest intensity so it's very easy to track it. In black hot mode however (between ~ 21.5 - 26.5 seconds) there's always 7-15 pixels with the same intensity, so in that case I ended up calculating their center of mass, but there's irrecoverable data loss due to that saturation, compounded by the larger blob getting closer to a compression boundary, so some extra noise is to be expected. Here's how the y coordinate of maximum intensity pixels varies (centered / magnified by 40):
gofast_bumps_rough.png
It's only changing by +/- a pixel or two, but visually you can see more detail than that so I added a method to track the pixels with subpixel accuracy. I fit a 2d surface described by the function "S(x,y) = A x^2 + B xy + C y^2 + D x + E y + F" to the maximum intensity pixel and its 8 neighboring pixels then calculate the point where this surface has the maximum value. I also used the el/az/bank angle data from Sitrec (with linear interpolations for el/az), and a 3.6 degree base jet pitch (scaled with the bank angle), to display the pod roll:
gofast_bumps_2.png

Notice that the red cross in the image is no longer centered on the middle of the pixel. Instead in this example it moves horizontally closer to the other bright pixel to the left of it, and vertically closer to the two brighter pixels below it. There's a bunch of noise, but still a general correlation between the pod roll and the magnitude of the bumps becomes apparent. Keeping in mind that the black hot section (21.5-26.5 s) has lower quality data and a different less precise algorithm, the relatively less bumpy period tracks with the very flat pod roll section. Maybe there's room for some improvements here but it does seem like a general prediction of the pod roll causing some bumps seems to hold up in GoFast as well ?
 
Last edited:
Top