"GO FAST" Footage from Tom DeLonge's To The Stars Academy. Bird? Balloon?

[Mick West]

I suppose he revised his calculations because it wasn't fitting the original narrative of TTSA that the object must be moving fast 380 Kn at a low altitude of 100 ft)

I think he did some revision after discovering the CAS/TAS problem, he's still using 250 knots there (CAS)

 

[Kaen]

The question is if the event log fits the objective events.

Here's a theory: occasionally, over the course of a decade, a pilot will lose situational awareness, but not realize it, and then later write down what he recalled observing.

Yes, but what makes this case interesting is that a second jet was involved and its pilot, Jim Slaight, also seems to have lost situational awareness:

Upon noticing the object, David Fravor indicated over the radio "I'm in" to which Jim Slaight replied "I have high cover". David Fravor conducted an aggressive banking maneuver and dropped his aircraft at the same time in order to catch up with the object.
The object immediately responded. Jim Slaight was worried for David Fravor and his WSO because he thought they wouldn't stand a chance against the object which conducted maneuvers like no aircraft or missile ever could. The object began to make deliberate changes in altitude, attitude, and angle in a manner that seemed to defy the laws of flight physics and that made any engagement by Fravor's F18 impossible.

Fravor's recollection is not of the events shown in the video, and really should be treated as separate.

Yes, the video was not made by Fravor, but some time later from another jet at another location - the jet was sent there because the object re-appeared on radar.

But this is the GO FAST thread.

Noted, so I'll stop now

 

[Mick West]

Sounds like he did some good work there.

Except for the GIGO aspect. He used the composite screenshot from TTSA which had 4.1 RNG at 22°, when the actual angle was 28°. Also got the plane speed wrong, as mentioned above. And he got the time wrong. All of which I think he later corrected.

 

[Mick West]

When assuming how the ATFLIR camera tracks is there anything I should be taking in to account? Can I discount the roll of the aircraft as the camera compensates and translate the camera mount in the x,y,z only?

I think so.

It would be useful to demonstrate the difference between the ground tracking (based on atltude and angles) and a "snowplow" mode where the camera points in a fixed direction/tilt.

The start of the video (e.g from 00:01 to 00:03) appears to be ground tracking, which kind of gives the illusion it was filmed from a helicopter. If it were in snowplow mode I think the sea would be whizzing by. So that would be good to show.

 

[Tom Mellett]

I think he did some revision after discovering the CAS/TAS problem, he's still using 250 knots there (CAS)

Mick, but that begs the question of who determined the original narrative of TTSA that the object was flying very fast (380 kn) very close to the surface (altitude = 100 ft.). I don't think they based it on Macabee's calculations, which were made March 9 and March 12.

EDIT: Here's the link
https://coi.tothestarsacademy.com/2015-go-fast-footage/

The unidentified vehicle appears as a white oval shape moving at high speed from top right to lower left of the screen flying very low over the water.

 

[Mick West]

Mick, but that begs the question of who determined the original narrative of TTSA that the object was flying very fast (380 kn) very close to the surface (altitude = 100 ft.). I don't think they based it on Macabee's calculations, which were made March 9 and March 12.

EDIT: Here's the link
https://coi.tothestarsacademy.com/2015-go-fast-footage/

The unidentified vehicle appears as a white oval shape moving at high speed from top right to lower left of the screen flying very low over the water.

They don't say 380 knots there, or anywhere that I know of.

Their analysis there is incredibly weak, and seems to be based entirely on a subjective visual assessment. i.e. they simply think it looks like it's close to the ocean surface. So I suspect whoever did it was a pretty non-technical person, perhaps Elizondo? Whoever it was, it's reflected very poorly on TTSA's technical abilities.

 

[Tom Mellett]

They don't say 380 knots there, or anywhere that I know of.

