Bumps in GoFast


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:


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):
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:

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:
It's been pointed out that in Gimbal the background rotates as well when bumps are seen in the object's position. Some people have even had difficulty seeing the background rotation for the smallest bump at the beginning of Gimbal and the bumps here are much smaller, so it makes sense that here with the naked eye you can only see the bumps in the object, not in the background, but I wrote some code to track the background and estimate its rotation. I got the following graph with a pretty good correlation between the bumps in the object's position (the same blue graph from above) and the bumps in the background's rotation (green). I'm also showing the average magnitude of the displacement of the background in pixels (purple) and the average angle in degrees (red).

To help see these rotations even better I color coded the angle of each displacement such that the average angle is green and angles that are smaller/greater than that shift towards red/blue (HSV with hue = ((angle - mean) * 8 + 90) % 360).

A (frame 399 at 13.4s)
B (frame 491 at 16.5s)
C (frame 508 at 17.1s)
D (frame 523 at 17.6s)
E (frame 540 at 18.1s)
F (frame 586 at 19.7s)
G (frame 625 at 21s)
H (frame 863 at 29s)
I (frame 1001 at 33.7s)
J (frame 1020 at 34.3s)

For the most part (frames A-F and J) the background rotates exactly when there's a sudden change in the object's position. A few exceptions are shown. At G it would seem like you'd expect the background to rotate, but it doesn't appear to. Maybe the pod rotation is somehow more gradual there, or maybe it's a wobble in the object. At H the algorithm detects a peak but looking at the displacements in the image it doesn't seem like it's a real rotation. In general the results get more and more noisy towards the end. Frames near the end look more blurry. Maybe it has something to do with background moving faster there, causing motion blur ? At I there's a peak detected and you'd expect one, but looking at the image it's not clear if it's real.

Here's the full video of this, slowed down 3x to help see the sudden changes in the pattern.

For the optical flow I used the same OpenCV functions as here but this time I tweaked the parameters a lot more to reduce the noise in the result. The values of the parameters that do not have default values are shown in the screenshot with the graph. Leaving in a bit more lower quality GFTT features was helpful to make sure there's enough data to find the pattern. More PyrLK iterations led to a bit better matches. The frames show correspondences between the current and the next frame. To help filter out the static elements of the display and other small noise I filtered out displacements that are smaller than 7 pixels. This time I also used a function to estimate an affine transform between the correspondences which also rejects some outliers. I show the remaining inliers in the frames and the average magnitude and angle are also based on those inliers. It turned out that setting the RANSAC reprojection threshold a bit higher gave better results so there's still a fair amount of false correspondences left among the inliers but more data that then gets averaged over. Finally I decomposed that transform to display the rotation (in degrees, multiplied by 100).

So in conclusion this is further evidence that the bumpy behavior during pod roll changes seems to be present in GoFast as well.
Last edited: