Amazing Fin Flutter vid!

[Ryan S.]

Frequency Amplification...or something like that

 

[rabidsheeep]

actually somthing like that actually happened... not sure, some discovery channel show, but they didn't put ventillation holes so basically the bridge started bending (not to that extent) then the mid section fell

 

[Bill]

Originally posted by Merican
Cheap camera trix

Definitely not the case. If you look at the related page, https://www.enm.bris.ac.uk/research/nonlinear/tacoma/tacoma.html, you will find out more about the actual collapse of the Tacoma Narrows bridge in Washington State. This footage was required viewing for all engineering students when I went through.


Bill

 

[Merican]

umm.. That would be the Tacoma Narrows bridge, aka Galloping Gertie..

completed July 1940 Collapsed November 1940 thus providing an abject lesson in harmonics relating to bridge design.


Edit.... Holy Mackerel I was kidding... It was an attempt at sarcasm, pointed to the non flutter, video compression, little Gremlin jiggling the camera conspiracy theorist.

While I’m not going to pretend to be knowledgeable in the areas of aeronautics or fluid dynamics I do have experience relating to Mechanical Engineering and have seen some pretty neat things while conducting failure analysis, so I find the Fin flutter very interesting.

 

[Elapid]

yeah, we watched that in Physics class. Hats off to the gentleman that tried to rescue the poor doggie! i forget if it was actually rescued or not... been a lotta years.

along with actual experience in earthquakes, where i have seen patios, walls, and solid ground turn to Jello...

makes me think that the fin flutter video is a real representation of the events.

Thanks to everyone that has participated in this thread!

 

[firemanup]

The only video i've seen similar to this stuff is from the Easton archery site......

Where as they take perfectly stiff aluminum and carbon arrows and shoot them out of a bow recorded in slow motion..

Those arrows turn into spaghetti as they come off the bow before they stiffen up again..

I think this video is showing a similar thing, i too wonder about the fins heating from both conducted heat from the motor as well as heat from the airflow going over them maybe making them even a little more prone to bend..

The other thing i wonder, having watched arrows turn to spaghetti coming off a bow and then be shot a hundred more times with no failure, is are these fins really bad now..?

Has it been flown again, anyone know..?

Either way cool video

 

[11bravo]

This is another one of those things about which I have no real knowledge to contribute that would advance this discussion, but I'll happily throw in my opinion anyway.
I would bet that this is like swimming beaches being closed because of bacteria so often these days. I suspect that the bacteria levels haven't gone up in recent years, we've just started to test more for them.
I would also be that something similiar happens WAY more often than people realize; this one just happens to have video.
Especially since they just seem to "pop" right back to what they are supposed to be.
I bet further that if people knew how often their rockets did stuff like this, they'd overreact and build the fins out of 1/2 steel plate.
Well, maybe not that much but you get the idea.

It is way cool video though.

Greg

 

[Ryan S.]

Originally posted by Elapid
yeah, we watched that in Physics class. Hats off to the gentleman that tried to rescue the poor doggie! i forget if it was actually rescued or not... been a lotta years.

The dog bit him and wasnt rescued.

 

[vcp]

Posting to this old thread since it was referenced by a recent thread.

I am not speculating. The video in these threads are certainly an example of fin flutter, but the 'wave' in the fins -is- an artifact of an imager that is using a 'rolling shutter'.

The paper here,
https://ieeexplore.ieee.org/iel5/16/26588/01185163.pdf explains:
"Most CMOS image sensors feature the rolling shutter
architecture to control exposure time. However, imaging
of fast moving objects or using pulsed illumination is a frequent
task in industrial and scientific applications, which cannot be
done with the rolling shutter architecture."

The camera does not take an instant 'snapshot' of an entire scene, rather the image is taken progressively, one imaging line at a time. Each line is a new view of the subject at a different time, so if the subject is moving, it appears distorted. Fluttering fins become wavy fins.

Figure 1 in that paper is a distorted photo of a rotating fan taken with a rolling shutter camera. Somewhere I've seen an example video, but can't seem to come across it now.

GC

 

[vcp]

Posting to this old thread since it was referenced by a recent thread.

I am not speculating. The video in these threads are certainly an example of fin flutter, but the 'wave' in the fins -is- an artifact of an imager that is using a 'rolling shutter'.

The paper here,
https://ieeexplore.ieee.org/iel5/16/26588/01185163.pdf explains:
"Most CMOS image sensors feature the rolling shutter
architecture to control exposure time. However, imaging
of fast moving objects or using pulsed illumination is a frequent
task in industrial and scientific applications, which cannot be
done with the rolling shutter architecture."