Their analysis there is incredibly weak, and seems to be based entirely on a subjective visual assessment. i.e. they simply think it looks like it's close to the ocean surface. So I suspect whoever did it was a pretty non-technical person, perhaps Elizondo? Whoever it was, it's reflected very poorly on TTSA's technical abilities.

OK, I got those numbers from Garry Nolan. Now that there's a clearer picture of TTSA incompetence, I will go back and ask Garry where he got those numbers from.

 

[Tom Mellett]

Sounds like he did some good work there.

But what is baffling to me is that he did calculate an object altitude of 1.6 nm which I round up to 10,000 feet. And he even made a remark that this altitude is not close to the ground, thus directly contradicting the "Official" TTSA narrative about the object being very close to the water surface. And yet he still ignored the parallax effect of that altitude in his speed calculations.

Mick already noted his error of using CAS instead of TAS, but at least this version shows that BM is not responsible for the official TTSA statement about the object altitude.

 

[Kaen]

Hello @Kaen ! Thank you so much for that diagram above. It is really helpful to explain parallax effect to those unfamiliar with it.

However, before I ask you questions I have about the assumptions made in the diagram, I would like to drop back and punt because I just discovered on FB Bruce Maccabee's Original calculations made on March 9. (You operated only from his revised calculations dated March 12.) Here is the text of his original calculations. Does it give you any more insight into his process? It looks like his original calculations were more in line with yours, but then I suppose he revised his calculations because it wasn't fitting the original narrative of TTSA that the object must be moving fast 380 Kn at a low altitude of 100 ft)

Bruce probably based his calculations on a period in the video above where the object crosses the display while the ATFLIR is more or less fixed on the same patch of sea. This is the period from 5,5 s – 7,3 s (duration 1,8 s).

The picture below contains the snapshots of the object entering and leaving the FOV. I projected the object's end position in the first picture, taking a slight shift of the camera into account (the white rectangle shows the same patch of sea). From these two positions I calculated the percentage of the ATFLIR FOV that the object crossed in these 1,8 seconds.

Let's go through Bruce's calculations step by step:

Object altitude calculated as: (4.1 nm [height of plane] – (4.1 slant range [plane to object]) x sin 22 = 4.1 – 1.54 = 2.46 below airplane altitude;
[Later he changes the 4,1 nm to 4,5 nm:] The exact distance to the object at that time is not known because the system had not yet locked on. However when it did lock on a short time later the range was about 4.1 nm and decreasing. I therefore "guesstimate" the range at 4.5 nm.

The calculated 2,46 nm is not a 'below airplane altitude' but the actual object altitude.
During Bruce's 1,8 s period, the object slant vector is at a downward angle of 24 degrees, not 22.
Slant range is unknown at that time, but can be estimated: At 12 s it is 4,4 nm and decreasing with 0,1 nm per 1,8 s. So at 6 s in the video the estimated slant range would be 4,4 + (0,1 x 6/1,8) = 4,7 nm, not 4,1 (later 4,5).

This gives an altitude difference between jet and object of 4,7 x sin(24) = 1,9 nm.
Jet is at 4,1 nm altitude so object is at 4,1 – 1,9 = 2,2 nm altitude (13.300 feet), not 2,46.

At 4.1 nm range to the object, the distance across the 1.5 deg FOV is (4.1nm) x [1.5 deg x 0.0174 rad/deg]= 0.1 nm.
[Later he corrects this value for the new range of 4,5 nm:] The width of the FOV is 1.5 deg x 0.0174 rad/deg = 0.026 rad which corresponds to 0.117 nm at 4.5 nm distance.

The actual range is closer to 4,7 nm (see above). This gives 0,12 nm instead of 0,1 (later 0,117 nm).

I wonder whether the 1,5 degrees FOV is correct. I thought this was the FOV at zoom level 2, it may be 0,3 degrees at zoom level 1. This would double the value to 0,24 nm

It crosses the FOV at about a 45 deg angle so the actual approximate distance across the FOV is 0.1 nm/0.707 = 0.14 nm;
[Later he corrects this value for the new range of 4,5 nm:] The object crossed the FOV area at an angle of about 45 deg so the distance traveled as it crossed the FOV was about (0.026 rad) x 1.41(to account for the 45 degree crossing) x 4.5 nm = 0.165 nm.

I made a more accurate estimate of the FOV coverage (see picture above), it is 1,31 so the total distance is 1,31 x 0,12 = 0,16 nm instead of 0,14 (later 0,165 nm).

it crosses in 4 to 3 sec implying a differential speed of the plane and object of 0.14 nm/ ( 4 to 3 sec)/(one hour/ 3600) = 126 to 170 kt)…
[Later he corrects this value to 1,8 s and the speed to 330 kt:] I found that it took about 55 frames at 30 frames/ sec which corresponds to 55/30 = 1.8 sec. It traveled this distance in about 1.8 sec for a speed of 0.092 nm/sec which is about 330 kt....about twice the larger speed previously calculated but certainly not an earth shaking speed.

