Calculating and visualizing Gimbal angles.

[markus]

I have been working off-and-on for a several months on a quantitative comparison between the angle of the glare (which I wrote a script to measure) and the direction of the target, since it is a clear prediction of the glare model that these two should be related, and in a two-axis system, identical up to a constant. In essence, it's just calculating Euler angles, complicated only by the fact that the aircraft is pitching up slightly by some unknown amount (which should change as the bank angle changes and the magnitude of the lift vector has to change to keep altitude constant).

This pitch angle is very important for getting the correct predictions, especially near the sweep-over point. I have seen some in the ufosphere argue that the gimbal object can't be glare because it rotates less than what is "mechanically required" (Lehto mentions this analysis here). The error lies in ignoring the aircraft pitch, since by pitching up it's moving the object away from the gimbal singularity, which reduces the required angle. Unfortunately it's not very easy to estimate since it depends on the aircraft loadout; even if I knew that, I have looked around for tables and charts but most information out there about F-18s and angles of attack pertains to its exceptional performance at high AoAs, which is not what we want, and the manuals only cite angles of attack for landing configurations, which is also not what we want. So we resort to flight simulators. The F-18 flight model in DCS is, I understand, fairly accurate away from the high AoA regime, but the modeled aircraft is the F-18C legacy Hornet, not the F-18E Super Hornet, which is a heavier airplane with a larger wing. MSFS does have a Super Hornet but the flight model is questionable (and I haven't had the chance to try it out anyway since it hit me with a 100 GB+ update). In the interim I'll grab the numbers from DCS which are likely wrong but are the best we got. In the default loadout it gives a pitch-up angle of around 6 or 7 degrees for 250 knots CAS at 25000 feet with a bank angle of roughly 30 degrees.

With this in hand we can do the coordinate transformations to convert the indicate azimuth and elevations into pitch and roll for the ATFLIR pod. This is what you get:

If ATFLIR were a two-axis system, the green and yellow lines should match (the green line, the glare angle, has a somewhat arbitrary zero so I chose it to make this clearer). Circa 16 seconds or so the lines begin to diverge, which I had been worried was an error in my analysis, but the fact that the glare doesn't move at 19 seconds as the airplane banks seems to be the smoking gun that the secondary mirrors are active at this point. You can see this in the graph above as the little dip in the yellow line that has no partner in the green one (note that the yellow and purple lines are on different scales). You'd expect the glare to rotate with the horizon, but it doesn't, because the main roll axis never compensates for the bank. Incidentally, the green line tracks the yellow line very well if you advance it about 1.8 seconds, which seems consistent with some sort of control law for the roll axis.

Still, the difference between the yellow and green lines seems rather large, so it might be questionable whether the secondary mirrors can really make up the difference. To see this, I'll first reconstruct the trajectory that would correspond to the observed glare angle (the pitch is still calculated from the indicated azimuth and elevation), if we had a two-axis system, and then plot it in the moving reference frame of the F-18 as it banks and turns, at a fixed distance to represent the path the object makes in the sky:

The agreement looks a lot more striking here. Not surprisingly, since the disagreement in rolls would look larger and larger as you approach the gimbal singularity, even for a fixed absolute angular disagreement. Still, is this small enough for the secondary mirrors? The patent mentions

The third gimbal axis 146 can be of small angular travel (for example, less than or equal to 5 degrees). As a result, the third gimbal axis 146 travels around the roll axis 142 and avoids the gimbal singularity.

So let's indicate what 5 degrees would look like here:

Despite the data limitations, it looks reasonable, and shows clearly that the assertion that the glare "rotates less than what is mechanically required" is incorrect.

Moral: if the point is persuasion, you can probably do worse than @Mendel's pithy point above: real objects rotate with the horizon as the airplane banks. A more detailed explanation is harder.

 

[markus]

Relaxed flight over Jacksonville on the Super Hornet, MSFS:

As mentioned before, the flight model is questionable. It shows more adverse yaw than it should (the FCS should automatically coordinate the turns), and anything below 200 knots is just Microsoft Stall Simulator (the real jet is renowned for its excellent performance at high AoA). So neither the FCS nor the effect of the LEXs appear to be implemented, which is unsurprising. It's more likely to give a reasonable result in a simple level turn though, so I'm putting the results here for the sake of completeness. The angle of attack here is around 3.5 degrees, smaller than the legacy Hornet, which is what I'd expect (it's a bigger airplane, with more drag -- we know the Super Hornet lands slower than the legacy Hornet, for instance).

So let's redo the above with 3.5 as the AoA:

 

[Mick West]

The angle of attack here is around 3.5 degrees

I'm not clear how the angle of attack related to the angle of the ATFLIR, or what you are actually doing with it here. How does an AoA of 0° affect your results, and why?

On the ground, the ATFLIR pod seems to be mounted perfectly horizontally, but AoA is the angle between wind direction (i.e. essentially horizontal in level fight) and the chord of the wings. So I think that on the ground there's still a few degrees of AoA (for takeoff)

So are you using the AoA in calculating angles for the Pod?

 

[markus]

I'm not clear how the angle of attack related to the angle of the ATFLIR, or what you are actually doing with it here. How does an AoA of 0° affect your results, and why?

On the ground, the ATFLIR pod seems to be mounted perfectly horizontally, but AoA is the angle between wind direction (i.e. essentially horizontal in level fight) and the chord of the wings. So I think that on the ground there's still a few degrees of AoA (for takeoff)

So are you using the AoA in calculating angles for the Pod?

I'm using the indicated AoA as a proxy for the aircraft pitch with respect to its velocity vector. It's a better assumption for a fighter jet than for most civilian planes since fighter jets often have symmetric airfoils and have to pitch up just to maintain level flight. Sometimes the reference line for the AoA is actually the longitudinal axis of the fuselage, but I don't know if that's the case here. These guys seem to say that it is but I don't know if it's just a shorthand/rule of thumb.

I made two takeoff videos, one in MSFS, one in DCS.

In MSFS the AoA is close to 0 during the takeoff roll. In DCS it's close to -1 degrees. Also in DCS the indicated AoA zeros out when the VV in the hud (the direction the aircraft is pointing) coincides with the velocity vector, in accord with what the pilots said in the video above. This suggests that the AoA is measured with respect to the centerline of the fuselage. In MSFS the indicated AoA when the VV and velocity vector coincide is closer to 2.5. If this happens outside of takeoff configuration it would suggest a pitch of 6 is closer to right for both aircraft.

How does an AoA of 0° affect your results, and why?

So, to be definite here, an AoA of 0 would (in the DCS model) mean a pitch of 0, so the aircraft points exactly into its velocity vector, which is to say the vector tangent to its trajectory at each point. Since the flight is level, the indicated ATFLIR angles are effectively with respect to this tangent vector, and from then obtaining pitch and roll is just a matter of coordinate conversion.

Here's what that would look like:

Another undesirable feature here is that, while in the case with positive AoA the glare rotation lags the computed roll axis, here it leads it, which would be difficult to explain without some sort of predictive control law, which is not required with either pitch = 6 or pitch=3.5.

 

[markus]

Ah, finally, found the error which had been hurting the accuracy of the reconstruction: I was applying the coordinate transformations in the order bank rotation, then pitch rotation, under the rationale that this is the correct rigid body rotation to get the aircraft in the proper "banked" position at a given angle of attack. But I forgot that to back out the pitch and roll angles for the ATFLIR main axes I have to apply the transformations in reverse, since I was starting from spherical coordinates with zero azimuth aligned with the F-18's velocity vector. With this error corrected the fit becomes excellent. Check it out:

The 5 degree radius cones looked too big in comparison with the difference here, so I changed it 2.5 degrees. Updated code is attached.

 

[Mick West]

With this error corrected the fit becomes excellent.

Well, that's a pretty awesome fit, if accurate.

I've been using my idea of making a gimbal explainer video as an excuse to figure out how to do 3d animations with three.js - with this very preliminary result.



I'm probably getting overambitious, but ideally I'd like to demonstrate something like your curve, with an animated pod (like above) and an illustration of the angles of internal mirrors.

I still don't fully understand exactly what you are doing though

 

[markus]

Well, that's a pretty awesome fit, if accurate.

Well, I did find an error with this version (rookie mistake: update all coordinates at once, not one at a time) but even with it fixed the fit is still very good. So I'll give the corrected figures and refer to them in explaining what I'm doing. I'll do several AoAs to help illustrate the difference and because we still don't know the right value (my kingdom, my kingdom for a recording of the HUD!)

AoA=6 comes from the F-18C from DCS with the aircraft in the default configuration, which is kind of heavy (80% fuel, lots of missiles and drop pods, etc) while AoA=5 is with the aircraft squeaky clean and only about 20% fuel. AoA=3.5 comes from MSFS which actually implements an F-18E (the one in the video is actually the two-seater F-18F, but all materials I was able to find indicate they perform identically). AoA=4 comes from this video with a payware Super Hornet for FSX. It's level flight at a lower altitude but I'm adding it in because why not. What looks to be the best fit here is the one from MSFS but the others aren't terrible and fit better at the end of the video, for instance. They're all clearly better than AoA=0:

I'll show the 3D plots only for AoA=3.5 and AoA=6, left and right respectively:

The perspective on these two plots is as if you were standing on the F-18's tail, watching the path made by the UAP in the sky. I'll explain in more detail in the following.

I've been using my idea of making a gimbal explainer video as an excuse to figure out how to do 3d animations with three.js - with this very preliminary result.



I'm probably getting overambitious, but ideally I'd like to demonstrate something like your curve, with an animated pod (like above) and an illustration of the angles of internal mirrors.

I still don't fully understand exactly what you are doing though

Oh, that's pretty nice!

So what you have there is pretty close to what I'm doing. If the ATFLIR were always parallel to the F-18 velocity vector, we'd be done -- that'd be how the pod must rotate to track the object. But it's stuck to the jet, which is banked and pitched to make the curve at constant altitude. To add some clarity let's define a local coordinate system with respect to the pod in your animation: I'll place the y axis along the longitudinal axis of the pod, the x axis transversally pointing to the right, and the z axis transversally pointing up. Now you rotate the ATFLIR to the left along the y axis by about 30 degrees (the bank angle), and then you rotate it up about the new x axis by about 6 degrees (our best estimate for the pitch angle during the turn). This is the position the ATFLIR roll and pitch angles are computed from.

If you made an animation of this situation now, you'd have the pod pointing a little bit up and to the left while the trajectory of the object remains steady at an elevation of -2 and making its usual azimuth arc from 54L to 7R. If you considered the bank angle over time, the ATFLIR would then move a little bit further up and left at around t=9 s, 19s, 25s, and move back at t=31s. With this guy moving it's a little cumbersome to calculate the pod pitch and roll, so what I do is to convert to a frame of reference where the ATFLIR is oriented as in your picture, nice and easy along one of the usual coordinate axes. To do this, I take the inverse of the rigid body rotations that were applied to the pod, and apply them to the UAP. So I take the nice steady path at -2 degrees elevation and pitch it down 6 degrees (in the original x axis), and then rotate it about 30 degrees to the right in this new (pitched down) y axis. The result is the blue line in the 3d picture above.

Anyway, because in this coordinate system the ATFLIR is sitting nice along one of the usual axes, once I have the cartesian coordinates describing the blue line, I can calculate what the pitch and roll for the ATFLIR gimbal should be with a simple cartesian-to-spherical coordinate conversion. This results in the blue and yellow lines in the 2d graph.

For a two-axis system this is all there is, we're done. Since we're in the pilot's frame of reference we can compare the calculated roll with the angle of the glare with respect with some line (which can be picked arbitrarily, so I just found whichever one gives the best fit). If this were this a two-axis system, we'd have to either get this pretty much exactly right or we're in trouble. Since it's not, we have to find a different way to check the results. What I'm doing there is to replace the calculated roll angle with the glare angle and seeing where in the sky we end up. This results in the yellow line in the 3d graph. The Raytheon patent says the secondary mirrors have a small angle of travel around 5 degrees, so if the difference is less than 5 degrees we're ok. I drew some cones with a radius of 2.5 degrees in the 3d graph from the F-18 position to various points along the UAP trajectory to give an idea of how close the two curves are. I also calculated the largest angular distance between the reconstructed and actual position. Each of the "plausible" AoAs above was within 5 degrees at all times.

AoA (deg)	max angular distance (deg)
3.5	3.4
4.0	3.2
5.0	3.8
6.0	4.8
0.0	5.3

Sorry for the long post which no doubt contained many things you already know, but I was trying to be thorough and clear as I can and to not take anything for granted. Please let me know if anything is missing/unclear/weird/wrong. This coordinate transformation stuff is prodigiously easy to mess up so I'll definitely feel better about all of this once other people are able to understand / replicate it.

 

[Mendel]

@markus great work!
I don't understand why your Euler angle diagrams show a change in pitch exceeding 50⁰. Could you please explain that for me? It feels undxpectedly large.

 

[markus]

@markus great work!
I don't understand why your Euler angle diagrams show a change in pitch exceeding 50⁰. Could you please explain that for me? It feels undxpectedly large.

Thanks!

Ignore bank and pitch for now. Let' say the ATFLIR is oriented parallel to the aircraft velocity vector. Let's say that the elevation of the object is 0: in that case, all of the tracking would happen in the pitch axis (you still need a 180 degree rotation in the roll axis as you move across the origin). Conversely, imagine the ATFLIR is pointing straight up: now all of the tracking happens in the roll axis. In the actual video we have an elevation of 2-ish degrees and a pitch up angle of around 5 degrees, so it's much closer to the former situation than the latter.

 

[Mendel]

all of the tracking would happen in the pitch axis

Ah, I understand my confusion. Bank angle refers to both the aircraft and the pod, but pitch and roll refer to the ATFLIR head. The legend would be clearer if the labels were "ATFLIR pitch" and "ATFLIR roll". Thank you!

 

[Mick West]

So what you have there is pretty close to what I'm doing.

Just focussing on incorporating the jet bank and AOA for now.

What I'm doing so far is the simple model, ignoring those two variables. I have El (elevation relative to horizontal) at -2 and Az (Azimuth relative to the jet's forward vector in the ground plane) going from -57 to +8. Those, as you know, are the numbers on screen.

From that I calculate a pod roll angle and a pod pitch angle. This is essentially converting from one spherical coordinate system to another, and is done by converting El, AZ to cartesian, then cartesian to pod roll and pod pitch.

So to incorporate AOA, can't I just subtract AOA from El? So instead of the target being 2° below horizontal, it's now (for, say, a 4° AOA) 2+4, or 6? Is that actually equivalent?

Then to incorporate jet roll, that's kind of like "free" roll. The pod needs to roll counter clockwise to pass under the singularity. The jet is banking left, which is a CCW rotation. It increases that bank through the video up to 0°, so that reduces the amount of roll that is needed by the pod.

So can I simple subtract the jet roll from the calculate pod roll to get actual roll (roll in the frame of reference of the jet or the fixed parts of the pod)?

 

[Mick West]

Here's a simple interactive version:
https://metabunk.org/gimbal/

Works best in a browser, but will also work on a phone. You can rotate, pan, and zoom, and adjust the az and el manually

 

[Mendel]

Here's a simple interactive version:
https://metabunk.org/gimbal/

Works best in a browser, but will also work on a phone. You can rotate, pan, and zoom, and adjust the az and el manually

Looks nice!
I was trying to see if the point where the light beam enters the ATFLIR window tells me anything (like, how far off center the fine tracking is relative to the coarse movement), but that's impossible.

 

