Board index FlightGear Development Nasal

target_track.nas

Nasal is the scripting language of FlightGear.

target_track.nas

Postby redneck » Mon Jul 05, 2010 9:16 pm

Not sure if this is the right place to put this or not. I've been playing with the file, trying to make it better, and I seem to have hit a wall. No matter what goal range I set, target speed, etc. I will almost always eventually overshoot. So, I did some testing and found that it works absolutely wonderfully at low altitudes. I match the target's speed once I'm about 3 nm away, and ever so slowly inch my way towards it as it turns and stuff, but never get within 1 nm of it. I know the original idea was to make the AP maintain formation, and I think that is still possible with my settings, since it will match the target's speed once it's within 3 nm of the target.
The problem sets in when I climb to altitudes above 10,000 ft. The target speed is ALWAYS too high, no matter where I am in relation to the target. Anyway, after a recent flight, I concluded that the speeds that the script is plugging into the AP must be in KTAS. This explains why it will work perfect at low altitudes, but leave me to play with the throttle manually at higher altitudes. So, I was wondering if there is anyway to get the script to recognize speed in KIAS, and use that instead?

You may be wondering, why would I want to take the fun out of maintaining formation with someone? Well, I like making videos, and I doubt a pilot would actually hold a camcorder and aim it at another plane, while trying to fly very close to it without crashing. Sure, s/he'd mount the thing somewhere in the cockpit, but that's about it, UNLESS a passenger takes the camera, and acts as cameraman. Basically, the idea is to give all planes with good APs functionality that is similar to the mibs. No, I wouldn't be satisfied just using the mibs, even if mine worked.

So yeah.... I will be very happy to receive any suggestions on how to modify this script, then I will apply them, test them to make sure it works as planned, and then release it right here! You'll just have to copy and paste the text and overwrite your copy of target_track.nas.
Call Signs: redneck, ATCredn (unspecified freq atc)
FGFSCopilot
FGFSCopilotATCEdition
System Specs
Model: Alienware M15x, OS: Windows 7 Professional 64-bit, RAM: 3 GB, CPU: Intel i3 quad core at 2.4 GHz, GPU: Nvidea GeForce GTX 460M 1.5 GB GDDR5
redneck
 
Posts: 3630
Joined: Mon Feb 02, 2009 2:17 am
Location: Pennsylvania, USA
Version: 240

Re: target_track.nas

Postby Hooray » Tue Jul 06, 2010 4:57 pm

Have you already taken a look at the Nasal script: http://gitorious.org/fg/fgdata/blobs/ma ... target.nas ?
Do you need any specific help understanding or modifying the script?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: target_track.nas

Postby redneck » Tue Jul 06, 2010 8:08 pm

No, I don't know anything about GIT. The script has been updated since 1.9.1b? I'll see if I can figure it out.

I think I found the line that is the culprit. Now, ideally, I can just change the word "true" to "indicated", and have it work, but I have a feeling that's not going to work. I'll back up my file and try it anyway. Oh, and no it doesn't appear to have been updated since 1.9.1b.

As I expected, that made the script stop working.
Call Signs: redneck, ATCredn (unspecified freq atc)
FGFSCopilot
FGFSCopilotATCEdition
System Specs
Model: Alienware M15x, OS: Windows 7 Professional 64-bit, RAM: 3 GB, CPU: Intel i3 quad core at 2.4 GHz, GPU: Nvidea GeForce GTX 460M 1.5 GB GDDR5
redneck
 
Posts: 3630
Joined: Mon Feb 02, 2009 2:17 am
Location: Pennsylvania, USA
Version: 240

Re: target_track.nas

Postby Hooray » Tue Jul 06, 2010 10:03 pm

I am not sure if I am understanding you correctly, but if all you want to do is change a property, you can simply change its path in the source code.
For example, the velocity property is created using the following call:

Code: Select all
var speed_prop = sprintf("%s/velocities/true-airspeed-kt", target_root );