With the 0,16 instead of 0,165 nm this yields a differential speed of 0,16/1,8 = 0,089 nm/s = 316 kt instead of 330 kt, so very close to Bruce's value.

Since the plane is going at about 250 kt the object was going at the speed approx. (250 – 150) = 100 kt in the same direction as the airplane but clearly slower)calculation assumes land speed is approx. same as air speed) )))

The 330 kt is a differential speed and needs to be compensated for the parallax effect. Here, Bruce makes some crude approximations using the CAS of the jet, and assuming the parallax compensation equals the jet speed.
In reality the parallax compensation is 0,52 x the jet speed (see my post about the parallax). The camera shifts a little (about 16% of the FOV) along with the object's trajectory while the object passes. This will add an additional 16% to the parallax compensation speed that I estimated (267 kt instead of 230 kt).

Note that the speed in the ATFLIR display being CAS is solely based on the annotations in the video made by TTSA. Maybe TTSA was wrong and the speed is based on something else like GPS data.


A few additional remarks:

The assumed FOV of the ATFLIR is 1,5 degrees. It may be twice that, i.e., the narrow FOV of an ATFLIR is 3 degrees according this document:
https://www.forecastinternational.com/archive/disp_old_pdf.cfm?ARC_ID=452
That would double the computed differential speed of the object to approximately 650 knots. This speed no longer implies a bird or balloon, and it no longer complies with the speeds computed earlier in this thread.

The object seems to travel against the direction of the jet, while other calculations made in this thread indicate it travels in the opposite direction. This is odd.

 

[Robert Sheaffer]

He can state it all he wants but he really need to show some reason why he thinks that.

The focal plane of something flying at 12,500 feet would not allow for waves to be seen in the background as they are.

Why not?

And where is the focal plane exactly? Nothing really appears to be in particularly sharp focus.

The focus for a camera set on an object 12,000 feet away will certainly also be in good focus for an object 25,000 feet away.

 

[Tom Mellett]

I wonder whether the 1,5 degrees FOV is correct. I thought this was the FOV at zoom level 2, it may be 0,3 degrees at zoom level 1. This would double the value to 0,24 nm

It crosses the FOV at about a 45 deg angle so the actual approximate distance across the FOV is 0.1 nm/0.707 = 0.14 nm;
[Later he corrects this value for the new range of 4,5 nm:] The object crossed the FOV area at an angle of about 45 deg so the distance traveled as it crossed the FOV was about (0.026 rad) x 1.41(to account for the 45 degree crossing) x 4.5 nm = 0.165 nm.

I made a more accurate estimate of the FOV coverage (see picture above), it is 1,31 so the total distance is 1,31 x 0,12 = 0,16 nm instead of 0,14 (later 0,165 nm).

