- 296comments
- 186comments
- 33comments
- 10comments
- 233comments
- 221comments
- 46comments
- 11comments
- 123comments
- 16comments
- 22comments
- 136comments
- 18comments
- —discuss
- 4comments
- —discuss
- 134comments
- 121comments
- 348comments
- 47comments
- 183comments
- 8comments
- 402comments
- —discuss
- 248comments
- 32comments
- 22comments
- 72comments
- —discuss
- 13comments
and this would work in real life too, if only we could all climb and descend entirely at pilot's discretion, direct enter enter and never have to worry about all of the other planes doing the exact same thing.
And never have to intercept certain waypoints when entering different classes of controlled airspace on the correct general heading to line up for a documented runway approach.
A plot of a larger sample of post-hoc known wind and other constraints over a regular service would help enormously to sell the idea.
One point at 45min faster and 25% less fuel is of course huge, but how does it map out over a year of routing?
I have this for sailboat routing: https://leebow.dev/research/how-the-race-to-hawaii-is-won. It solves the optimal route for every Transpac and Pac Cup start since 2011, using each race's own verified wind data (ERA5). Then it compares that route to what the fleet actually sailed. It shows the median hours the fleet gave up, how often the optimal route even falls inside the fleet's own spread (16% of the time), and how much that pattern holds from year to year. A second figure runs the same solve across 108 routes over 70 years, so you can see how much the optimal route itself varies, not just one good example.
One difference from the OpenAP/scikit-decide setup: my router doesn't search a fixed grid with A*. It runs a continuous isochrone search that expands a fan of headings against the live forecast each step. That's closer to how routing is actually done for this problem, and it's what both the live product and the backtest above use.
This is pretty cool! https://github.com/airbus/scikit-decide
It's nice to see the scikit brand live on.
I am not sure how this approach would integrate with the common use of navigating between known/mapped IFR navigation waypoints:
https://www.google.com/search?client=firefox-b-d&q=IFR+navig...
https://skybrary.aero/articles/waypoint
https://www.flyingmag.com/how-ifr-fixes-get-their-names/
It will never work because you have too many human processes in the loop. This HN share by the author is selling the idea of consulting to obtain nominal efficiency on a well established process to human organizations who are structurally opposed to it, subject to human regulators who are structurally opposed to it, in an industry that is famous for aversion to change. Nice try drumming up clients, but realistically you're not going to move the mountain a millimeter on this one. Quicker to wait for AI airports, AI ATC and AI airlines than selling to humans at this point. 20th century humanity just about spitballed together a working system, but making it efficient is not going to happen on our watch. We would do well to admit it.
If you said automated instead of AI that would make sense to me.
But why would you want to use AI to control planes?
It's a by-word for expert systems with management conception as well as multi-domain comprehension these days. Reasoning through failures in one sensor domain with limited data from other domains within a fixed period following strict risk protocols at 3:01AM is the sort of thing AI would excel at versus humans.
Which are these "human processes in the loop"? We are talking about changing flight schedules, and I'm pretty sure that existing flight schedules are not developed by teams of people with pen and paper, but rather by powerful ILP solvers, because of (a) the immense value in optimising every aspect of them and (b) the myriad regulatory constraints that need to be met for, e.g., flight crew scheduling.
Aviation is one of the few industries where the largest regular (non-capital) expense is something other than labour, namely fuel. Anything that reduces fuel costs even a little is of obvious interest to every airline.
There are still the issues of coordinating flight paths to avoid collisions, and regulation (including international regulation). The former seems like a technical problem amenable to increasingly accurate approximations over time. I don't know about the latter, but I doubt it's as insurmountable as you imply. International air travel has been around longer than ILP solvers, meaning that at some point flight schedules were created by people. Now they're created by ILP solvers, and the regulatory environment successfully adapted to that change.
There's a bunch of other interesting flight path optimization work going on at https://contrails.org/.
It turns out contrails contribute to 2% of global warming power and is relatively easily avoided. The cost might be a bit more fuel consumption though.
The fuel consumption feels like the bigger problem since contrails last for hours vs co2 that lasts damn near forever.
They are roughly equal problems at the moment.
If we're measuring in terms of difficulty, CO2 is a much bigger problem than contrails.
Yes, contrails appears to be mostly solvable at a small cost in time and fuel and people have started to take action on that.
For most flights today though, if you only count the CO2 produced you're understanding the climate damage by about half.
Fun fact, contrails contribute to global warming, but only at night.
During the day they have a cooling effect by reflecting/blocking some light.
The optimal is not to eliminate them entirely, but to create them only early in the day so that they dissipate by sunset.
This is highly impractical and it is evident that the author has no idea how IFR navigation and oceanic routes work. When flying on oceanic routes and even on land, you have to intercept certain waypoints and vectored into/around airspaces.
I hate to be discouraging, but maybe the author should make an attempt to understand navigation before cooking up something like this.
I have a close family member who flys airliners. He routinely laments having to burn up thousands of pounds of fuel on the ramp to adjust changes to the landing weight projections by dispatch and from over fueling. The amount of waste in a single error (and they are not that infrequent) is enough to heat my house for a year… and I live within 200 miles of the arctic circle. I mean, burning 1000 gallons of fancy diesel once in a while is a rounding error for jetliner operations, but still, it’s absurd that that is the best solution.
I just had this happen on a flight yesterday. Exactly as you describe, extra fuel put the plane over weight, so we sat there letting it burn for an hour.
Aviation is notoriously resistant to change. For both good and bad reasons. Look at how long it's taken to get leaded fuel on the way out for light aircraft operations.
It seems like there should be a solution to this though, either battery-electric or fuel-cell auxiliary thrust for ground operations and taxiing, or utilising tractors more to do the full aircraft ground movement, not just pushing back from the gate.
If you look at the "optimal" path here looks completely unrealistic/pathological. How is it optimal to zig zag like this? The grid is clearly too coarse and that's possibly not the only issue: https://tech.marksblogg.com/theme/images/flight_planning/msr...
I think it’s not a great illustration; the map looks like mercator so the shortest path would be curved and closer to the green path anyway. the red line is not “as the crow flies”. It would be more fair to show deviation from the actual (great circle) shortest path. Also agree the grid seems coarse.