[Edward Current]

Here's a simple interactive version:
https://metabunk.org/gimbal/

Works best in a browser, but will also work on a phone. You can rotate, pan, and zoom, and adjust the az and el manually

I can't stop watching this. I wish I had some mushrooms

 

[markus]

So to incorporate AOA, can't I just subtract AOA from El? So instead of the target being 2° below horizontal, it's now (for, say, a 4° AOA) 2+4, or 6? Is that actually equivalent?

No: take for example what's probably the simplest track with constant elevation = -2, which is a circle at unit distance away from the z axis, contained entirely in the z = sin(2°) ~ 0.035 plane. If you add some pitch/AoA, that plane is no longer parallel with the new z=0 plane. It's no longer constant elevation in the new coordinate system.

Then to incorporate jet roll, that's kind of like "free" roll. The pod needs to roll counter clockwise to pass under the singularity. The jet is banking left, which is a CCW rotation. It increases that bank through the video up to 0°, so that reduces the amount of roll that is needed by the pod.

So can I simple subtract the jet roll from the calculate pod roll to get actual roll (roll in the frame of reference of the jet or the fixed parts of the pod)?

Yes, I think that's right. You just have to be careful with the order of operations: assuming you know the roll, you can subtract the angle of bank (which is what you said, I'm just confirming). I checked with my script by not doing the transformation that applies the bank angle, and then subtracting it from the calculated ATFLIR roll, and it gave the exact same answer:

Here's a simple interactive version:
https://metabunk.org/gimbal/

Works best in a browser, but will also work on a phone. You can rotate, pan, and zoom, and adjust the az and el manually

That looks awesome.

 

[Mick West]

No: take for example what's probably the simplest track with constant elevation = -2, which is a circle at unit distance away from the z axis, contained entirely in the z = sin(2°) ~ 0.035 plane. If you add some pitch/AoA, that plane is no longer parallel with the new z=0 plane. It's no longer constant elevation in the new coordinate system.

Ah right. Going to elevation -6 would give another horizontal circle, -6° all the way around. But an AOA of 4 tilts the pod coordinate system up in the global frame, so the -2° globally horizontal circle would be -6° at the front, -2° at +/-90° (the sides, like either end of the axis that AOA rotates about) and +2° at 180° (the back).

So if I were to take the white curved path in my sim and rotate it around the left/right axis down 4°, that would correctly account for AOA, I think.

Currently I have a function EA2XYZ, :

// el, Elevation is the angle above horizontal
// az, Azimuth is the angle in the horizontal plane relative to the direction of travel

function EA2XYZ(el, az, r) {
    var x = r *  cos(radians(el)) * sin(radians(az))
    var y = r * sin(radians(el))
    var z = r *  cos(radians(el)) * cos (radians(az))
    return new THREE.Vector3(x,y,-z);
}

(Where x = right, y = up, -z = forward, the three.js left-handed y-up coordinate system, unfortunately)

That's converting into the pod's coordinate system, with 0,0,0 in the middle of the ball, and a horizontal pod. So all I need is one additional rotation around the right (x) axis to incorporate the AOA tilt and bring it into the frame of reference of the tilted pod.

 

[jarlrmai]

The elevation angle displayed on the screen is always relative to the horizon right? At least that is what the manuals say?
But the pod/jet system's actual elevation angle relative to horizon again? Would be taken into account by the algorithm deciding on when to do major rotations.

 

[Mick West]

The elevation angle displayed on the screen is always relative to the horizon right? At least that is what the manuals say?

Yes

But the pod/jet system's actual elevation angle relative to horizon again?

What is the "actual elevation angle"? I don't think there is on. There's the elevation of the target relative to the horizon, and then there's the angle of attack of the jet relative to the horizon.

 

[Mick West]

That's converting into the pod's coordinate system, with 0,0,0 in the middle of the ball, and a horizontal pod. So all I need is one additional rotation around the right (x) axis to incorporate the AOA tilt and bring it into the frame of reference of the tilted pod.