it crosses in 4 to 3 sec implying a differential speed of the plane and object of 0.14 nm/ ( 4 to 3 sec)/(one hour/ 3600) = 126 to 170 kt)…
[Later he corrects this value to 1,8 s and the speed to 330 kt:] I found that it took about 55 frames at 30 frames/ sec which corresponds to 55/30 = 1.8 sec. It traveled this distance in about 1.8 sec for a speed of 0.092 nm/sec which is about 330 kt....about twice the larger speed previously calculated but certainly not an earth shaking speed.

With the 0,16 instead of 0,165 nm this yields a differential speed of 0,16/1,8 = 0,089 nm/s = 316 kt instead of 330 kt, so very close to Bruce's value.

Since the plane is going at about 250 kt the object was going at the speed approx. (250 – 150) = 100 kt in the same direction as the airplane but clearly slower)calculation assumes land speed is approx. same as air speed) )))

The 330 kt is a differential speed and needs to be compensated for the parallax effect. Here, Bruce makes some crude approximations using the CAS of the jet, and assuming the parallax compensation equals the jet speed.
In reality the parallax compensation is 0,52 x the jet speed (see my post about the parallax). The camera shifts a little (about 16% of the FOV) along with the object's trajectory while the object passes. This will add an additional 16% to the parallax compensation speed that I estimated (267 kt instead of 230 kt).

Note that the speed in the ATFLIR display being CAS is solely based on the annotations in the video made by TTSA. Maybe TTSA was wrong and the speed is based on something else like GPS data.


A few additional remarks:

The assumed FOV of the ATFLIR is 1,5 degrees. It may be twice that, i.e., the narrow FOV of an ATFLIR is 3 degrees according this document:
https://www.forecastinternational.com/archive/disp_old_pdf.cfm?ARC_ID=452
That would double the computed differential speed of the object to approximately 650 knots. This speed no longer implies a bird or balloon, and it no longer complies with the speeds computed earlier in this thread.

The object seems to travel against the direction of the jet, while other calculations made in this thread indicate it travels in the opposite direction. This is odd.

First of all, the document you link to is an older generation ATFLIR, the NITE-Hawk. Instead of doubling the FOV from 1.5 to 3.0, you may need to cut it in half to 0.7.

The Paracaster calling himself Realm makes an argument that the FOV for this "3rd video" has to be 0.7

https://www.theparacast.com/forum/t...udy-media-monitoring.19069/page-5#post-270549

I made another effort on finding the FOV for the ATFLIR for better estimates of the target size, and also confirmations on the sensor resolution. Here's what I found:

TL;DR version: the NAR mode most likely has 0.7° FOV, meaning the bird is only half the size of most estimates.

He quotes from a Raytheon brochure:

The fourth generation version of LITENING, built by Northrop Grumman, features the 1024 x 1024 pixels FLIR sensor for improved target detection and recognition ranges under day/night conditions; new sensors for improved target identification; and other advanced target recognition and identification features. Other product improvements include a new 1k charge-coupled device sensor, which provides improved target detection and recognition ranges under daylight conditions.

Notice the Narrow FOV of 0.7

ATFLIR specs (it also lists 4 other products with FPA 640x512 and one with 320x240):
name: Raytheon AN/ASQ-228 advanced sight FLIR（ATFLIR）
detector: InSb FPA 640×480 (centerline space 25μm)
waveband: 3.7～5.0μm
field of view: Wide: 6.0°; middle: 2.8°; narrow: 0.7°

Here again notice the Narrow FOV as 0.7
And @Kaen , notice in the next line that this version replaces the older NITE-Hawk that you linked to above.

ATFLIR specs again:
Raytheon AN/ASQ-228 ATFLIR, recently named Terminator
Dimensions: L: 183 cm/72 in D: 33 cm/13 in W: 191 kg/ 420 lb
Capabilities: 640 480 FPA FLIR operating in MWIR: WFOV 6 6; MFOV 2.8 2.8; NFOV 0.7 0.7
Carrier aircraft: F/A-18A þ , C/D,E/F Replacement for AN/AAS38 Nite-Hawk

 

[jarlrmai]