You have to watch out however, because some properties are "output" properties, because they are used to store results, while others are "input" properties that are used for doing calculations. There was recently a discussion about this. So you need to make sure that your changes make sense to FlightGear.

You can also use Nasal to convert from IAS to TAS or vice versa.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: target_track.nas

Postby redneck » Tue Jul 06, 2010 10:32 pm

Yes, that line right there. I want to change that to indicated airspeed. I tried changing the word "true" to "indicated", and I tried omitting the word "true". Both attempts gave me the same result: a broken target tracking script.
I browsed through the internal properties, and thought I had found what I was looking for (that I needed to simply get rid of the "true"). I'm wondering how this part works exactly. I suppose FG can't just look at the ASI of an MP or AI aircraft, right? It has to calculate it's speed based on the amount of time it travels from one point to another point, and it does that about 20 times a second. Well, if that's the case, then maybe I need to insert a line that converts the true airspeed it gets into KIAS, and plug that value into the AP settings. I'm not sure how to go about doing that though.
Call Signs: redneck, ATCredn (unspecified freq atc)
FGFSCopilot
FGFSCopilotATCEdition
System Specs
Model: Alienware M15x, OS: Windows 7 Professional 64-bit, RAM: 3 GB, CPU: Intel i3 quad core at 2.4 GHz, GPU: Nvidea GeForce GTX 460M 1.5 GB GDDR5
redneck
 
Posts: 3630
Joined: Mon Feb 02, 2009 2:17 am
Location: Pennsylvania, USA
Version: 240

Re: target_track.nas

Postby Hooray » Tue Jul 06, 2010 10:49 pm

Okay, I think I understand now what your problem is: You have to keep in mind that the AI traffic system does not use the PID controller based autopilot code, so it does not provide the same modes like the standard autopilots.
You can see what properties are supported by having a look into the source code: http://gitorious.org/fg/flightgear/blob ... AIBase.cxx

This means basically, that you have to convert your desired speed to the unit used and expected by the AI traffic system.
Just making up a new property will not work because the hard coded AI autopilot does not provide for different AP speed modes (IAS, TAS, CAS, GS).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: target_track.nas

Postby redneck » Wed Jul 07, 2010 2:15 am

Okay, now you have completely lost me. Or, we have both lost each other. I'm trying to make this script better fulfill its purpose: plugging in the right values into the AP to allow the pilot to engage in formation, or follow from a distance (depending on range setting), by simply engaging the AP. I'm not trying to set up an AI traffic system. It seems I may just need to learn some actual programming skills before I can even wrap my mind around this. I was hoping to accomplish this by simply changing some variables, which isn't working quite as planned. Yeah, that source code stuff will take me a while to understand. Really, I know how to guess the stuff, and read carefully, and then know what modifying a variable is going to do, then backup the file and tinker with it gently. I know nothing about setting or writing properties.
Call Signs: redneck, ATCredn (unspecified freq atc)
FGFSCopilot
FGFSCopilotATCEdition
System Specs
Model: Alienware M15x, OS: Windows 7 Professional 64-bit, RAM: 3 GB, CPU: Intel i3 quad core at 2.4 GHz, GPU: Nvidea GeForce GTX 460M 1.5 GB GDDR5
redneck
 
Posts: 3630
Joined: Mon Feb 02, 2009 2:17 am
Location: Pennsylvania, USA
Version: 240

Re: target_track.nas

Postby Thorsten » Wed Jul 07, 2010 8:05 am

Actually, the conversion of TAS to IAS isn't anything simple - you need the complete atmosphere model for that (it depends on temperature, pressure and altitude).

I don't think there is a simple function call available from Nasal which does that. So either someone makes it available from the C++ side, or you have to duplicate the environement model in Nasal.
Thorsten
 
Posts: 11322
Joined: Mon Nov 02, 2009 8:33 am

