New Boeing 787-8 GIT

[Gijs]

The pushback is

I know, I brought it to FlightGear

but not any of the others..

Ok, that's bad. The A340-600 also had ground systems, and it would be a shame to reimplement it for each single aircraft. The pushback is in Models/Airport/Pushback, but I think Aircraft/Generic/ is a better place...

[Hooray]

Anyway, it seems I wasn't thorough enough in my scan through the console output during startup. There is a parse error. Only problem is, the line that contains the error consists of only a closing curly brace. I'm looking at it, and I can't' seem to find what's wrong. I'll post the little chunk in question below.

Unfortunately, the Nasal parser is not particularly clever or informative in such cases currently.

Especially not when dealing with nested hashes and complex expressions.

I've often seen the parse error being somewhere else, sometimes there's even a fixed offset to the line number reported, too.

That's usually a sign that the parser got "confused" at some point. So, I would look at earlier code, too.

When troubleshooting such problems, it sometimes helps to make the code less complex, i.e. by NOT using the "embedded hash" syntax to declare classes and methods, but rather use the slightly more verbose version. For example consider this:

Code: Select all

var myClass = {
 method1: func {},
 method2: func {},
 method3: func {},
};


versus:

Code: Select all

var myClass = {};
 myClass.method1= func {};
 myClass.method2= func {};
 myClass.method3= func {};


While this is slightly more verbose, it makes your code more readable, and it may also help you track down problems more easily.

Also, you might want to use a text editor that supports syntax highlighting, and which highlights matching parentheses and braces automatically.

Speaking in general, whenever you have complex nested code blocks, I'd suggest to add a short comment to the closing braces, that will make things much easier too:

Code: Select all

var myClass = {
 method1: func {
  var x=0;
  if (x==1) {
   for (var i=0;i<=1000;i+=125) {
     print(i);
   } #end of for loop
  } #end of if
  else {
   return nil;
  } #end of else
 }, # end of method1

 method2: func {
  var x=0;
  if (x==1) {
   for (var i=0;i<=1000;i+=125) {
     print(i);
   } #end of for loop
  } #end of if
  else {
   return nil;
  } #end of else
 }, # end of method2

 method3: func {
  var x=0;
  if (x==1) {
   for (var i=0;i<=1000;i+=125) {
     print(i);
   } #end of for loop
  } #end of if
  else {
   return nil;
  } #end of else
 }, # end of method3
};


When looking through the code in FlightGear, you'll see that most experienced developers tend to use such comments to make things a little easier. That's actualy a common practice, not just in Nasal or FlightGear, but in most code bases with C, C++ and Java.

It may seem tedious at first to adopt this style now, but it should help you avoid such problems. You guys (omega95 and you) tend to write fairly complex code, i.e. in that you come up with huge functions and huge loops and conditional blocks. It's not necessarily easy to keep track of what's going on. So it's only natural that your code is causing some confusion occasionally and a single missing semicolon, parentheses or braces are going to be a pain the in the ass to troubleshoot.

Really, I'd suggest to always use little helper functions to split up complex functions and code blocks (like loop bodies), it will be much easier for you to develop and debug your code. Try to make it a habit that every function/method/loop body should always fit on your screen, without scrolling in your text editor - let's say, each function shouldn't be longer than say 20-40 lines (the shorter the better). Once a function gets longer than this, simply factor out some of the code into a separate routine (or method) and call it.

Honestly, some of the most readable code that you can find in the FG repository was written by people like mfranz or AndersG who regularly use functions which are just 2-3 lines (often even just a single expression). It's a joy to read and debug code written like this, because it's so easy

You will have a much better chance of tracking down problems whenever you have very small self-contained functions that just do a single thing very well. Functions are fairly cheap in Nasal, there's really no reason not to use them. And your chance of getting good feedback here are also much better once your code is well modularized so that people only ever need to understand tiny snippets of code, rather than having to go through hundreds of lines of "spaghetti code" to understand what exactly is going on there

I already talked to omega95 about this, and I started a new howto to demonstrate the concept:
http://wiki.flightgear.org/Howto:_Use_h ... s_in_Nasal

[redneck]

Thanks a lot. I managed to solve all the errors, except one thing wasn't working quite right. For some reason, the new target altitude kept getting set to zero, so that, when it came back into the loop the second time, it would encounter an error b/c you can't do ln(0). Despite that, I already completely rewrote the whole function, splitting it up into nine different functions. Unfortunately, the problem persists. I still have a couple of ideas left to try tonight before I break down and post my code, which just happens to be about 50 lines longer now that I split it up into so many different functions. I'm not sure any of my ideas will work, however. I looked at this one pair of waypoints. I took the variables and calculated the target altitude by hand, and got about 18000. And, since my direction of flight was Westbound, it rounded to 18000. However, when FG ran the Nasal function, the final result was zero. I also have the function writing all the variables to the property tree, so I can see that they are all getting to be the correct values, or at least that they are all positive values.

I'm thinking the function that does the rounding may be to blame. Normally, to solve this problem problem in Java, I'd use a built-in class, like BigDecimal or something, combined with some fancy math. However, AFAIK, Nasal doesn't have any built-in functions or hashes for rounding. My next most-preferable method would then be to use a switch statement, but Nasal doesn't have that, either. So, finally, I would end up using a very long else if chain. I had that in my very first attempt at writing this function. However, Omega told me that that was very inefficient. Even now, I'm really not sure that the efficiency of this one function is a big deal, since it will only be run a maximum of once per flight. He told me that I should have used a for loop; however, I had no idea how to use a for loop for something that I would normally use a switch statement for. So, he made one for me and sent it to me, but it had a problem. It only rounded in one direction. So, I fixed it so it would round to the nearest even- or odd-thousand, based on overall flight direction. I'm starting to think that there's something wrong with these loops. He did tell me that he has used for loops just like the one he sent me to do rounding for him many times with no problems. He never said anything about rounding to the nearest value, however. Either up or down, but never designed to round to the nearest value. My first attempt at this function was a complete failure, littered with errors, btw. So, I never really got to see for myself how inefficient the huge elsif chains were. Well, now that I have something that doesn't break the whole hash, I'm gonna try it. And, if it works, I'll be pushing it to Git. Better to have something that works inefficiently than not at all.

EDIT: I finally fixed it! I should have never listened to Omega when he suggested that special rounding loop to optimize my code. After all, "premature optimization is the root of all evil." If only I had remembered that when he insisted that my inefficient code, which just happens to generate zero noticeable lag, would be a problem. Now, I have another problem, resulting from one of his suggestions. Since VNAV only works on the active waypoint, I must fly to a waypoint that is at least a certain distance away from the airport before I can descend. In this case, assuming the ideal descent rates of -2300 fpm above 10,000 and -1800 below 10,000 brings me down way too fast, so now I need a way to calculate a smooth descent. Just how fast will the current recommended altitudes bring you down, you might ask? Well, let's say you begin descent 221 nm away from the runway, since the next waypoint is too close for a 3-degree descent profile, and a steeper descent isn't safe. In this case, you will be down to 2000 ft with a whopping 99.7 nm left to go. This is just no good. Luckily, I already have a formula in mind for determining the descent rate. It's only shortcoming is that it will NOT take TDZE into account. I intend to figure this out later, probably using one of the GPSs installed on the plane.

[tikibar]

Hello. I've been checking out the 787-8 for the last couple of days, and I have to say you guys have done an absolutely fantastic job with it. Beautiful model and it flies like a dream. My sincerest thanks for all the hard work you're putting into it.

I've noticed that the HDG knob on the MCP won't cross 0/360 - you have to use the dialog to jump across due North. I fixed it, and thought I'd share how I did it (actually, it's the same fix as skyop's CRJ-700). Hopefully it's useful.

In Models/FlightDeck/b787.flightdeck.xml, around line 2570 in the "HDG Knob Pick Animations" section, change:

Code: Select all

<animation>
                <type>pick</type>
                <object-name>HDG.knob</object-name>
                <action>
                        <button>0</button>
                        <button>3</button>
                        <repeatable type="bool">true</repeatable>
                        <binding>
                                <command>property-adjust</command>
                                <property>/autopilot/settings/heading-bug-deg</property>
                                <step>1</step>
                                <max>360</max>
                        </binding>
                </action>
                <action>
                        <button>1</button>
                        <button>4</button>
                        <repeatable type="bool">true</repeatable>
                        <binding>
                                <command>property-adjust</command>
                                <property>/autopilot/settings/heading-bug-deg</property>
                                <step>-1</step>
                                <min>0</min>
                        </binding>
                </action>
        </animation>

to something like this:

Code: Select all