When I finally made what I consider to be a close approximation to the video in Blender the parallax looks closest with a fov of 0.7 and an object of 1 meter, the power of the ATFLIR is quite ludicrous this is tracking an object of that size from kilometers away. Hard part of the video is a sea texture that looks close to the video.

 

[jarlrmai]

Rough 1st draft proof of concept, whatever other disclaimers you need this is a try.


Source: https://youtu.be/j1O4iBke2vo


assumptions used in render

Object is ~1 meter
Object is stationary (clearly not the case in reality)
FOV is 0.7
Video is 30 fps, tracking lasts 22 seconds, video is 660 frames camera position keyframes each second based on values from post on this thread by JUSTIN SHAW for the tracking period.
Camera tracks object using a constraint in Blender may not match exact tracking characteristics of the ATFLIR.

It would be helpful if someone could confirm the object's position relative to the camera (x/y) at the start of tracking ie how far in front and to the left it is. I have used 5k left of camera and 5.2k ahead.

I can provide the .blend if anyone wants.

 

[Mick West]

I can provide the .blend if anyone wants.

Yes please. You should be able to upload it, or mick@metabunk.org

 

[Agent K]

First of all, the document you link to is an older generation ATFLIR, the NITE-Hawk. Instead of doubling the FOV from 1.5 to 3.0, you may need to cut it in half to 0.7.

I've argued for 0.7 degrees based on this old brochure and some other reasons.
https://web.archive.org/web/2009121...s/sas/documents/content/rtn_sas_ds_atflir.pdf

But FAS says 30X magnification, which suggests 1.5 degrees, if 1X magnification is 45 degrees.

ATFLIR's magnification is 30X versus previous FLIR capabilities at 4x.
https://fas.org/man/dod-101/sys/smart/atflir.htm

I thought the "previous FLIR capabilities at 4x" referred to Nite Hawk, but 3 degree FOV is better than 4X magnification.

 

[Agent K]

When assuming how the ATFLIR camera tracks is there anything I should be taking in to account? Can I discount the roll of the aircraft as the camera compensates and translate the camera mount in the x,y,z only?

You can discount the roll of the camera, which isn't displayed in any case, but the video is rolled opposite the roll of the aircraft to keep the horizon horizontal so the WSO doesn't get nauseated. See the Gimbal video. The horizon is tilted in the video, but if you rotate your screen counterclockwise the way it it would be in an aircraft, the horizon will be horizontal.
View attachment 30642

 

[Agent K]

The start of the video (e.g from 00:01 to 00:03) appears to be ground tracking, which kind of gives the illusion it was filmed from a helicopter. If it were in snowplow mode I think the sea would be whizzing by. So that would be good to show.

I wonder if it was in A/G mode or A/A mode. The geopoint ground tracking suggests A/G mode, but all the symbology on the screen resembles the Gimbal video, which was surely A/A.

 

[Mick West]

And zoomed in, in 3D the object motion looks pretty random.

I think that's a bit misleading as the limits of your axes are not square, so it greatly exaggerates the up/down and left/right motion. If you view it in a 0.2 nm cube it's

A more of less straight line within the rather low resolution we have for angles. Then an odd kink at the end.

Here's the code setting the axes' limits, using NMI for everything for simplicity.

	  ax.set_xlim3d([-3.2850, -3.2850+.2])
	  ax.set_xlabel('X')

	  ax.set_ylim3d([1.74, 1.74+.2])
	  ax.set_ylabel('Y')

	  ax.set_zlim3d([2.138, 2.138+.2])
	  ax.set_zlabel('Alt')

	  ax.plot(-gs[:,1] / NMI, gs[:,0] / NMI, gs[:,2] / NMI)

 

[Justin Shaw]

I think that's a bit misleading as the limits of your axes are not square, so it greatly exaggerates the up/down and left/right motion. If you view it in a 0.2 nm cube it's
View attachment 32340

Agreed. I used NMI for my x and y coords and FEET for alt. So a 1-1 scale would have been even more distorted. The 3D spin is a nice touch.

 