Re: target_track.nas

Postby xiii » Wed Jul 07, 2010 8:55 am

I did a bit of nasal, inspired by Vivian's work on the sources to get air density and speed of sound from altitude. It is very simplistic and it use only simplified standard atmosphere as data, but it can be the starting point for an nasal environment API. It is just a matter to move it to the Nasal dir. I'll ask Vivian and Anders on IRC if they mind if I put that in the Nasal dir. Then I'll be happy if someone more confident with physics take care of it.

You can find this bit of Nasal in GIT: $FG_ROOT/Aircraft/f-14b/Nasal/environment.nas
If the engines are Pratt and Whitney, the seats best be Martin Baker
xiii
 
Posts: 472
Joined: Tue Jan 08, 2008 10:04 pm

Re: target_track.nas

Postby Thorsten » Wed Jul 07, 2010 9:00 am

Wouldn't it be more efficient and clean to ask someone to expose the existing environment model to Nasal? A simplified model for TAS to IAS won't help redneck, because his AP is still going to fly with the complicated version, so for any non-standard conditions it won't work properly, and while I know the atmospheric physics and in principle also know how to Nasal it, I really don't want to redo existing work...
Thorsten
 
Posts: 11322
Joined: Mon Nov 02, 2009 8:33 am

Re: target_track.nas

Postby AndersG » Wed Jul 07, 2010 9:43 am

Thorsten wrote:Wouldn't it be more efficient and clean to ask someone to expose the existing environment model to Nasal? A simplified model for TAS to IAS won't help redneck, because his AP is still going to fly with the complicated version, so for any non-standard conditions it won't work properly, and while I know the atmospheric physics and in principle also know how to Nasal it, I really don't want to redo existing work...


What about using appropriate inputs to drive the controller? I assume that the "real" goal is not (only) to fly at exactly the same speed as the "target" but also at a specific distance from it? Perhaps distance and closure rate can be used to control the speed sent to the AP? Then there is no need to know the target's speed in any specific measurement system.

Otherwise, I'd be surprised if the speed of the main aircraft isn't available in both KIAS and KTAS - so one could also control the AP KIAS hold speed to fly at some desired KTAS set speed.

Yes, both options require somebody to write a simple controller, but at least controllers, whether in Nasal or using the AP system, do not require a recompilation of FG.

Further, in general (but perhaps not with Thorsten's weather system) we do not know the atmospheric properties at the location of the AI aircraft so I don't think the data needed to compute an accurate IAS is available.

Cheers,

Anders
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2449
Joined: Wed Nov 29, 2006 9:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: target_track.nas

Postby redneck » Wed Jul 07, 2010 3:02 pm

Yes, you are correct. Right now, it actually uses that concept to catch up to the aircraft, but when it's in range, attempts to match its speed by looking at just the aircraft's TAS, which is the wrong value to plug into the IAS for the AP. Let me find the part of the script that describes this function.
Code: Select all
target_speed = speed + range_error * 10.0;
        if ( target_speed < min_speed_kt ) {
            target_speed = min_speed_kt;
        }

The default used "range_error * 100", but that made the overshooting much more frequent, so I changed that. That fix, combined with changing the default range to 3 nm was enough to make it work nicely at low altitudes, even with the 787, enough that the AP could actually land safely by itself when following another landing jetliner.
Call Signs: redneck, ATCredn (unspecified freq atc)
FGFSCopilot
FGFSCopilotATCEdition
System Specs
Model: Alienware M15x, OS: Windows 7 Professional 64-bit, RAM: 3 GB, CPU: Intel i3 quad core at 2.4 GHz, GPU: Nvidea GeForce GTX 460M 1.5 GB GDDR5
redneck
 
Posts: 3630
Joined: Mon Feb 02, 2009 2:17 am
Location: Pennsylvania, USA
Version: 240


Return to Nasal

Who is online

Users browsing this forum: No registered users and 1 guest