Новости от X-Crafts

Let’s talk about the Autopilot. We’ve been working on it a lot recently and I’d like to give you a glimpse into the problems we are solving on a daily basis. The E-Jets are heavily automated, which makes it easier for the pilots and for you, but really hard for us.

Once we start getting really deep into recreating the real systems, as we are now, it becomes really hard to decide where to draw the line of “this is enough for v1.0”, or “this is enough for a flight sim”. This is a very dangerous place to be in. Every new function seems crucial, especially when viewed from the point of view of real pilots who are testing the products right now. But, for every problem we solve, three new ones pop up.

The easiest way to describe our current development is: “ICEBERGS“.

Every feature seems simple* straightforward initially (*we don’t use that word, nothing is ever simple exactly for the reasons explained in this paragraph!), but once we start working on it, situations, problems and limitations of the sim arise, that make the development much more complicated.

The vast majority of issues are hidden from us at first, and that is also one of a million reasons why it is so hard to predict releases in software development. Either we rush and release something full of bugs, or it takes forever. We need to find the sweet spot in between. I covered another one of these reasons in one of my previous Not-A-Newsletters here.

I’d like to give you a real example of one such iceberg that we recently ran into – Flight Level Change (FLCH).

FLCH is a Vertical Autopilot mode that adjusts the pitch to maintain the selected speed. On the E-Jets, FLCH is always accompanied by the “Speed on Elevator” (SPDE) Autothrottle (AT) mode.

When we examined the FLCH on the E-Jets with help of our lead pilot, we concluded that the Autothrottle automation is straightforward: the plane commands MAX currently allowed thrust on FLCH climb, and IDLE when we descend.

So we tried to define the logic for the custom FLCH system:

• For FLCH Climb: AT commands MAX currently allowed thrust.
• For FLCH Descent: AT commands IDLE thrust.

That sounds simple! Done in 30 minutes.

1. But wait… What if we are close to the current altitude? Commanding max thrust will totally overshoot the selected altitude! So if not MAX, how much should we add?
2. What if the users want to override the throttles? Should we allow them?
3. If the users move the throttles and override the AT, does the override last forever, or will the throttles start going back to max again once you stop using any manual input? And if so, how much user input should we allow?
4. How do we detect throttle input? What if the user has hardware throttles? The input is registered differently in X-Plane if it comes from hardware throttles or the keyboard.
5. What if the user’s hardware throttles are old and have a noisy potentiometer, that could cause AT disconnects due to the axis value spiking!?
6. OMG, but wait!!! Imagine this scenario: Hardware throttles are close to idle. After that, the user engages FLCH for Climb – the throttles in the sim would go to max, but the user’s physical hardware throttles would stay on idle.  Unlike the real throttles in the real plane that would actually move to the max position, we would now have a mismatch of throttle inputs! So if we allow the users to override the AT, the moment the user moves the hardware throttles and overrides the AT, the commanded thrust would immediately go to idle, because that’s where the hardware throttles were when we started moving them which would cause a sudden loss of thrust!!!
7. X-Plane doesn’t allow us to do what we just planned on doing.