[jarlrmai]

Is there a list of timestamped coordinates for the tracked object in this thread?

 

[Mick West]

Is there a list of timestamped coordinates for the tracked object in this thread?

You can't really get one without picking a wind speed and direction. I've been playing with Justin's code, and with the wind at 30,50 and 70 knots (all at 180 degree to the plane's initial heading) the track is radically different. Here the Black dot is the start position, the black triangles are the three end positions. (the red, green, and blue are just the side and top projections).

Notice the 50 knot path ends up near where it started.

Probably we'd need to pick the wind settings that give the best end result in term of matching the motion of the ocean.

What format exactly are you looking for?

 

[Clouds Givemethewillies]

You can't really get one without picking a window(sic) speed and direction. I've been playing with Justin's code, and with the wind at 30,50 and 70 knots (all at 180 degree to the plane's initial heading)

Do you mean 'on the nose' ?
At sea level it looks to me to be about 15+ knots, more or less towards the plane (taking into account the the foreshortening of the waves). 30-50 knots at 2.15 nmi altitude seems reasonable.

 

[Mick West]

Then an odd kink at the end.

That kink appears to be a data problem, @JUSTIN SHAW you were duplicating the last values on the change times, end the final time, meaning it appeared to have a drastic slowdown at the end. I've redone it without the kink

Here's a scale image showing the jet's motion (red) the objects motion (black, barely visible) and the track this makes on the ground (i.e. the sea surface at the center of the image when locked on) . The movement of the object has little effect on the ground projection

But notice the jet has a smooth curve, whereas the ground track varies a bit.

The image includes drop lines from the start and ends of the paths to show the height above the ground.

 

[Mick West]

Code attached

 

[Justin Shaw]

Nice plot @Mick West! I think the conclusion holds: No strange behavior. I'm standing down on this unless we get more data.

Small hint: arange(start, stop, step) will give an array from start up to (but not including) stop. So your "if (WIND_KTS + SPD_STEP < SPD_END):" check is not required. One nice way to get the spdNames populated is to "join" strings with commas. Like this:

speed = arange(SPD_START, SPD_STOP, SPD_STEP) ## make an array of speeds
names = [str(spd) for spd in speeds] ### make a list of string names
comma_sep_names = ','.join(names)

 

[Mick West]

Nice plot @Mick West! I think the conclusion holds: No strange behavior. I'm standing down on this unless we get more data.

Yes I don't think there's a huge amount to be gained here for fine-tuning the details, there's too much inaccuracy (and unknowns) anyway, but the basic thing is there's a slow moving object around 13,000 feet, and the apparent motion is almost entirely from parallax whichever way you dice it.

Here's using all the data (left) vs just the endpoints (right). The track of the object (bottom) varies more, but the end result (top, green) is the same.

 

[Getoffthisplanet]

Code attached

I just did a quick eyeball, this is this the same roll data from After Effects that you posted the other day?

Also, I've been using the raw raw X, Y, Z jet position data posted by @JUSTIN SHAW.

Plotting that data is beyond my abilities, are you saying you have an update?

If so, can you post similar to how he did, so I can just basically copy and paste it into an Excell doc?

x [m], y [m], z [m]
6.33, -0.00,7620.00

 

[Mick West]

I just did a quick eyeball, this is this the same roll data from After Effects that you posted the other day?

Also, I've been using the raw raw X, Y, Z jet position data posted by @JUSTIN SHAW.

Plotting that data is beyond my abilities, are you saying you have an update?

That text file was the roll data used as an input to Justin's code.

The curve I'm plotting are slightly different to the ones shown earlier by Justin as there was a problem with the way wind was handled. The newer code does it better, meaning the angles on the plots now match the numbers.

I can output numbers in script format if you like. Let me know what the actual script looks like that you create with Excel.

 

[Mick West]

Let me know what the actual script looks like that you create with Excel.

In the meantime, here's the positions that match the diagrams above.

 