<animation>
                <type>pick</type>
                <object-name>HDG.knob</object-name>
                <action>
                        <button>0</button>
                        <button>3</button>
                        <repeatable type="bool">true</repeatable>
                        <binding>
                                <command>property-adjust</command>
                                <property>/autopilot/settings/heading-bug-deg</property>
                                <wrap type="bool">true</wrap>
                                <step>1</step>
                                <min>0</min>
                                <max>360</max>
                        </binding>
                </action>
                <action>
                        <button>1</button>
                        <button>4</button>
                        <repeatable type="bool">true</repeatable>
                        <binding>
                                <command>property-adjust</command>
                                <property>/autopilot/settings/heading-bug-deg</property>
                                <wrap type="bool">true</wrap>
                                <step>-1</step>
                                <min>0</min>
                                <max>360</max>
                        </binding>
                </action>
        </animation>

If you set the range from 0-360, due North will be 0. If you set it 1-361, due North is 360.

[redneck]

Well, I wasn't able to fix the descent altitude recommendations. For some reason, I'm having a problem adding up all the distances from the "current" waypoint to the final waypoint to get the total remaining descent distance. By "current" I do NOT mean the active waypoint, since this function is only for use in preflight. Instead, I mean "current" as in the waypoint that's currently in question, as FG goes through the Nasal script. I can gently descend from the TOD to the waypoint after the TOD, but then, it gets screwed up. Anyway, it's working half-right, which is MUCH better than it was before. So, I'm gonna push what I have to Git. I'll probably go off to bed soon after.

EDIT: Pushed. Please note that I made a slight error in one of the comments. On line 5, "# Those functions make calls to all other functions down to line 134." should be "# Those functions make calls to all other functions down to line 276.". I've fixed it, but I'm gonna wait to push it, since it has no change on how the script functions, and I doubt there would be any contributors not checking this forum topic.

[Hooray]

Normally, to solve this problem problem in Java, I'd use a built-in class, like BigDecimal or something, combined with some fancy math. However, AFAIK, Nasal doesn't have any built-in functions or hashes for rounding.

Actually, that depends entirely on your requirements. It shouldn't be too difficult to come up with something in Nasal, if you can tell us what you need to do. Maybe raise this question in the Nasal sub forum, and we'll see ?

My next most-preferable method would then be to use a switch statement, but Nasal doesn't have that, either.

I am not sure if that's a problem - switch is just syntactic sugar, all of it can be recreated using Nasal control structures. Also, you could even use a Nasal hash with functions mapped to keys to emulate a switch statement, see Anders' suggestion here: viewtopic.php?f=30&t=10988&p=113816&hilit=#p113791

So, finally, I would end up using a very long else if chain. I had that in my very first attempt at writing this function. However, Omega told me that that was very inefficient. Even now, I'm really not sure that the efficiency of this one function is a big deal, since it will only be run a maximum of once per flight.

I actually agree here with you, that sounds like "premature optimization" - maybe it was just the length of the conditional block that he was referring to? I don't think, you'll be able to actually measure any performance overhead here.

[ormaaj]

When ending a replay the altitude seems to be offset a bit from zero causing the tires to burst. Any way to reset this?

[omega95]

When ending a replay the altitude seems to be offset a bit from zero causing the tires to burst. Any way to reset this?

Good point, I'll add repair options to the menu.

[omega95]

@Ormaaj,

I see you're confused about the Flight Control System (Actual and Trim), even I was before but in the 787-8, you're NOT supposed to be able to control the trims. It seems they want the FBW to do it for you. If you take a look at any picture of the 787 cockpit, you'll notice that the 787's thrust quadrant does NOT have any trim controlS (like in hte 777). But then why exactly do you need to control the elevator trims?

[ormaaj]

@Ormaaj,

I see you're confused about the Flight Control System (Actual and Trim), even I was before but in the 787-8, you're NOT supposed to be able to control the trims. It seems they want the FBW to do it for you. If you take a look at any picture of the 787 cockpit, you'll notice that the 787's thrust quadrant does NOT have any trim controlS (like in hte 777). But then why exactly do you need to control the elevator trims?

I knew I was probably confusing something. EDIT: yes, seems the trim thing is as you say. I still notice the aileron doesn't quite return to center on landing but as you say that could be an effect of the bank limit compensating at some point.

[redneck]

