I think Mick was saying it is correct now? and the formula is/ was different?, Gimbal V Go Fast.
But then he added code so that it now has rotation?
I was pointing out the boat has no rudder, why i used so many question marks and used the word think, "I think mick was saying".
If I'm not getting confused (which I may), does that mean that if the additional dero is at work in GoFast, background motion angle would only change by 7° over the course of the video, versus 19° if it doesn't exist?
Qualifying my remarks with regards to background motion angle is resrictive compared to Bank Tilt for go fast. 7 ish degrees of variance for Formula, 19 ish degrees for bank tilt.
Yes, it's not quite right. GoFast has always been a bit of fiddly one.
Is that a straightline, for the tracked portion? like this?
Which looks rather boring for GoFast, and does not work for Gimbal (as there's no distance to project onto)
The formula simply fails at every step, I appreciate the effort those involved in the formula have put in, but "debating" vector operations (which I suspect is the reason why everything goes screwy), is pointless, the proof is in the pudding as they say (testing methods on an appropriate video to determine the correct method), so unless an actual example demonstrating why the formula is correct can be provided, and why the footage is NOT rotated at 1 to 1 to the bank angle, go fast there isnt the rotation required to even match the bank angle, and hence the skewed artificial horizon, I'm voting with @TheCholla , the formula is out of the equation to explain anything in gimbal.
I said the pod horizon formula, which calculates the angle of the horizon in the pod's eye view without dero, not the human horizon one which I wrote. It's from a different patent that you showed me:
That is exactly the assumption behind the pod horizon formula. We know that the imager/sensor is inside the EOSU but in the back, technically only rotating with roll, not pitch/yaw. But the mirror setup inside the pod without the dero makes it so that it's still *as if* the imager were rotating along with the front window of the pod, affected by all of the gimbal axes. Jeremy confirmed the pod does have an auto-alignment system, so it seems like this would apply.Article: some tactical airborne IR systems are forced to locate the IR and visible sensors and laser off of the gimbals using an optical relay path, such as in the Advanced Targeting FLIR (ATFLIR) system. In order to re-establish an ideal configuration, a pseudo on-gimbal IR sensor and laser configuration must be implemented, such as by using the principles of the present invention, with an active auto-alignment scheme with the use of miniature two-axes mirror technology.
An active auto-alignment mirror configuration is in effect equivalent to having the IR sensors and auxiliary components, such as the laser, mounted on the stabilized gimbal.
Yes, we all agree that bank and camera tilt is in the footage, the only two things we are correcting for
Thats why we tested both methods on the Go Fast footage, and the Metabunk formula has failed to adequately de-rotate that footage, Sitrec is wrong
I say the pod is working fine and not using these internal mirrors to look somewhere the pod isnt pointed.
Simple,
Again, instead of arguing about what method is used on gimbal, we test both methods on another vide, Go Fast, ten minutes earlier, same pod, same plane, same systems, same crew, we couldnt ask for a better litmus test.
It is, and it happened...3-4 years ago. Most everyone is silent here because multiple analyses point to a distant aircraft, with the rotation almost certainly happening at the camera.
And recently we have a much simpler explanation for de-rotation of the footage, one that is demonstrated to be correct as per the side by side testing on Go Fast and that now removes the possibility of a distant plane and it being glare.
You are making a mathematical/physical claim that if you apply your formula then it will result in the physical angle between the edge of the imager and the real horizon projected onto the imager. That is a claim you need to demonstrate mathematically, providing a physical model that it results from. If your math is wrong, and it looks like it might be, then it doesn't matter how much you like the results, it doesn't matter that you think it works for whatever video, the contribution required to derotate the image would still need to come from elsewhere, not from how much the camera is tilted due to pitch and Az.
Again, I am claiming the pod is working fine, the pod isnt using the internal mirrors that are CLAIMED as A POSSIBILITY (Not certainty) that you are relying upon.
Which is why I went an implemented feature tracking, demonstrated how it works, and also tested it on go fast, both methods, and the formula resulted in a straight line path (noting that it certainly appears Mick has confirmed it with his motion tracking path of go fast), as opposed to a curved path that is in the bank tilt method, as well as being the expected result of a plane in a bank, flying an arc.
Can you address,
The internal mirrors are there. They are certainly used to traverse the singularity. Exactly how they are programmed is unclear, but you can't say they don't exist.
Didnt say they weren't, I said there is no need for them to be in operation as per "stepped rotation".
Thats what I said.
The original video is pretty darn straight, but not entirely - which is also what Sitrec Gofast is, just the other way around. If I flip and rotate it (and beware here, these are panoramas done with different methods to different data, so the scale is off), then we get what looks like the same path - which makes me suspect I did something wrong when I patched GoFast with Gimbal code, but maybe it means something else. Fascinating.
I am doing the same, and then using the panorama, ground positions, as the base and moving the plane position to get the Az/ El to fit it, determining the actual wind direction and wind speed impacting the F-18.
As I suspected, I got the sign wrong, something that often happens as all code like this ends up mixing conventions of which way is positive rotation. and also here where rotating the camera one way rotates the scene the other way, so the camera angle is the negative of the horizon angle.
export function getIdealDeroFromFrame(frame) {
const horizonAngle = get_real_horizon_angle_for_frame(frame)
const podHorizonAngle = getPodHorizonAngleFrame(frame)
const deroNeeded = podHorizonAngle - horizonAngle
return deroNeeded
}apply(f, objectNode) {
const humanHorizon = [I]get_real_horizon_angle_for_frame[/I](f);
const camera = objectNode.camera;
camera.rotateZ([I]radians[/I](humanHorizon));
}Can you elaborate on that? the new working formula implementation is giving a straight line in the de-rotation for go fast? What do you mean by "flat"?
I am glad that is now sorted out in the software, and I can relate to the feeling of, the code flicking the rotation, and it now being resolved.
Gimbal is a low priority, fascinating though it is. I have other things to do in life.
Or because the simulation isn't exactly modelling reality. Do you have a better sim that includes clouds?