I've added this to the sim, with an aoa variable.
https://metabunk.org/gimbal/

Like here an AOA of 8 degrees (meaning the jet is tilted up 8, raising the singularity (the center of the dome here) up 8°- which is shown by the horizontal -2° line touching the first red 10° circle.

 

[Mick West]

Changed the AOA to rotate the frame of reference for display, so the -2° track stays horizontal.
https://metabunk.org/gimbal/

 

[jarlrmai]

It might be worth talking about why the track doesn't just continue left to right, ie why the rotation occurs.

 

[Mick West]

It might be worth talking about why the track doesn't just continue left to right, ie why the rotation occurs.

Well, in this simple model (with no internal gimbals), you can see that if you pause it and manually adjust the pod (ball) pitch.

Without rotating, you can't track something that's a constant -2° below the horizon.

Now with internal gimbals allowing you to stray from the ideal path, you could in theory go to the other side without rotating, however I think the algorithm still prefers to rotated because:

A) it puts it in a better position for future moves - continuing without rotation will gradually increase the deviation needed, so it makes sense to periodically update the rotation to minimize the error
B) (uncertain) the range of motion might not be the same on both sides. The model I'm using is a Litening pod, which has physical limits on how far the ball can rotate before it's hidden by the EOSU housing - which is cut away on one side. Hence the algorithm will try to stay on the "good" side (the one with the most range of motion - especially if it looks like the target is continuing in that direction.

However I'm not sure if the ATFLIR pod has that same range of motion limitation to the ball pitch - it's not clear from the images and videos I've looked at.

 

[markus]

Nice.

One thing that might be interesting to add (I don't know if it's easy to setup with three.js) is a camera at the position and orientation of the pod head, with some sort of background as a reference. Then simply draw a stationary glare on top of it and have a check box or something to select rotated and derotated.

As for why the pod doesn't just pitch through the singularity, there's two very good reasons.

Unless the target passes exactly through the singularity, if you do this,
1. The pitch angle is discontinuous
2. The first derivative of the roll is discontinuous

Would look something like this:

I understand the pod head is fairly heavy, so this is something to be avoided. The pathology we have with the usual gimbal singularity is that the first derivative of the roll approaches infinity near the singularity, but that's much milder than a discontinuity and it happens on one axis only. There's likely some range of rotations that are nearly perfectly across the singularity for which the problems with pitching through are milder than those for rotating through, but the rotating mirror solution might provide sufficient mitigation that it's not necessary to implement the special rule. I have no idea if it's mechanically possible for ATFLIR either.

 

[Mick West]

A few changes:

• Split roll into Global Roll, Jet Roll and Pod Roll, such that Global Roll = Jet Roll + Pod Roll
• Changed angles so "Pod Roll" is more intuitively in the range -180 to 180 with negative elevation
• Added a graph that changes in real time as parameters (particularly elevation and Jet pitch) are changed with the slider

 

[Mick West]

This coordinate transformation stuff is prodigiously easy to mess up so I'll definitely feel better about all of this once other people are able to understand / replicate it.

Behold!

Here I modify the AoA from 0 to 3.4, and the pod roll (white line) magically conforms to the gimbal rotation relative to the horizon (magenta)
Graph is only every tenth frame, so it looks a bit different yours. But it's nearly dinner time here.

The online version (graph every frame) might be a bit messy, as I've not considered the layout on different sized screens, but I'll fix that eventually.
https://www.metabunk.org/gimbal/

 

[markus]

Very nice I ran my script with the smoothed azimuths, overlaid the graph on yours and the agreement looks pretty much perfect.
I have a small suggestion and a question. Suggestion: I think the more useful comparison is with the gimbal angle with respect to the screen (the column titled simply 'glare_angle' in the csv) since the 'pod roll' is the roll in the frame of the jet. Question: I noticed that a few versions back the flat cover in front of the gimbal optics was normal to the direction the pod is looking at; now the direction vector is 45 degrees "ahead" of the cover. Was this change intentional? Is this actually the direction the internal optics are pointing?

 

[Mick West]

Suggestion: I think the more useful comparison is with the gimbal angle with respect to the screen (the column titled simply 'glare_angle' in the csv) since the 'pod roll' is the roll in the frame of the jet.

Ah yes, that (eventually) makes sense. Glare angle directly maps onto pod roll because pod roll maps onto derotation. Pod roll creates an unwanted rotation of the horizon in the direction opposite to the pod roll, but no matching rotating of the glare. Derotation corrects this, makign the glare seems to rotate in the same direction as the pod, by the same amount.

Jet roll alone creates a rotation of the horizon, but no rotation of the glare. No derotation or pod roll involved.

Jet rolls will alter the amount of pod roll that is needed to track - either increase or decrease it. This can be seen by toggling "use real bank angle".

Here's the ideal 2-axis track (white), along with the glare angle (green). The red line is the jet roll (jet bank angle), and the magenta line is the angular error (x10 and -100 to make it more visible. )

Now the same thing without incorporating the bank angle. The ideal 2-axis track (white) is now a much worse match to the gimbal angle, moving over 13° before the first big correction. The associate angular error is larger

The "angular error" here is the angle between the point on the ideal track, and the point using the pod pitch from the ideal track and the pod roll being equal to the glare angle. This is shown visually as a green sphere.

That angular error is the correction that is needed to be performed by the internal gimballed mirrors. The maximum error as I have it now is about 3° (the large peak near the end). The distance between the red rings is 10°, so the above is about 2° error. I should add a 5° radius ring.

The track of the glare angle is rather noisy. I wonder if it might be worth doing a smooth one manually. The glare rotations are pretty apparent, as is the lack of rotation

 

[Mick West]

Question: I noticed that a few versions back the flat cover in front of the gimbal optics was normal to the direction the pod is looking at; now the direction vector is 45 degrees "ahead" of the cover. Was this change intentional? Is this actually the direction the internal optics are pointing?

It was intentional. The pod has two window and as far as I can tell it needs to see the same things via both of them. This means it's looking through both windows at 45°.

For ATFLIR, "looking" through the smaller window is the laser target designator.

 

[Mick West]

Added 5° error circle, and an (optional) mini-jet to show orientation.

 

[Mendel]

Added 5° error circle, and an (optional) mini-jet to show orientation.

What is the green dot showing me?

I'd like to know where the ATFLIR head is looking, aka the target of pod roll/pid pitch without the "fine tune" mirrors.

 

[Mick West]

What is the green dot showing me?

I'd like to know where the ATFLIR head is looking, aka the target of pod roll/pid pitch without the "fine tune" mirrors.

That's what it's showing you.

The "angular error" here is the angle between the point on the ideal track, and the point using the pod pitch from the ideal track and the pod roll being equal to the glare angle. This is shown visually as a green sphere.

The green dot is showing you what actually happened, based on the glare angle. The white dot is the ideal track, but is also the actual LOS track with the glare angle derived track plus up to 5° of "fine tune" mirrors (the white circle).

 

[Mick West]

However we really need a smooth glare angle track, as the noisy one is a bit misleading.

 

[markus]

However we really need a smooth glare angle track, as the noisy one is a bit misleading.

Yeah, I hear you. For the analysis I've been using the raw data as much as possible, but it does pay to show something nicer. Smoothing this guy is a bit difficult though because of the age old problem where if you discard high-frequency information you also lose edges and structure that you want. In the end I came up with something that looks much smoother and keeps the stairstep structure by first applying a median filter with a window of 28 frames and following that with a Gaussian filter with a sigma of 4 frames. Looks like this:

And this is the video with the smoothed angles superimposed:

(apologies for the video compression but I hope it illustrates the idea)

I really like the little jet by the way, it definitely helps to see the pod roll.

 

[DavidB66]

I know this has been explained before, and I think I understand the explanation (or at least I did at the time), but on viewing the simulation it still looks intuitively as if the clouds are moving in the wrong direction. People coming new to the subject are likely to have the same reaction, so it will probably save time in the long run if this point is explained quite fully when the final product is presented to the public.

 

[flarkey]

I know this has been explained before, and I think I understand the explanation (or at least I did at the time), but on viewing the simulation it still looks intuitively as if the clouds are moving in the wrong direction. People coming new to the subject are likely to have the same reaction, so it will probably save time in the long run if this point is explained quite fully when the final product is presented to the public.

Yes, it might be better if the 'wireframe ball' in Mick's simulation moved, rather than the green & white dots. Maybe?

 

[Mendel]

Yes, it might be better if the 'wireframe ball' in Mick's simulation moved, rather than the green & white dots. Maybe?

The clouds move because the observer jet turns, and there's parallax; that's not part of this gimbal sim at all. @Edward Current 's Blender sim shows the clouds well.

 

[flarkey]

The clouds move because the observer jet turns, and there's parallax; that's not part of this gimbal sim at all. @Edward Current 's Blender sim shows the clouds well.

You're right. Two different models for two different purposes. (in fact, I only realised that Mick's model was available online after posting that)

 