EDIT: I've found a way around an issue with the VNAV Calculator. It seems that, when calculating the target altitudes for descent, the VNAV Calculator seems to get confused sometimes. Let me explain with an example. We're going to do a totally unrealistically short flight from KLAX to KSLC with the following flightplan: OSHNN3 DAG J9 MLF DELTA3. We'll take off from 25R, and land on 16R using an ILS approach. If we follow the VNAV Calculator recommendations, we'll have a very nice, uneventful flight until we get near the end of our descent. For some reason, after reaching QUIPA at 15000, the VNAV Calculator gets confused, recommending a climb to 19000 until we reach RROYY. After reaching RROYY, it goes back to giving altitudes less than the previous target altitude for a descent. I'm still not exactly sure why it does this, but I managed to fix it by playing around with the route. So, I'll list the waypoints below from the TOD to the ground with their distances apart and their altitude recommendations for the route that causes problems.

BEVRR@41000
DTA@35000 - 30.0 nm
JAMMN@25000 - 45.9 nm
DRAPR@21000 - 16.1 nm
SPIEK@19000 - 10.9 nm
HEIRY@19000 - 4.8 nm
PITTT@17000 - 4.6 nm
MAGNE@15000 - 7.1 nm
QUIPA@15000 - 1.4 nm
RROYY@19000 - 27 nm
RRUFF@15000 - 6.8 nm
BNKER@7000 - 14.9 nm (We'll intercept the GS sometime shortly before reaching this waypoint)
KSLC16R@5000 - 5.3 nm (The last waypoint is always above the ground for safety. KSLC has an elevation of 4223)

Next, I'll list below the descent from the same route, but with some waypoints removed, and a completely new one added to replace a critical waypoint.

MLF@41000
BEVRR@35000 - 31.3 nm
DTA@29000 - 30.0 nm
JAMMN@19000 - 45.9 nm
DRAPR@15000 - 16.1 nm
SPIEK@13000 - 10.9 nm
BNKER/270/10@7000 - 27.7 nm
BNKER@5000 - 10 nm
KSLC16R@5000 - 5.3 nm (GS intercept somewhere before the runway)

I am thinking the distribution of waypoints over the descent may have something to do with the problem. As you can see, in the first list, some waypoints are spread apart, while others are almost on top of one another. In the second list, the waypoints are more evenly spread apart. Well, their distance apart closes as you get closer to the airport, but that's okay, since groundspeed will be decreasing as well. Still, I had to remove RROYY, as it was causing problems, and I can't seem to figure out why. In fact, I wasn't able to get it to work right with OGD, either. Perhaps it doesn't work well when your approach demands that you fly past the airport and turn around. Perhaps it also has issues with high-altitude airports, as, in the above video, I dealt with neither of those situations; whereas, in this example, both of those situations are present.

I can't see why passing the airport and turning around would cause any problems, however. The total remaining descent distance is determined by the sum of the distance to each waypoint from the waypoint in question to the final waypoint, which is the runway. So, even if my route had me circle over the airport a dozen times, it should still get the descent right.

I also can't see why the airport elevation would have any issue. The amount of altitude I have to lose depends on the destination airport's elevation. AFAIK, this value does not change. At least, logic tells me it should not. I'd be kinda worried if the ground started undulating wildly.

It is for these reasons that I must conclude that the nature of the approach and airport elevation are NOT factors in whether or not the VNAV Calculator gets confused. Yet, I am confused myself. Without RROYY, I must perform a very short approach. Furthermore, the new descent may send me into terrain! KSLC is surrounded by mountains (not as bad as LOWI, but enough that it has special SIDs and STARs for each runway, an unusual feature for airports in the US). Even with all waypoints between DTA and RROYY removed, the VNAV Calculator recommends a descent down to only 19000 to RROYY, expecting me to descend at over 3000 fpm to BNKER. This is just no good. My guess is that this occurs b/c the waypoints are then spread too far apart. For descent calculations, the VNAV Calculator uses the predicted groundspeed for the previous waypoint to help determine the target altitude for the next waypoint. Therefore, if the waypoints are spread too far apart, then the VNAV Calculator will be running its calculation with a high groundspeed, which, in flight, will decrease dramatically between the waypoints. Therefore, the waypoints must be close together. However, if they are too close, then there will not be enough distance between them to give enough time for you to descend at all. While the difference in average distance between waypoints among both lists of waypoints isn't all that different, don't forget that some waypoints in the first list are barely a mile away from one another other. So far, it seems that setting up a descent with the waypoints about 20 nm apart should work. I'll have to experiment some more. I'd really prefer a final approach of at least 15 nm, rather than just five.

Anyway, if you have any problems with this new WIP feature, just play around with your route. Try removing the waypoint that has a higher altitude than the previous waypoint in the descent. If you need it, try replacing it with a different waypoint. Just experiment! I'll keep you guys posted on my own experiments as well.

EDIT2: I've been experimenting some more. It seems that, for some reason, the main issue may NOT be the distribution of the waypoints, but the nature of the approach. I can't seem to figure out why that is, but it seems that is definitely the case. Using the same flightplan as before, I tried to make an approach that more closely follows the published procedure without confusing the VNAV Calculator. It seems that, if I get to be within a certain distance from the airport, then I cannot go outside that range without the VNAV calculator insisting that I climb, despite the fact that the total remaining descent distance it's working with is based on the route, and NOT the actual distance from the airport. Going out 16.3 nm is okay, but 22.4 nm is not. I'll list the waypoints below as I did before.

BEVRR@41000
DTA@33000 - 30.0 nm
JAMMN@23000 - 45.9 nm
DRAPR@19000 - 16.1 nm
SPIEK@17000 - 10.9 nm
HIERY@15000 - 4.8 nm
PITTT@13000 - 4.6 nm
MAGNE@11000 - 7.1 nm
QUIPA@11000 - 1.4 nm
UFEMY/270/5@7000 - 17.3 nm
UFEMY@7000 - 5.0 nm (intercept GS)
BNKER@5000 - 8.8 nm
KSLC16R@5000 - 5.3 nm

As you can see, it's very similar to the first list. RROYY and RRUFF had to be removed, as they went too far away from the airport. To increase the length of my approach, I managed to add UFEMY/270/5 (downwind) and UFEMY (base). This gives me a final approach of 14.1 nm. Next, I'll have to make sure everyone's happy (including those who want total automation) by altering the AP management in copilot.nas so that it will wait until getting closer to intercept the LOC. Currently, it does so when 25 nm out. Anyway, this route should be able to produce a safe flight.

[omega95]

Redneck's already completed the core of the VNAV Automatic Altitudes Generator and I just completed creating an interface to access it from the EFB. Note that you DON'T have to search for the destination airport in the EFB (as in redneck's video) anymore. As this is not a function of the real 787-8's FMC, it's NOT going to be in the CDU(s).

On the other hand, the EFBs (Electronic Flight Bags) are meant to be an interface to run the Airlines or other Third-Party-Software, and that's why the VNAV AutoGEN can be accessed there, along with the FGFSCopilot Logger which is another TPS.

Cheers.

[omega95]

Don't even ask me about it.



CLICK HERE TO READ MORE...

[Hooray]

for some reason, after reaching QUIPA at 15000, the VNAV Calculator gets confused, recommending a climb to 19000 until we reach RROYY. After reaching RROYY, it goes back to giving altitudes less than the previous target altitude for a descent. I'm still not exactly sure why it does this

@redneck, I would suggest to add some explicit logging statements (i.e. print) to your decision-making code, so that you can actually see what your code is doing (when and why) when it is updating the route.

That should at least give you a way to see where the error is introduced, and at what time.

You could also add some scripted heuristics to your code, checking the consistency of VNAV altitudes created - i.e. if they just "make sense" or not. You could use a simple loop to check this, and then call it after each update to do a "self check", checking the created altitude against the previous altitudes. While approaching an airport, there shouldn't be any VNAV altitudes created that are higher than the previous altitudes, so that's a simple thing to check in Nasal:

Code: Select all

var above_altitude_vector = func (curr_alt, prev_altitudes)  {
 foreach(var alt; prev_altitudes) {
  if (curr_alt > alt) return 1; # return "true", i.e. new altitude is greater than previous alt
 }
 return 0;
}

var vnav_descend_self_check = func(alt,previous) {
  if (!above_altitude_vector(curr_alt: alt, prev_altitudes:previous)) {
    print("vnav descend self-test passed: created altitude is fine");
    return;
  }
   print("vnav descend self-test FAILED: created altitude is higher than previous altitude");
}

var alts = [35000,30000,18000,12000,9500,6500,4500];

vnav_descend_self_check(3500, alts); # should be okay
vnav_descend_self_check(6500, alts); # should fail


( I didn't test the code)

In Nasal, you can use "debug.bt();" (and then pause the sim) to get a full backtrace.

[redneck]

Thanks Hooray. I'll be sure to check it out. In other news, Omega went and made some nasty changes to the AP dialog, breaking parts of the Virtual Copilot, and possibly the FGFSCopilot interaction. I was hoping to do some other things while flying, but now that won't be possible.