The camera does not take an instant 'snapshot' of an entire scene, rather the image is taken progressively, one imaging line at a time. Each line is a new view of the subject at a different time, so if the subject is moving, it appears distorted. Fluttering fins become wavy fins.

Figure 1 in that paper is a distorted photo of a rotating fan taken with a rolling shutter camera. Somewhere I've seen an example video, but can't seem to come across it now.

GC

 

[DaveHein]

I am familiar with some of the Aiptek cameras and they do use a CMOS sensor that causes a skewing artifact when there is motion. I use an Aiptek Pencam to take still images. Objects become distorted if the camera is moving or the object is moving.

MPEG compression can cause severe artifacts at low data rates. However, most digital camcorders compress video at a fairly high data rate. It is doubtful that the fin flutter artifacts are caused by the MPEG compression.

I believe that the fin flutter shown in Peter Clay's video is a combination of real fin flutter and the scanning artifacts produced by the CMOS sensor. Art Upton's video shows fin flutter without the sharp angles present in Peter Clay's video. The camera used by Art Upton doesn't seem to have the scanning problem that the Aiptek camera has.

I wrote a program to simulate a scanning type of camera taking a picture of a fin oscillating back and forth, but without bending. I generated the following image.

The blue lines represent the position of the fin at different angles as the image is being scanned. The red line shows the resulting image. This looks very similar to some of the frames in Peter Clay's video. Therefore, I believe the sharp bends and multiple waves in the video are a result of the image sensor.

Dave Hein

 

[vcp]

Thanks Dave, I was prepairing to attempt that same thing, expecting that result. What did you write it in?

Gary

 

[2muchstuff]

Originally posted by DaveHein
...MPEG compression can cause severe artifacts at low data rates. However, most digital camcorders compress video at a fairly high data rate. It is doubtful that the fin flutter artifacts are caused by the MPEG compression.

I believe that the fin flutter shown in Peter Clay's video is a combination of real fin flutter and the scanning artifacts produced by the CMOS sensor....

Dave,
You're on the right track. CMOS sensors do indeed have problems with motion, but you've overlooked something about the compression.

What no one has really looked at is how video is compressed and how that might cause the problem. The issue goes much deeper than has been discussed elsewhere. Since Dave Schultz and Bob Krectch firmly believe the video is fin flutter, I'd like them to explain the following images.

First, I do believe that there was some fin flutter. But nothing like is depicted in the video. Dave Schultz (uhClem) did some preliminary research on how video is compressed, but he fell short of really getting into the meat of it.

A complete discussion would be well beyond what anyone here would be interested in, so I'm going to keep it brief and use a couple of images to demonstrate my points.

Video images are encoded as a series of 'macroblocks': 8x8 squares of pixels. Generally, luminance (detail) is sampled at a much higher rate than chrominance (color.) That alone can produce a number of artifacts. More importantly, macroblocks are reused between frames if possible since that greatly reduces the amount of information needed to reproduce any single frame. All mpeg compression uses some form of both inter- and intraframe compression.

To put it simply, an encoder compares two frames against each other, using macroblocks. It tries to 'predict' motion if possible and creates a vector that is applied to a macroblock from the first frame to tell it where to go in the next frame. The works fine when objects are moving along an orderly path, such as a car driving down the street or a person walking. Image a macroblock that included detail from a car door handle. Rather than storing it in each frame, you could just say to the macroblock, 'move x pixels in y direction' for each frame, and you'd have a highly compressed video, yet with good detail.

However, when things move strangely, the encoder can get confused and put macroblocks in the wrong place. This can cause all kinds of problems. I believe this type of error, along with other issues, is causing the incredible flexing of the fins, instead of actual fin flutter. To repeat, I believe the fins are fluttering, but not to the extent indicated by the video.

My next two posts include images that demonstrate my argument.


tms

 

[2muchstuff]

Originally posted by 2muchstuff
...However, when things move strangely, the encoder can get confused and put macroblocks in the wrong place. ...