[Getoffthisplanet]

That's text file was the roll data used as an input to Justin's code.

Right. Just want to double check if goFastRoll.txt is the same data contained in Go Fast Tilt tracking.xlsx?

In the meantime, here's the positions that match the diagrams above.

GF_Jet_xyx_30kt-180dg.csv is the updated data I'm interested in.

GF_Target_xyx_30kt-180dg.csv is the unknown object?

I'm not exclusively trying to simulate the actual event. Although, corroborating the data presented here would be great.

So, I'll wait on trying out the GF_Target_xyx_30kt-180dg data. Right now, I've been trying to backtrack/subtract the object's position in Max based on the known variables.

My interest is combining the hard math posted here with presenting the data in an easily digestible way.

My MaxScript is beginner level. It's the result of me discovering the power of both MaxScript and Excel for animating.

jet_position_.ms is for every frame converted to feet since the scripts I have that calculate speed work only when Max's System Units are set to feet.

with animate on
(
	  at time 0 $jet_position.position =  [20.8,0,25000]
	  at time 1 $jet_position.position =  [41.5,0,25000]
...
	  at time 1029 $jet_position.position =  [21310.4,1111.5,25000] 
)

I've done a few attempts and it seems the raw data for every frame might be too granular.

So, I've been converting the position data into a spline with vertices created for every frame, then normalizing the spline in order to smooth it out for use it as a motion path.

I've been getting fairly consistent results in Max. Altitudes of the object are matching fine.

But, after RNG locks at frame 368 the speed of the object calculated in Max ranges from 45 MPH towards the beginning to 200-300+ MPH on the last 60-70 frames.

This is such a mind bending challenge, as a novice, I've caught myself making mistakes.

 

[jarlrmai]

The video I made in blender starts at the tracked stage, I just set keyframes for the coordinates of the jet each second and set the framerate to 30fps and then added 660 frames to match the tracked time of 22 seconds.

 

[Mick West]

My MaxScript is beginner level. It's the result of me discovering the power of both MaxScript and Excel for animating.

jet_position_.ms is for every frame converted to feet since the scripts I have that calculate speed work only when Max's System Units are set to feet.

with animate on
(
at time 0 $jet_position.position = [20.8,0,25000]
at time 1 $jet_position.position = [41.5,0,25000]
...
at time 1029 $jet_position.position = [21310.4,1111.5,25000]
)

I've done a few attempts and it seems the raw data for every frame might be too granular.

So, I've been converting the position data into a spline with vertices created for every frame, then normalizing the spline in order to smooth it out for use it as a motion path.

Jitter might be due to the low number of decimal places of previous data. The jet path seems pretty smooth to me.

I added some code to spit out maxscript for the jet and the target. This is only during the time it is tracked, from 14 to 32 seconds.

def writeMaxScript(thing,positions):
   outFilename = "GF_"+thing+"_MAX_"+str(WIND_KTS)+"kt-"+str(WIND_HDG_DEG)+"dg.txt"
   f = open(outFilename,"w+")
   f.write("/*\nTrack of GO FAST %s in feet for %d Knots at %d\n%s\n*/\n\n" %(thing, WIND_KTS,WIND_HDG_DEG, infoString));
   f.write("with animate on\n{\n")
   t=0
   for p in positions[:]:
	  f.write("\t at time %d\t$%s_position.position = [%f, %f, %f]\n" % (t,thing,p[0]/FEET,p[1]/FEET,p[2]/FEET))
	  t+=1
   f.write("}\n")
   f.close()


writeMaxScript("jet",poss)
writeMaxScript("target",gs)

which writes:

/*
Track of GO FAST jet in feet for 30 Knots at 180

Turning, Detailed Data (new)
*/

with animate on
{
	 at time 0	$jet_position.position = [19.072251, -0.002185, 25000.000000]
	 at time 1	$jet_position.position = [38.144503, -0.005828, 25000.000000]
	 at time 2	$jet_position.position = [57.216754, -0.010929, 25000.000000]
	...
}

