Airworthiness Directives; The Boeing Company Airplanes (2019) [pdf]
rgl.faa.gov
rgl.faa.gov
"The FAA received reports earlier this year of three incidents of display electronic unit (DEU) software errors on Model 737 NG airplanes flying into runway PABR in Barrow, Alaska. All six display units (DUs) blanked with a selected instrument approach to a runway with a 270-degree true heading, and all six DUs stayed blank until a different runway was selected. [...] The investigation revealed that the problem occurs when this combination of software is installed and a susceptible runway with a 270-degree true heading is selected for instrument approach. Not all runways with a 270-degree true heading are susceptible; only seven runways worldwide, as identified in this AD, have latitude and longitude values that cause the blanking behavior."
(Note that this is all 6 displays on each plane, not 2 displays on each of three planes.)
The runways in question are:
* Runway 26, Pine Bluffs, Wyoming, USA (82V)
* Runway 28, Wayne County, Ohio, USA (KBJJ)
* Runway 28, Chippewa County, Michigan, USA (KCIU)
* Runway 26, Cavern City, New Mexico, USA (KCNM)
* Runway 25, Barrow, Alaska, USA (PABR)
* Runway 28, La Mina, La Guajira, Colombia (SKLM)
* Runway 29, Cheddi Jagan, Georgetown, Guyana (SYCJ)
(The numbers are magnetic bearings, whereas the problem is apparently related to true bearing.)
The reMarkable tablet’s file format contains an angle field for each point, which is the angle of movement, in radians clockwise from the positive x axis, range [0, 2π). For most tools (BallpointPen, CalligraphyPen, Marker, Pencil, MechanicalPencil), it’s the tangent from the last point, but for a few tools (Fineliner, Paintbrush, Highlighter), it’s the average of the last two line segments’ angles—not the tangent from two points ago to the current point, but the average of the last two segments’ tangents. The consequence of this is that if you’re drawing a line with one of these tools in the positive x axis direction, you’ll regularly end up with points with spurious angles, as the average of just above 0 and just below 2π is around π.
(There’s another field speed, calculated in pixels per sample, which also has this curious average-of-last-one-or-two-segments behaviour, so that I can synthesise both of these properties perfectly for all except the first point or two of every stroke, provided the stroke hasn’t been scaled or rotated. I also feel like grumbling about the fact that marker tilt is not recorded in the file, though it influences the width field in the CalligraphyPen and Pencil tools, which you might otherwise expect to be derived from some combination of pressure, tilt and speed.)
This is just a fun curiosity I observed when reverse-engineering it all (and I was really pleased that I predicted it as soon as I discovered the average-of-last-two behaviour, and that experimentation proved it to be so); I haven’t gone far enough to identify the effect of the angle property on rendering, but Fineliner and Highlighter certainly won’t use it (I suspect Paintbrush does).
My first two guesses on this Boeing issue are: some sort of mishandling of the point of angle discontinuity, or division by zero.
In 3d I'm finding quternions to be sometimes better than vectors, but the learning curve has taken much longer.
Quaternions are popular because they are usually the fastest technique but are notoriously non-intuitive. This is the best guide I have found explaining them in a practical way: https://danceswithcode.net/engineeringnotes/quaternions/quat...
I used that guide to write quaternion functions for one of my projects. It is three times faster than the (also gimbal safe) trigonometric method I used previously. The quaterion functions can be found at the top of: https://github.com/kevinloch/bsrender/blob/main/src/process-.... The rotation quaternion is constructed at the bottom of https://github.com/kevinloch/bsrender/blob/main/src/init-sta.... The vector quaternion is constructed by simply copying the Euclidian x,y,z into i,j,k while setting r=0, and the output x,y,z is copied from i,j,k after rotation.
Beware my program uses a non-standard coordinate system where +y is to the left, being derived from equatorial coordinates used in astronomy where the x->y angle (Right Ascension) increases to the East. Removing the y-axis inversion/reversion steps in the quaternion functions should make them work with conventional coordinates.
The speed advantage of quaternions depends on the use case. If the points being rotated are natively Euclidian and you are performing the same rotation on a billion points then it's a clear winner as the expensive trig functions are only done once while the actual rotation steps are all + and *.
Cartesian <--> polar coordinate transformations applied to the real world must be done carefully because of the magnified error potential at boundary conditions. Again, heavy mathematics as a foundation are necessary to avoid major harm. Honestly, I don't think anyone except Professional Engineers should be allowed to work on critical flight control software. Boeing has been farming out software development to overseas contractors because they're cheaper ($9/hr), not because they're better.
Many formulas can be reduced to operations on dy/dx but you still have to watch of a zero denominator (when used as a slope). You're right as this is certainly common in 2D games but to some degree, it was originally for performance reasons since you don't want to perform a bunch of trig operations when trying to obtain a reasonable refresh rate.