Airworthiness Directives; The Boeing Company Airplanes (2019) [pdf](rgl.faa.gov)
rgl.faa.gov
Airworthiness Directives; The Boeing Company Airplanes (2019) [pdf]
https://rgl.faa.gov/Regulatory_and_Guidance_Library/rgad.nsf/0/3948342a978cc27b862584dd005c1a60/$FILE/2019-25-17.pdf
20 comments
Perhaps we should start replacing the co-pilot by a software engineer.
Nawh, bring back the engineer station like on the original 747. "Hang on, let me set some breakpoints and jiggle the cables."
The discontinuity in angle (that you loop back round from the highest value to the lowest value or vice versa) can lead to interesting issues when not treated carefully.
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.
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.
One should avoid using angles in software whenever possible. Use vectors whenever possible.
In 3d I'm finding quternions to be sometimes better than vectors, but the learning curve has taken much longer.
In 3d I'm finding quternions to be sometimes better than vectors, but the learning curve has taken much longer.
Software engineers seem to have a lot of problems with trigonometry and especially spherical coordinates/rotations. One recent example is MS FS2020 which despite being a clean-sheet redesign is still unable to render correctly or fly near the poles.
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 *.
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 *.
Quaternions are "non-intuitive" for people without a math background. If you're a professional software engineer, you should have a CS degree which includes a math background. I found 4x4 matrixes trivial in a computer graphics course because they were taught with proper examples in terms as they applied to camera and transformations. We re-implemented a subset of the OpenGL pipeline. If you don't understand the math, you can't hope to possibly understand how a 3D rendering pipeline works.
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.
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.
There are definitely cases where using polar coordinates or angles (with sin/cos/tan and their inverses) is the right tool for the job. The common problem with using trigonometry in software is that angles repeat every 2pi and tangents can overflow your math system (and in fact are undefined at 1/2pi and 3/2pi).
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.
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.
Yeah, the advice shouldn't be "avoid angles", but "avoid discontinuities".
First, you have be able to spell "quaternions." :) I think you meant vectors, points, and 3x3 matrixes. 4x4 transformations have the advantages of specifying translations and scaling in 3-space where triples and 3x3 cannot.
Isn’t this old news?
https://news.ycombinator.com/item?id=21991087
https://news.ycombinator.com/item?id=21991087
Cool bug.
"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.)