[Mick West]

The clouds move because the observer jet turns, and there's parallax; that's not part of this gimbal sim at all. @Edward Current 's Blender sim shows the clouds well.

The clouds move right because they are behind the object, and the observer jet is moving left. The object stays in the middle of the screen because the camera is locked onto it. With parallax the more distant objects "move" in the same direction as the observer/camera.

It's a valid confusion though. Here I'm showing it from the POV of a camera fixed to the jet. It might also be useful to have a view where the target stays fixed, perhaps even with a cloud layer demonstrating parallax motion. Endless possibilities (and programming work) ....

 

[DavidB66]

The clouds move because the observer jet turns, and there's parallax; that's not part of this gimbal sim at all

Yes, that's what I thought (vaguely recalling previous discussions). But unless it is explained when the sim is publicised, I guess at least 50% of the audience (and 99% of the UFO-nuts) will think there is something wrong with it, and Mick will spend days on Twitter explaining why there isn't!

 

[Mick West]

In the end I came up with something that looks much smoother and keeps the stairstep structure by first applying a median filter with a window of 28 frames and following that with a Gaussian filter with a sigma of 4 frames.

Added, thanks.

I've also added another thing that's quite revelatory. I made the pod roll track the glare angle. So now by default it's not locked onto the "ideal" curve (minus bank angle). The pod pitch angle still comes from there, but the pod roll now is controlled entirely by data from the video.

