Falcon 9 velocity/altitude values from webcast

[Space Opera]

Dear all,

I have written a fully automated algorithm that is able to get the videos from SpaceX on Youtube, to run Optical Character Recognition (OCR) on each frame of the videos, to get time, frame number, altitude and velocity at each image and to post-process this. All the regions of interest for OCR are visible in the rectangle in this figure:

The post-processing consists in filtering and clean interpolation of the data to make it suitable for analysis. Raw data is heavily impacted by lag in the framerate, by rounding errors, by actual glitches in the telemetry display and occasionnaly by OCR errors, so that it needs time and love to become nice and a bit more reliable.
The automated process includes the creation of an Excel file with both raw and filtred data. Now that I have this algorithm working very efficiently on all previous videos with suitable display (i.e. CRS-9, Eutelsat, Jason-3, JCSAt-14, JCSAT-16, SES-9 and Thaicom-8), I will be able to update this post at each new launch with the same graphical interface in the webcast (can't wait NSF2017 with wiki-like pages). Sometimes the telemetry is cut-off a bit short during the webcast so the data is obvioulsy depending on what is visible, but overall it works surprisingly well.

I have seen many people here struggling with data by hand and naked eye to build curves, and I hope this file will help those interested in the only reliable source of data for Falcon 9 trajectory (or at least altitude and velocity norm). You can use it as you wish, to compare flights, to guess the position, etc

Some examples of what can be directly visualized from this file:



----------------------------------------------------------------------------------------------------------------------

Structure of the file:
- 1 sheet per flight
- First line is a comment to indicate if the raw velocity (as shown in the webcast) is in km/h or in m/s
- Columns A to D are the raw data :
--- Column A is the number of video frames since T0. T0 is automatically detected when "T-00:00:00" becomes "T+00:00:00".
--- Column B is a direct transcription of the chronometer.
--- Column C is a direct transcription of the altitude, in m (although shown in km in the webcast).
--- Column D is the velocity, expressed either in km/h for earlier missions and in m/s for the latest missions.
- Columns G to I are the cleaned data:
--- Column G is the time, expressed in seconds since T0. Time sample is 0.1s.
--- Column H is the filtred altitude, in m.
--- Column I is the filtred velocity norm, in m/s.

Don't hesitate to play with the data, to give me any feedback and to suggest any improvement, I'll do my best to implement it. And come back after each flight for the updated version of the document.

Space Opera.

[AnalogMan]

I had a little play with plotting some data - here are graphs for Jason-3.  Acceleration curve was generated by numerical differentiation of the velocity data.

[Hobbes-22]

Interesting project.

About the lag in the framerate: would it help if you could download the file from YouTube to a local .mp4 file, so you can play it without interference from Youtube's servers and your internet link? Or are you already doing that and is the source material compromised?

[Semmel]

Wow, thanks! That is very interesting. I was thinking of doing something similar myself but didnt get very far because I lack the skills in video frame grabbing. I was thinking of using long exposure images and triangulation to get the flight path and take it from there. Your data is far better! Lets see if I can squeeze out some more info from your data. Unfortunately I just arrived at work and dont have time for that. Cant wait.. my fingers are itching like crazy!

[JamesH65]

Interesting project.

About the lag in the framerate: would it help if you could download the file from YouTube to a local .mp4 file, so you can play it without interference from Youtube's servers and your internet link? Or are you already doing that and is the source material compromised?

I believe the source is inaccurate - ie the on screen data doesn't seem to match what the image shows. The lag is in the SpaceX 'reporting', not the final video.

[Space Opera]

You are right, the lag is not due to the video format itself. Of course, I first download the *.mp4 file in 1080p, I don't stream it directly. And the lag comes from the telemetry, not from the video. It appears that the chronometer behaves as expected (so it is probably run "offline", and not an input from the telemetry), but both the velocity and the altitude are sometimes stucked for several frames on one value. Almost invisible with the naked eye, but very visible in the charts.

[Semmel]

Space Opera,

Thanks for the data. I want to analyse it with python and to do that its best to have the data within a text file. Now, I could do that from your excel sheets manually but for future flights, it would be best to have the data in a text file format like .csv for instance. Could you change your program such that it produces text files instead of excel? Also, a separate file for the frame grab data and the interpolated data would be fantastic because the index value (frame number vs. time) is not the same. Could you do that?

Cheers,
Semmel

@edit: examples for THAICOM_8 appended. You can use other delimiters but tabulator if you want, its not important. Also, I used the .txt ending because the forum restrictions do not know .csv.

[S.Paulissen]

Is copying and pasting spreadsheets into notepad and seeing it as tab delimited that much work?

[Space Opera]

Yes Semmel I can do that easily, it is the same effort for me.

Do you expect ( 1 file for raw data + 1 file for filtred data) * each flight ? It will be a lot of files...

[Semmel]

Space Opera,

you wanted some feedback.. After first data inspection of the thaicom launch, it seems your interpolation is very slightly underestimating the true value. Nothing serious but maybe worth a fix. I cant do it right now my self because there is some problem with some packages and I dont have the time to fix it. Need to wait until the weekend for that. See the appendix for a visualization. Otherwise, quite good interpolation, nice and smooth and not overfitted. @edit: see appended figure.

Paulissen,

I have very limited time at moment. My 3 month old son requires almost all my free time and I would rather spend what limited time I have on analysing data rather than fixing the format. Its probably some 2-liner for Space Opera to output the data as text files. Doing it that way is much more efficient than manually. Also I am a programmer, I hate to do repetitive tasks manually if it can be automated. If you think its not much work, be my guest.

[Semmel]

Yes Semmel I can do that easily, it is the same effort for me.

Do you expect ( 1 file for raw data + 1 file for filtred data) * each flight ? It will be a lot of files...

See, there I go for to make sing him into sleep and you have an answer already. Yes, one raw file per flight and one interpolated one might be best. Also easily scalable for future flight so you dont have to update existing data all the time.

[S.Paulissen]

This is very interesting. I never realized that staging-reignition took so long.  When I reduce the resolution to 1s, there is a 10s window of zero to negative velocity change between, ostensibly the time between MECO-SECI.

s  m/s
1 8123
2 8262
3 8331
4 8343<-meco
5 8333
6 8323
7 8313
8 8296
9 8284
10 8272
11 8255
12 8243
13 8231
14 8229
15 8238<-seci
16 8248
17 8265

EDIT: apparently my crude method does the same thing Semmel.

[Semmel]

Paulissen,

It doesnt look like Space Opera always took the lowest value for a sequence of identical values. It seems to be more intelligent, especially at the beginning and end. I try to improve some other time.

Here is a plot showing some values. I used the atmospheric model from Wikipedia to include atmospheric drag in order to see MaxQ. It looks grossly wrong though. I always imagined the peek to be much slimmer and it also should align with the throttle back as seen in the acceleration data. At least the order of magnitude of the drag force seems to be reasonable (about 20% of F9 thrust)

I used these equations:
air density: https://en.wikipedia.org/wiki/Atmospheric_pressure#Altitude_variation
drag: https://en.wikipedia.org/wiki/Atmospheric_drag#Drag_at_high_velocity
and included the values provided by Space Opera for hight and velocity.
For the F9, I used
fairing cross section area in m^2: A = (0.5 * 5.2)**2 * Pi
drag coefficient (guess) for the fairing: C_d = 0.07
pressure at sea level: p_0 = 10132
scale height: h_0 = 8435
and the equations
p = p_0 * exp(-h / h_0)
F = 0.5 * p * v**2 * C_d * A
where v is the velocity in m/s, h the height in m, p the air pressure and F the force of the drag.

[Space Opera]

Your work is pretty cool and deserves a comparison to the actual max-q indicated for each mission. I could apply voice recognition as well to get the moment the speaker says "max-q" (half kidding).
As you noticed, I have done something a bit more tricky in terms of interpolation than just "blind" interpolation. In addition, I have to guess how their altitude data is rounded: is it a round(), a floor() or a ceil() ? Consistency checks seem to say it is round(), but I'm still not very confortable with this conclusion.

I take good note for your observations about the under-estimated values, and I will check tomorrow where it comes from and correct it if needed.

[Proponent]

Very cool, Space Opera!

Does SpaceX use the same reference frame all the way from take-off to orbit?  My recollection from LEO launches was that the burn-out speed was consistent with circular speed in an inertial frame, but the that speeds early in flight were obviously in a rotating, Earth-fixed frame (otherwise the speed at lift-off would be over 300 m/s).

Is the speed deduced at the moment the rocket reaches Mach 1 (I haven't seen recent launches, but in earlier launches this was called out) consistent with a rotating frame, allowing for a lag?

[S.Paulissen]

Very cool, Space Opera!

Does SpaceX use the same reference frame all the way from take-off to orbit?  My recollection from LEO launches was that the burn-out speed was consistent with circular speed in an inertial frame, but the that speeds early in flight were obviously in a rotating, Earth-fixed frame (otherwise the speed at lift-off would be over 300 m/s).

Is the speed deduced at the moment the rocket reaches Mach 1 (I haven't seen recent launches, but in earlier launches this was called out) consistent with a rotating frame, allowing for a lag?

The raw data says they only ever reach 7480.6 m/s  so I assume they -only- use inertial frame. As a 160km  altitude orbit is 7811 m/s. Net: about the rotational speed they get for free.

EDIT:

I, again, very crudely smoothed the function in a way that ... I sort of am okay with.  After simply averaging the duration of the track (520s) with the number of observations I got a time 'step size' of 0.033309s which comes out to (unsurprisingly the frame rate of the video 30.022), and smoothed the time function by incrementing EVERY data read out 0.033309s and got, a smoother but essentially the same graph I had before, with the data only barely meeting the bottom of the raw points, but only on occasion.  I then realized that the raw data is 'backwards skewed' in the time dimension as it accumulates velocity for ~1s while being frozen in time before stepping forward to meet 'reality'.  To be honest, these curves that only meet the bottom are probably more correct than wrong.
 
To fairly visualize the smoothened data I tried to 'mimic' the backwards time bias by making the smoothened data look forward 30 frames, and averaging them to get the following graph.

[Semmel]

Ach right.. The lack of knowledge of the rounding method and also the lack of knowledge how and when the data is projected onto the screen makes the true curve anybodies guess. I have to revoke my statement that the interpolation needs improving, please leave it ad it is Space Opera.

[Proponent]

The raw data says they only ever reach 7480.6 m/s  so I assume they -only- use inertial frame. As a 160km  altitude orbit is 7811 m/s. Net: about the rotational speed they get for free.

Thanks, S. Paulissen.  I presume you mean "rotating frame" rather than "inertial frame."

[Space Opera]

Does anyone could provide the launch azimuth for each flight ? From this information, I should be able to reconstruct a crude 3D trajectory as well...

[S.Paulissen]

Does anyone could provide the launch azimuth for each flight ? From this information, I should be able to reconstruct a crude 3D trajectory as well...

I know that SES-8 and 9, JCSAT14 and 16, AMOS6, Thaicom8,and  ABS/eutelsat2 were a 90 degree azimuth, and I don't think it'd be a stretch at all to say that all GTO launches are 90 degrees as well.  The little bit of inclination change is done during the GTO insertion burn.

http://www.faa.gov/about/office_org/headquarters_offices/ast/licenses_permits/media/LLS%2014-090%20Rev%202%20-%20License%20and%20Orders%20(FINAL)%2001_21_2016%20-%20signed%20copy.pdf

CRS-6 was 46.62 degrees azimuth. And most CRS missions will be nearly 42.

Jason3 was 142.8 according to one article but that doesn't sound right to me.
http://www.nasa.gov/press-release/noaa-s-jason-3-spacecraft-ready-for-launch-0

The raw data says they only ever reach 7480.6 m/s  so I assume they -only- use inertial frame. As a 160km  altitude orbit is 7811 m/s. Net: about the rotational speed they get for free.

Thanks, S. Paulissen.  I presume you mean "rotating frame" rather than "inertial frame."

Yes.  I have no idea why I wrote the wrong thing up there.  Not enough coffee I guess.