Here's my first image. It's an enlargement using a sampling technique that does not modify the pixels, but just makes them bigger. (Unlike Photoshop's bicubic sampling.)

It's taken from a frame of the fin flutter video. It's been converted to grayscale to increase contrast. You can easily see the macroblocks I mentioned in my previous post. I've noted in the image where a possible encoding error occurred. You can clearly see that the fin edge is 'discontinuous' at the point indicated. I suspect that the encoder erred and placed the wrong macroblock(s) at this location, causing the fin to appear longer than it actually is.

Upon further inspection of the macroblock structure, I noticed that all of the macroblocks that occurred in the frames that showed the incredible bending and flexing were of lower average luminance than their neighbors, which again leads me to believe an encoding error occurred. Or, the luminance varied in a way that defied what would have been expected and is seen in other frames.

More importantly, and here's what I'd like Dave S. and Bob Kretch to explain, is what happens in the next image.


tms

 

[2muchstuff]

Originally posted by 2muchstuff
More importantly, and here's what I'd like Dave S. and Bob Kretch to explain, is what happens in the next image.

While I agree that fin flutter occurred, its motion was greatly exaggerated by both the camera and the video encoding. What I have not mentioned yet is that I'm not sure where the encoding error occurred. I'd really like to see the original file as captured by the camera. The one posted on the web is only 12 fps, (actual frame rate) and has been transcoded, which can induce additional encoder errors. If I could analyze the original file, I might be able to better discern what happened.

Here's the image that leads me to believe that what we are seeing is not purely the result of flutter. I used a program that allows me to step through the video frame by frame, as well as 'paint' on a layer directly above the video. I simply drew a red line over each fin just before the flutter started. I then stepped through the video and compared the fins to the length and location of the original lines. One thing I realized is that the payload bay 'twists' counter-clock wise slightly during the sustainer's boost. The two pieces actually rotate in relation to each other. That counter-rotation can cause some slight aliasing artifacts in the video image.

Worse, if you believe the video, the length of the fins changes considerably while they flex! Remember that these fins are somewhat diamond shaped - they taper in the middle. Yet, when you look at the image, you'll see that the fins get much longer when they flex - which is exactly the opposite of what should happen. Get a piece of paper, flex it, and you'll see it's 'shorter' than when straight. But somehow these fins get longer while they flex. And this is G10 material - not very elastic. I'd like to hear an explanation for how something that is bending can get longer at the same time and not come apart. You'll notice that in the last frame, the fins have miraculously returned to their original length. There is a follow up video on the website that shows that the fins are largely intact. I also find it hard to believe that the paint would have held up to all that flexing, yet it looks fine, other than at the root edge of the fin.

I could go on with several more examples of how the image is technically flawed and how sensors screw up images. Dave and Bob may be experts in their fields, but if there's one thing I know and understand, it's digital images and compression. Based on my technical analysis of the video, what we are seeing is not real, but a summation of errors in the image, caused by both the camera and the compression. To be sure, there is some slight flutter, but not the wild and crazy stuff we're seeing.

I'd love to stand corrected.


tms

(Finally, let's apply Occam's razor: what's the simplest explantion? That a G10 fin can somehow survive wild and fantastic oscillations in shape and length, or that the video has technical limitations in showing what really happened?)

 

[Graham Orr]

2muchstuff,
I completely agree. Upon looking at the algorithms for image/video compression, there are a few simple explanations:
*Nyquist frequency is ~15Hz, so we are not really seeing 2-3Hz fin resonance (explains time oddity)
*Video compression method uses a sort of Newton's Method to try to obtain position of moving objects. However, if they are accelerating rapidly, this approximation is not good.

Fins are fluttering but not like we see them. They are probably buzzing back and forth with a magnitude of no more than 0.4 inches PTP.

I'd love to stand corrected.

You ARE correct.

 

[DaveHein]

I still stick by my statement that the unusual appearance in the video is due to the way the CMOS censor is scanned. I have many pictures taken by the Aiptek PenCam that show this artifact. Here is a picture I took last week at South Padre Island using a PenCam hanging from a kite:

Based on the discussions on this thread there are three possible explanations for the curvature in the buildings and objects on the ground:

1. The kite caused unusual turbulance which temporarily softened the buildings and caused them to bend in the wind.

2. The JPEG encoding produced artifacts that makes objects appear warped.

3. The camera was swinging from the kite string, which caused each scan line to be at a slightly different angle as the image was being read out of the CMOS sensor.

Of course explanation number 3 is the correct one.

WARNING -- Details about MPEG encoding follow below. Please skip the rest of this message if you are not interested in MPEG.

The MPEG argument about the fin flutter video doesn't make a lot of sense. MPEG compression does use motion compensation to predict the next frame, but the resulting prediction error is then coded as quantized transform coefficients. If the data rate is very low the quantizers will be very high, which would result in severe coding artifacts. However, according to the specs for the Aiptek DV4500 the internal 16Mbyte memory can hold 3 minutes of video. This works out to 745 kilo-bits/second. Admittedly, this is at the low end for video quality. At 640x480 resolution and 30 frames/second good quality would be achieve with about 2 M-bits/sec.

However, since the DV4500 encodes video at 12 frames/second 745 kbps is not unreasonable. This would be 62,000 bits per frame. A macroblock is 16 pixels by 16 lines, so there are 1,200 macroblocks in a 640x480 image. This works out to an average of 51 bits per macroblock. Macroblocks with little detail will use fewer bits and macroblocks with more detail (such as a rocket fin) will use more.

Motion vectors are typically limited to a small range, such as +/- 31 horizontally and +/- 31 vertically, which would require 12 bits. However, since motion vectors are coded differentially from one macroblock to the next and variable length codes are used, the average number of bits per macroblock are less than 8 bits. Assuming the mode indication is around 8 bits this would leave 35 bits for transform coefficients. Some macroblocks will use more and other less.

When a good motion vector cannot be found for a macroblock it will either be encoded intraframe (similar to JPEG) or interframe where the macroblock in the previous frame is subtracted from the one in the current frame. The mode that is used depends on which one generates the lower number of bits.

The bottom line is that MPEG encoding did not cause the fin flutter artifact.

 

[2muchstuff]

Originally posted by DaveHein
I still stick by my statement that the unusual appearance in the video is due to the way the CMOS censor is scanned....

Dave,
Perhaps you skimmed my posts a bit too quickly. You'll see that I state that the image is a combination of all three factors - the camera, the encoding, and real fin flutter. I sounds like you have a very good understanding of the encoding process. As a result you can appreciate the following image. It shows your image next to one from the now infamous 'fin flutter' video. You'll clearly see the difference.

I think you also misunderstood my post. I did not claim that mpg encoding caused the fin flutter artifact, only that it exaggerated it. The image you posted was not nearly as compressed as the images in the fin flutter video.

Your argument that the effect is based solely on the camera fails on a much more fundamental level.

In the image you posted, the camera is moving and the buildings are stationary, hence, the curved effect. But in the fin flutter video, both the camera and fins are stationary with respect to each other. (Except for a very slight rotation.) So, your argument would explain why the smoke trails appear curved, but not the fins. If your argument held, the curvature of the fins would be consistent from frame to frame and smooth in shape, which is clearly not the case in the fin video. In fact, the image you posted proves that the camera can not be the sole reason for the observed motion, since the fins curve in BOTH directions and in vastly varying amounts, not just with the rotation of the rocket. The fins are fixed with respect to each other and the camera, so any scanning error should be consistent across both fins. More importantly, the 'flutter effect' starts and stops near mach, even though the rocket continues to rotate. A scanning artifact would remain constant with spin rate and independent of airspeed.

You're also being too kind when you generalize how compression works. As you must be aware, there are many tradeoffs made during encoding. The distance a macroblock can 'wander' is a function of encoding efficiency. There are also different levels of motion estimation quality. Worse, the fin video has been encoded twice, which greatly increases the chance of errors. Frankly, I'm surprised that someone with your level of understanding of how video compression works would dismiss it as a source of the visual artifacts. Your description of how macroblocks are reused between frames and are assigned motion vectors proves my discussion is valid.

While your image is compelling, it only serves to prove my argument. Since both the camera and fins are stationary with respect to each other, the scanning characteristics of the camera can not explain all that we're seeing.

Plus, unless I misunderstood your post, your image is taken in 'photo' mode, not a frame from a video stream. Apples to oranges.

I'll summarize the conclusions I posted previously:

* the CMOS sensor of the camera creates image artifacts
* the encoding process creates image artifacts
* the actual fin flutter greatly magnified those artifacts

I've yet to be convinced otherwise.


tms

ps: actually I'll modify my conclusion somewhat - it's also possible the the visual effect of the flutter is further magnified by air turbulence near the fins. After further review of the video, there are no 'sharp' macroblocks near the fins when they show the greatest amount of distortion. It looks a lot like the same effect as heat waves over a road on a hot summer day. (Looks like everybody's right.) There are distorted areas that clearly have the same color as the surface of the fin - that is hard to explain other than as a function of the fin 'fluttering' enough for the surface to be visible, and that color being 'spread' to adjacent pixels either through a compression artifact or the effect of a 'mach mirage.'

 

[falingtrea]

Actually, I think is is related to the oscillation rate of the flutter. The typical video camera captures video at a 30 fps rate. According to Nyquist theorum, you would only be able to accurately capture flutter motion with a frequency of 15 hertz. Above that you will see some kind of distortion.

Now taking into account that video is collected and sent in frames(which are alternating odd then even scan lines) at a 60 hertz rate, fast motion would see even more distortion.

It is a similar effect to when you "see" car hubcap spin backwards on video or under street lights.

 

[DaveHein]

Tim, you are correct that the frame rate is way to slow to accurately depict the motion of the fins. The fins are fluttering much faster than 12 fps can capture.

tms, I did not skim your messages. I read them in detail, and I examined the images you posted. I do see the blocking artifacts you mention. Large portions of the image have almost no detail in them, and they are represented by the DC coefficient (average value) of the block. There are clear block edges along the fins, with small missing corners from the block.

However, I don't believe the overall shape of the fins is an artifact of the MPEG encoding. I believe the MPEG encoder accurately conveyed the overall shape of the fins as it was obtained from the image sensor.

The simple C program I wrote generates simulated images that closely match the fin shapes found in the video. I'll post a few more simulation images on Monday when I have a chance.

In order to generate the shapes in the video the fins needed to vibrate at 40 Hz or more. What's the resonate frequency of the fins on your rockets? I plucked the fins on several of my rockets, and the plywood fins are so heavily damped they just make a thud.

The plastic fins on my Aerotech G-Force do vibrate some. It sounds like the frequency is around 60 to 100 Hz. Under the right conditions the fins on the G-Force could be forced to vibrate at their resonate frequency during a launch. I've never made a rocket with G10 fins, but I would guess that they would vibrate also.

Dave

 

[2muchstuff]

Originally posted by DaveHein
...However, I don't believe the overall shape of the fins is an artifact of the MPEG encoding. I believe the MPEG encoder accurately conveyed the overall shape of the fins as it was obtained from the image sensor...

Dave,
Then the only disagreement we have is how much the encoding is distorting the image. I originally misread your post to say you concluded the flutter effect was caused soley by the image sensor, not as a combination of the sensor and flutter.

I have examined the frames from the video at the 'macroblock' level, (I sub-divide each macroblock into its 8x8 pixel subsets) and can only conclude that encoding is causing significant distortion in some frames.

The other thing that's hard to figure is the twisting of the fin. It's clear that not only is the fin oscillating from side-to-side, but also twisting along its vertical axis. I think it is when the fin twists and the blue color of the fin becomes prominent that the encoder fails and the shape of the fin can no longer be reliably discerned. This is most noticeable on the left fin.

I think we really agree on the basic premise - that real fin flutter is being exaggerated by the digital representation of the image. The wild changes in shape are more a product of the recording process than an accurate depiction of what really happened.


tms

 

[DaveHein]

I'm spending way too much time on this topic, but I find it somewhat interesting. One way to demonstrate the flutter artifact produced by the Aiptek camera is to make a video of an object that is oscillating. My son did a science fair experiment a few months ago using a wooden ruler attached to stand made from a block of wood. I put my PenCam on a tripod and held the block of wood down by one hand while pulling back and releasing the other end of the ruler with my free hand.

I observed the ruler visually and it just oscillates back and forth without any ripples in the ruler. When I did this experiment in room lighting the video just showed a blur where the ruler was oscillating. I moved the experiment outside in the sunlight and recorded an interesting video sequence. I cut-and-pasted pieces from four sequential frames as shown below.

I put the short 10-second video on YouTube at the following address

https://www.youtube.com/watch?v=hScRu3KbeV0

The flutter effect is much stronger in this experiment than in the rocket video. However, this is exactly the same effect that we see in the fin flutter video.

Dave

 

[2muchstuff]

Originally posted by DaveHein
I'm spending way too much time on this topic, but I find it somewhat interesting. One way to demonstrate the flutter artifact produced by the Aiptek camera is to make a video of an object that is oscillating. ... However, this is exactly the same effect that we see in the fin flutter video.

Dave,
Great job showing how the scan rate of the sensor can create a visual artifact that defies 'normal' physics. It also demonstrates how slow the scan rate of the Aiptek camera is.

The compression artifacts are still in the fin flutter video. But I think you have conclusively shown that the wild shape oscillation is due to the sensor and normal flutter. Bob Kretch and others claimed it was the material, but to me, that explanation never made sense.

If I wasn't so busy this coming week, I'd repeat your test with a 'normal' video camera and one set to progressive scan. It would be interesting to compare the results.

Thanks for taking the time to post your results,


tms