Note higher precision numbers.

output attached.

 

[jarlrmai]

You need to interpolate or 'lerp' as it is known for smooth transition between your cartesians.

 

[Mick West]

You need to interpolate or 'lerp' as it is known for smooth transition between your cartesians.

Who does?

The data above is per frame, so you can't usefully interpolate more. It could be smooth though, with a moving average or somesuch. However I suspect the higher definition numbers will be smooth.

 

[Getoffthisplanet]

Jitter might be due to the low number of decimal places...Note higher precision numbers.

Nailed it:

I added some code to spit out maxscript for the jet and the target. This is only during the time it is tracked, from 14 to 32 seconds.

Good grief. You're a beast.

Thank you for taking the time to whip up the MAXScript. Though, I couldn't get it to run until I replaced the brackets with parentheses.

Just to double check, is that 14 seconds to 32 seconds or 12 to 34?

Also, can you post the position data for all 1030 frames?

 

[Mick West]

Thank you for taking the time to whip up the MAXScript. Though, I couldn't get it to run until I replaced the brackets with parentheses.

Oops. My eyes are getting old.

Just to double check, is that 14 seconds to 32 seconds or 12 to 34?

14 to 32, in the code it looks like:

dt = .0333333333 # time step
t = arange(14, 32, dt) # numpy. returns 1d array from 14 to 32-dt in steps of dt (0.1)
N = len(t)  # nubmer of timesteps in our recreation

Also, can you post the position data for all 1030 frames?

Not easily, the code (which is mostly @JUSTIN SHAW's) is focussed on the tracking portion, it would need a bit of restructuring to model the plane outside of that, and even more to get that synced with a moving object.

 

[Getoffthisplanet]

Oops. My eyes are getting old.

Oh yeah, I hear ya.

14 to 32

Ok, but I thought the thing starts getting tracked at 12 seconds when "4.4 RNG" pops up on-screen then continues on to 34 seconds when the video ends?

Not easily, the code (which is mostly @JUSTIN SHAW's) is focussed on the tracking portion, it would need a bit of restructuring to model the plane outside of that, and even more to get that synced with a moving object.

I mean just the position data for the hornet, not the thing.

@JUSTIN SHAW posted it before so I assumed it was easily updatable, I have no idea.

 

[igoddard]

I think that's a bit misleading as the limits of your axes are not square, so it greatly exaggerates the up/down and left/right motion. If you view it in a 0.2 nm cube it's
View attachment 32340

A more of less straight line within the rather low resolution we have for angles. Then an odd kink at the end.

As well its path appears to be a straight line when the footage is stabilized to the ocean:

But here's the predicted vs actual flight path of a balloon that's similar in its random meandering to the path Justin modeled:

From the blog of a high-altitude balloon business.

https://bovineaerospace.wordpress.com/2015/11/02/predicting-the-flight-path-of-a-solar-balloon/

 

[Mick West]

Ok, but I thought the thing starts getting tracked at 12 seconds when "4.4 RNG" pops up on-screen then continues on to 34 seconds when the video ends?

I trimmed the ends so the data only included where the ATFLIR numbers (angles and range) changed, otherwise it's at a value for an unknown length of time. You could probably extrapolate a bit though. So I start just after the first elevation (dip angle) changes at 13s19f, and end just before the last el change at 32s7f. This was to keep the track the object from kinking at the ends.

I mean just the position data for the hornet, not the thing.

@JUSTIN SHAW posted it before so I assumed it was easily updatable, I have no idea.

The positions are relative to where the jet starts (0,0) so starting earlier will yield different numbers relative to where the object is. But see attached.

 

[Mick West]

But here's the predicted vs actual flight path of a balloon that's similar in its random meandering to the path Justin modeled:

Justin's graph great exaggerated the amount of meandering. It could well be a straight line within the bound of measurement error.

And your balloon path is probably over a much larger time.