This is very interesting, as you can see the corrections in real time. When the pod roll is not changing and the plane is not banking, then all the pod can do is change pitch, meaning it follows the blue lines (the green dot shows where the pod is physically pointing). So it's natural path is to rise up (look at the blue lines).

To keep on target it needs a counter-clockwise rotation. For the first 22 seconds, this is largely supplied by the jet banking. The jet is making a CCW bank (ie a bank more to the left) right at the start. This makes the green dot go down, removing the need for the pod itself to roll. The green ball rises, but the jet does two more increases in left bank, and 9 and 19 seconds. All of these do not rotate the glare.

Then after 22 seconds we have four larger roll corrections, the stair step pattern that the green line makes:

Step 1 is all pod roll.
Step 2 overlaps another left bank, which helps, meaning it's a little less
Step 3 at about 28.5 seconds, overlaps a right bank, which means the pod has to rotate even more to the left (CCW) to copensate for the jet rotating the "wrong" way. That's slightly why this rotation is so much larger than the others (but mostly because it's close to the singularity - see how steep the white curve is)
Step 4 is also affected a bit by the CW rotation of the jet, but essentially it's just following the white curve in steps.

The video ends with an error of about 2.2°, almost certainly just before another roll correction which would have taken the glare around 30° past vertical (i.e. it would be upside down).

This is all fascinating confirmation of the rotating glare hypothesis, but the challenge of explaining it remains.