Using the video data reduction sheet:
To determine the inflight speeds of a model, lacking any form of on-board telemetry to send the
data to a ground station, the position of the plane can be read from a video tape of a test flight.
With a properly flown and positioned plane, the planeís change in location on each frame of the video
tape can be translated into its speed.
A camcorder, a VCR, and some manner of video-to-computer frame grabber is required.
I use Intel Create & Share Software which comes with a web-camera for interfacing between the VCR
and the computer, and JASC Paint Shop Pro v7.0, for its animation feature with the images imported
from the camcorder tape to the computer..
The flying portion of the test should consist of the plane flying past the camera, probably no more
than 125 feet away, to give a reasonably sized image on the tape without needing much enlargement via use
of the telephoto capability of the camera. Level passes in both directions to account for any wind should
be performed, in the event of wind. Calm is best since that gives airspeed directly without needing the
The camera can be set fixed on a tripod, looking towards the test area.. Set to look where the plane
will be flown. Or it can be panned with the planeís motion.. In which case some fixed objects will need
to be in the field of view to relate the planeís change of position in each frame. An image size about 10%
of the field of view width is optimum..
Owing to the scan pattern of NTSC video, Ĺ the lines of the image being scanned first, and then the
other Ĺ , thereís a situation where the image will smear on the tape, due to the odd-even scan line process.
This can make the image difficult to impossible to read. The camcorder should have a high-speed shutter
selection. The normal shutter speed is much too slow to get anything other than a smear either of the plane
with the fixed camera, or the background with a panning camera.
Even with a higher (shorter) shutter speed, the images for the odd lines and even lines will be in
different locations on the tape due to the planeís position changing between the scan times.
With the plane close and fast, this makes the images too long and indistinct. With the plane far
enough away for the motion to be indetectable, the image will unfortunately be too small to be useable.
A test run or two will find a happy medium between plane location, field of view, type of
Once the test flights are flown, the image from the camcorder tape is best transferred to a VCR for
ease of use in putting the information into a computer with the frame grabber system. A VHS-C camcorder
simplifies this step, as the tape can be read directly in the VCR.
Generally this comes in to the computer as an *.AVI file.
A paint program or an animation program can take this .avi file and prune the extra frames not needed
for the analysis. Generally more than 5 but not more than 20 frames will be needed. Each image of the
test sequence should be examined for the following information: a predetermined reference point at one
end of the plane, generally the spinner or some other easily picked out feature, to read the x and y
positions.. And some other predetermined location on the plane to use for determining the size of the
image, such at the vertical finís trailing edge. (Figure 1) The dimension between the two points will
be used to compute the airspeed.
If the program has the ability to read/display the position of the mouse cursor directly itís handier
than guessing the numbers off a scale on the side of the image. Itís handy to annotate each frame
of the test sequence permanently. This makes it easier to insert any frames from the test sequence if
such are needed.
After 5 or whatever frames are read, the information is placed in the spreadsheet:
The x dimension, y dimension and length in the appropriate cells. The distance between the parts of
the plane used to determine the size (best if theyíre as shown in Fig. 1), the weight, wing area and the local
atmospheric density are also input in the appropriate yellowed cells..
As the cell information is input, the results are computed.. Ignore these until all the data has
been input. Due to idiosyncracies in the frame grabber programs, thereís a good chance that some of
the video frames in the sequence were not captured to the computer. This will show up in the reduced
data, pixels array as inconsistencies in the reduced data. There can be discrepancies of 2x and 3x
between x positions between frames.
The smallest delta value computed can indicate how much the other values are off.. For instance a
value of 9 in the del-x column with 18s and 36s indicate frames have been missed.
This indicates one (2x) frame was skipped, or 2 (3x) frames were skipped, and another pass thru the
frame grabber is needed.
The new frames are read, and any with information not in the initial pass have their information read
and inserted where it should be. Basically this gives confidence in the quality of the overall results
to not have to interpolate missing data.
With a panning camera, additional information from selected fixed objects in the frame must be read.
In this example a tree in the background.. (note the blurring due to panning) is selected.
The position of the intersection of the vertical and horizontal tail is read for the x, and the
spinner for the length. The position of the selected fixed object is input in the raw data array.
With a fixed camera this data need not be read.
Itís a good idea to ignore the computations the program performs on the data as itís input. Guessing
ahead is a trap that leads to erroneous input values. Wait until all the data is in the sheet before
evaluating any of it!
This is where a data set may differ from another in the useable range. When the values in the cells in
column G and I are within one pixel of the neighboring values in the column, the data set is valid to be
used for interpretation. If there's a discrepancy of more than one pixel, then the raw data must be
examined to find the problem.. Either a data value read incorrectly off the image, input incorrectly,
or is an indication a frame was missed in the data process between the VCR tape and the information
imported to the computer. This generally shows up as a 2X or 3X difference between cell values..
For example, reading down in column G, a sequence 12,12,24,12,12.. indicates a frame of data is missing
between the second and third data sets. The flight test camcorder tape should be recaptured and played
into the computer, with the data points read as per the first run-thru. It pays to have annotated each
frame of the data sequence, so that only the frame(s) containing data missed the first time need be read
and inserted in the data columns.
Some care is needed to prevent computational sequential errors when inserting information:
For example, inserting a row for new data in the raw data input block creates a series of ERR notations
in the data reduction block. The equations in that block must be corrected for the cells below the inserted
row by copying an unaltered row or set to the new block.
Moving only the raw data block down one row creates a mis-count in the cells in the data reduction
block below the row of new data. This must also be corrected..
It's best (but not easiest) to type the new data over the existing data.
The recommended method around this finger-poken in the cell equations is to expect to have to read
another data pass.. Make two tape copies and import both into the computer. Read all the information off
both sets of data, combining frames that are in one set with frames found missing, from the other for a
continuous set of information.
Figure 5 shows a data page from two passes thru the animation program, reading the data points from
the screen. The first pass reading indicated there would be some 2X steps in points at frames 3,6,8, and 10.
Reading another copy of the information, comparing the first "x" values, not recording those that were
duplicated did find the missing frames, which were read, and inserted into the original .avi file for a
continuous presentation of the fly-by. Another frame at the end was found in the second pass.
How the spreadsheet is constructed:
The Airspeed spreadsheet
The cell columns B thru F, rows1 thru 21 are for the raw data read off the digital image.
|| raw data,pixels
|| reduced data, pixels
|| computed per frame
|| frame #
|| x, pixels
|| y pixels
|| *fixed obj
|| x del
|| del x
|| climb rate, fps
Note: as few as 3 sets of input data will suffice.. the more good information though,the more
precise and accurate the final computations.
The columns and rows of G thru J do the data reduction automatically. Don't use these
cells for input or change anything in these cells!!!
"x del" is the computed difference between two data entry cells
"del x" is the computed difference between two "x del" cells
"altitude" is the computed difference between two "y" cells
"length" is the computed difference between "x del" and "length" in the data entry cell
Cells G 28, H 28 and I 28 average the reduced data for the range of input data.
The average airspeed for the interval is computed:@INT(@AVG(G6..G25))
The rate of altitude change in the interval is computed:@INT(@AVG(H6..H25))
The average length for the interval is computed:@INT(@AVG(I6..I25))
Note.. these cells control the amount and accuracy of the later information. The span of
cells used is selected by judgement, looking for constant or near constant differences between
succeeding cells in the computed data ranges. No values 2x or higher greater than the average
for any two cells.
Columns K and L compute the information from the reduced data.
The distance traveled per frame is computed to airspeed
@IF(G9=0,"TBD",((G9/I9)*~length/12)*30) is the airspeed for the sequence.........
The lift coefficient for that airspeed, based on weight and wingarea is computed.
In column M, the rows thru 11 present the results..
Average airspeed for the interval is computed in ft/sec and mph.
The block M14 thru O17 are input constants:
Atmospheric density, fuselage length, gross weight and wing area.
PJBís Seriously Aeronautical Stuff
..Return to Main Menu
E-mail to: Paul J. Burke