Board index FlightGear Development New features

Universal FMC powered by Java

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Universal FMC powered by Java

Postby redneck » Sun May 01, 2011 5:25 am

Hey guys! I'm back after a lot of FG inactivity. Anyway, now that I've learned OOP, GUI, and inheritance, I decided I would take up the challenge of making a universal FMC. Well, I've finally done it, except there's one problem. There's a variable I need, which I can't find. The program needs to look up the distance to the last waypoint put into the route manager. I've been sitting here running FG for about 12 hours now while I've been coding this (and doing other things as well ;)), I've been all over the property tree, and I can't seem to find a working variable that fits the description of what I'm looking for.
Man! What a buzz kill! If only I had that one variable, I could test it, tweak it, and get it committed to Git, assuming I can find someone kind enough to do that for me, since I have no idea how.

Well, I guess I might as well describe it. Now, it's universal with a few exceptions. It won't work with planes that have the autopilot menu disabled. It may not work on planes with special, custom APs, like the B1900d and nearly all of Xsaint's planes. Don't even try it with a heli. Sorry. Oh, and if you just happen to have a plane with more than 6 engines, it won't work right.
It's a little basic. It assumes you have properly loaded your plane with fuel and payload, and that you are lined up on the runway when you click the Activate! button. If you're not set up for takeoff, DO NOT click it! You will die if you do. It's gonna require you to click some buttons and punch in some numbers; not too hard, right ;) So, you'll click a radio button to tell the program whether you are flying a prop or jet-propelled aircraft. Yeah, why not have an FMC for little GA planes :D Then, you'll need to choose a climb power setting (you get three choices and they are dependent on the engine type). You'll have to punch in your cruise speed in both KIAS and mach if you're using a jet. Otherwise, just KIAS will do. Then, you'll need to enter the cruise altitude in ft, NOT FL. Java doesn't like receiving strings when it's expecting numbers and bad things will happen if you do that. You will also need to enter your approach speed and the destination airport elevation. You can just find that online. Then, taxi to the runway and click Activate!

TAKEOFF MODE
Once you click the Activate! button, it will quickly check the barometric pressure and recalibrate your altimeter. Then, be ready on the rudder. I didn't even want to try to fully automate the TO sequence. You'll have to rotate manually and climb up to 200 AGL before it takes full control, at which point it will act kinda like the c172P's AP at first, getting and setting the vertical speed, and leveling the wings, so you'll want to be sure not to rotate too hard or be close to stalling when you reach 200 AGL. Then, it will reduce power slightly to your chosen climb power, and begin to vary pitch for maximum climb.

CLIMB MODE
It will maintain those settings until you reach 500 AGL, at which point it will turn to the first waypoint, which I've already made sure will not be the departure airport.
With a jet, you'll maintain 250 KIAS with pitch at the chosen climb power level (which btw, can be changed at anytime) until you reach 10,000, and then you will reduce climb rate, without beginning a descent, and accelerate to your cruise KIAS setting. It will then continue to climb at that speed until it gets close to your cruise altitude or you get close to your mach cruise speed. It will intercept and maintain speed in mach with pitch at the chosen climb power level until you get close to the cruise altitude, at which point it will switch to cruise mode.
With a prop, it will climb at a speed that should be very close to Vy by varying pitch while maintaining your chosen climb power setting. It will maintain Vy until you reach your cruise altitude at which point it will switch to cruise mode.

CRUISE MODE
The FMC will engage alt-hold mode and AT, unless it's maintaining speed in mach. The FMC comes with an auto mach throttle built-in. Throughout the flight, it will repeatedly check the distance remaining to the destination, so that it can begin descent from an appropriate distance. Once your distance to the destination reaches this magic number, it will switch to descent mode.

DESCENT MODE
The FMC reduces your speed to 250 KIAS (if you're in a jet) and performs a few calculations repeatedly to make sure your plane maintains a 3-degree descent profile from TOD right down to the GS. Hopefully, your second to last waypoint is on the ILS beam, b/c, upon reaching that waypoint, the FMC will switch to approach mode.

APPROACH MODE
The FMC checks to make sure the LOC is in range and switches the heading mode to NAV1 HOLD. It will then continue to repeatedly check your distance to the destination. Once you are 15 nm out, it will reduce your speed to the approach speed you gave it, and enter final approach mode. If you're in a prop, it won't reduce your speed until you are 4 nm out, at which point, it will probably already be on final approach mode.

FINAL APPROACH MODE
The FMC will check your speed repeatedly. If you're in a jet, it will lower flaps and gear once you are down to 200 KIAS. It will then check repeatedly if the GS is in range, and when it is, it will set the altitude mode to NAV1-GS HOLD. It will then allow the AP to track the ILS down to 200 AGL. You better be prepared to land, b/c once you reach 200 AGL the FMC will disengage the AP completely, and exit. I decided I may tackle the task of creating an autoland system later.

So, just in case you forgot now that you've read this entire lengthy post, there's a slight problem with this, which I mentioned all the way back at the top of my post. Anyway, help will be greatly appreciated, and not just by me, I imagine.
Oh, and if someone here is kind and knowledgeable enough to provide the help I need, and I do not respond for like a week, I'm probably busy studying for finals or working on some assignments for my university. But don't worry! I will eventually check back and see that help, and apply the final missing piece to my nearly functional program.

Oh, and for those curious as to how I did it, I copied the workspace for the old instructor station to a new location and renamed it. Then, started removing unnecessary stuff (at least I hope everything I removed was unnecessary stuff!), and then got coding. And, in the horrifying case that I did remove something necessary, I still have that old instructor station I can refer back to.

EDIT: Man! No replies?! That's not cool. Maybe I didn't give everyone enough time. Anyway, I got some sleep since I posted this, and woke up with an idea: check into the GPS properties. And what do you know? I find the exact property I'm looking for! I can complete the program! YAY!!!

EDIT2: The program is complete. Formal instructions have been added, so you won't have to refer to this post when you want to be sure you know what you're doing. The only thing standing in the way of distribution is the testing phase, and being that I currently don't have access to my joystick, I doubt I'll get very far for a day or two, until I have access to it again.

EDIT3: The testing phase is off to a rough start. The layout was totally screwed up. So much for my totally reliable GridBag. So, I used a GUI builder to build the layout, making a brand new program. That task has now been complete. I will test it either today or tomorrow in flight.

EDIT4: Looks like I won't be flight testing for a while. I'm getting a very unusual response from the program. As soon as I make a selection, my RAM gets maxed out, and the program goes into an unrecoverable stack overflow reporting an error in a couple of over 250,000 threads, whatever they are. Until I get that figured out, I can't even test to make sure button handlers for my JRadioButtons are working as I intend them to.

EDIT5: This is still looking bad. I altered the FMC once again. Now, you can quickly and easily set your fuel load (in percentage of capacity). This action should work for any plane with no more than 15 fuel tanks. Anyway, now for the bad news. I tried the program again after this alteration. It seemed fine at first, however, as soon as I began to fill in the form, my system began to lag horribly. Shortly after the display driver crashed, I gave up and forced shutdown with the power button. If there is anyone out there who would like to take a look at my code and offer suggestions, I would be most grateful. I just can't figure out why this single program - this NEVER happens with any other program I've made - does this! Gonna add part of a bug report I found below.

#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 32744 bytes for ChunkPool::allocate. Out of swap space?
#
# Internal Error (allocation.cpp:117), pid=227060, tid=227116
# Error: ChunkPool::allocate
#
# JRE version: 6.0_21-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0-b17 mixed mode windows-amd64 )
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

--------------- T H R E A D ---------------

Current thread (0x000000000071d000): VMThread [stack: 0x000000003b4a0000,0x000000003b5a0000] [id=227116]

Stack: [0x000000003b4a0000,0x000000003b5a0000]
VM_Operation (0x000000003f2af260): BulkRevokeBias, mode: safepoint, requested by thread 0x000000003b96e800
[stuff omitted from post /]
VM state:at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x0000000000629df0] Threads_lock - owner thread: 0x000000000071d000

Heap
PSYoungGen total 53824K, used 34108K [0x000000002a950000, 0x0000000031830000, 0x000000003a8a0000)
eden space 48000K, 58% used [0x000000002a950000,0x000000002c4f7160,0x000000002d830000)
from space 5824K, 99% used [0x000000002d830000,0x000000002ddd8018,0x000000002dde0000)
to space 8768K, 0% used [0x0000000030fa0000,0x0000000030fa0000,0x0000000031830000)
PSOldGen total 32704K, used 7782K [0x000000000aaa0000, 0x000000000ca90000, 0x000000002a950000)
object space 32704K, 23% used [0x000000000aaa0000,0x000000000b239858,0x000000000ca90000)
PSPermGen total 21248K, used 11027K [0x00000000056a0000, 0x0000000006b60000, 0x000000000aaa0000)
object space 21248K, 51% used [0x00000000056a0000,0x0000000006164db8,0x0000000006b60000)
[more stuff omitted from post /]
VM Arguments:
jvm_args: -Dfile.encoding=Cp1252
java_command: FGFSFMC
Launcher Type: SUN_STANDARD

Environment Variables:
PATH=C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;c:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program Files\Intel\DMIX;c:\Program Files\WIDCOMM\Bluetooth Software\;c:\Program Files\WIDCOMM\Bluetooth Software\syswow64;;C:\Program Files\Dell\DW WLAN Card;C:\Program Files (x86)\Windows Live\Shared
USERNAME=Dwayne
OS=Windows_NT
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 37 Stepping 5, GenuineIntel



--------------- S Y S T E M ---------------

OS: Windows 7 Build 7600

CPU:total 4 (8 cores per cpu, 2 threads per core) family 6 model 37 stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, ht

Memory: 4k page, physical 3133940k(52628k free), swap 12533864k(89072k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (17.0-b17) for windows-amd64 JRE (1.6.0_21-b07), built on Jul 17 2010 01:05:36 by "java_re" with MS VC++ 8.0 (VS2005)

time: Sun May 01 21:44:42 2011
elapsed time: 479 seconds

EDIT6: I found what was causing that problem and fixed it. Man, setting a thread to sleep inside a loop was a very stupid idea, and NO it was NOT mine. That was a portion of code that I kept the same from the instructor station. So, I commented out the code that makes the thread sleep. Now, my new problem: the dreaded NullPointerException. It happens EVERY time I try to read properties from FG, and I don't know why. I'll tinker around with the code some more and see if I can find out. Once again, if anyone wants to take a look at what I've got, simply PM me your email address and I'll send a zip of the workspace over.

EDIT7: It seems every time I solve one problem, a new one arises. So, I got rid of my NullPointerException by creating and declaring a variable of the type FGFSConnection. Great! Now, I have a NumberFormatException. No problems with loading fuel quickly and easily anymore, so this thing is actually useful to some extent now. But clicking the Activate! button throws that error. Below I have posted the problem code along with a key that tells you what each thing is. The problem is that executing this code is making FG return an empty string.

Code: Select all
   if (FGFSFMC.fgfs.getDouble("/position/altitiude-ft")<18000)

FGFSFMC=the class name of the main program.
fgfs=the FGFSConnection variable name. As you can see, I am accessing it statically through FGFSFMC.
getDouble is supposed to return a string parsed into a Double type variable by looking up the property I've told it to look up, in this case, the real altitude of the aircraft.

EDIT8: Well, I sure feel stupid for not catching that typo. I'll try again and report my results.

EDIT9: SUCCESS!!! Well... almost. I got the plane to disengage the parking brake and throttle up. Only problem is, the FMC was in some kind of weird mix of Takeoff and descent mode or climb mode or something. My point is, it makes the plane do something, but not in the way I expected. Maybe I need to nest more if statements or something.

EDIT10: Managed to fix above problem, only to once again find myself presented with a new problem. I threw in a little something special. I've slightly modified the code so that it should rotate for you. You will still have to keep the plane centered on the runway, but it will rotate for you, and the pitch it sets the plane to is dependent on whether you are flying a jet or a prop. This way, it won't force your poor little prop-driven planes into a power-on stall right over the runway whenever you use it. Anyway, this new code is not executing, and I don't know why. After finding that one typo, I'm gonna very carefully review my code. Hopefully, that's what the problem is, so that it will be an easy fix. I'll keep the updates coming as I proceed.

EDIT11: Fixed above problem, but found myself yet another new problem: The Activate! button handler was only running once, and then exiting, leaving the plane to do whatever at its own peril. I found that if I repeatedly clicked the Activate! button, the program sent commands to FG somewhat near the way I expected, so I came up with an ingenious solution: place all the code that I want to execute repeatedly inside an infinite do-while loop. Worked like a charm, until it was time to maintain a certain N1 setting. Then, it simply disengaged FG's AT, but never used its own built-in AT that I made for it. Furthermore, it decided that it was not going to vary pitch automatically either. Then, I found yet another glitch. B/c of the way I wrote the code to determine how far the plane was from the last waypoint, it got confused, and thought that the second waypoint was the last waypoint, at which point it began this very odd behavior. See, the first thing it does is set the AT to 250 KIAS to reduce your speed and begin the descent, but when it gets to be 15 nm away from the destination, it then reduces the speed setting further to the approach speed you gave it. Well, since I managed to somehow satisfy two different conditions at the same time, the FMC oscillated the speed setting between the approach speed and 250 KIAS, causing the speed to drop to about 145 KIAS, even though my approach speed was set to 133 KIAS. Now, another very strange thing happened. Well, sorta, very strange. Anyway, when my speed hit 200 KIAS, it lowered the landing gear but forgot the flaps. Furthermore it was setting my descent rate to a number that was extremely close to zero (<0.0001). Besides that, the vertical speed it had set appeared to be a positive number, as opposed to a negative number. And to top it all off, it switched the heading mode on the AP to NAV1-hold, even though there was no signal in range (according to my instruments).
I decided to take the time I spent in a somewhat controlled stall to look up different properties and rewrite my code. To my surprise, everything in /autopilot/route-manager seems to come alive once I am airborne. It just won't work if I'm sitting on the runway. So, anyway, I went and replaced the GPS wp[1] with the route manager's wp-last to identify the final waypoint. I may have to rewrite the statement it uses to determine if it's at the second to last waypoint. So, hopefully things are a little better on this next batch of tests. Once again, I'll report be sure to report my findings and breakthroughs.
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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby redneck » Tue May 03, 2011 2:15 am

UPDATE: Live broadcast of flight test in progress!
http://j-tv.me/lAO0WA
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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby redneck » Tue May 03, 2011 5:46 am

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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby redneck » Tue May 03, 2011 8:05 am

Lots of restructuring to the code done. See progress here: http://j-tv.me/kl8Trn.

EDIT: OMG!!! It's soooooOOOOooooo close to being perfected! I fixed that little issue with the FMC switching to TO mode upon touchdown. Of course, that wasn't supposed to be an issue, since the program was supposed to self-terminate as I descended through 200 AGL. But, it didn't this time. Furthermore, it did not automatically intercept the GS, in case you didn't notice. I don't know why I never mentioned it in the broadcast. I was probably too busy trying not to crash! Oh, and btw, I changed the distance from the airport at which props begin to slow down to approach speed to 15 nm, since I had realized that while 4 nm would be just perfect for the Rallye, it wouldn't work out too well for the turbo props.

EDIT2: Fixed above problem. Now, unfortunately, the two modes: NAV1-GS-HOLD and VS-HOLD want to fight each other as soon as the GS is in range. I'm not sure why this is happening. However, it is something that I do not believe needs fixing, since it has very little effect on the flight. So, at least for the first release, I'm NOT going to fix that. Furthermore, I had a major crosswind that I was not aware of due to the fact that the AP was doing the flying. I was just sitting there wondering why it did not appear to be tracking the ILS properly, flying significantly far to the right. Anyway, I said in the above broadcast that I was increasing the distance at which the jet begins to slow down to approach speed to 30 nm. Well, I changed my mind. It's now up to 60 nm. Btw, the 787-8 is nearly impossible to slow down without extending each set of flaps at their max flap extension speeds. So... yeah.... In other news, I had a slight issue with this past, undocumented test flight. Once it was time to reduce speed to approach speed it not only wanted to oscillate between 250 KIAS and 133 KIAS, but it also ceased running calculations of the proper descent rate. Sure is fun to recode the FMC on the fly though, literally :lol: I also made a few changes to the climb mode section. Now, the FMC will assume decreased climb performance for jets at altitudes greater than 30000 ft, and for props at altitudes greater than 10,000 ft. Under these conditions, the increment for changing climb rate is decreased by 80 percent. So far I still have yet to test this with props, and I would also like to test this with supersonic jets. Would be very interesting to see how this works with the Concorde. Especially since it would be beginning its descent very late, at about 150 nm from the airport, as opposed to the recommended 250 nm or whatever it is. So, if things go as planned, I will have one final undocumented test flight, followed by a live broadcast of a flight to show off how well it works now, at least on the jets. Then, I'll just have to tweak the props.

Again, would be great to get this on Git as part of the FG project. The only issue I see is, due to the infinite loop, it is impossible to close the program without a little force (clicking the X in the top-right corner of the window while the Activate! button is pushed in has no effect, but clicking the little red square in Eclipse does. This is another issue I hope to solve before I make this publicly available. Would just be a shame if all pilots using it had to open their task managers while on final approach, click End Task, and then wait for it to close, and hoping it closes on time. I did address this issue in my latest code revisions, by creating a break point to get out of the infinite do-while loop. Not sure if it works as intended yet, though. Right now, the code sits inside that loop, so I'm thinking it's not going to work. So, what I am going to do is take the statement that determines if it's time to close the program or not, and move it outside the infinite do-while loop. This way, if I am correct, it will reach that break point, and then go straight to the code that disables the AP (hopefully) and then exits the program. At this point, in consideration of making a public release I am not too concerned as to whether or not it fully disengages the AP before exiting. It would be a nice feature to have, but I wouldn't deem it necessary, as it's just as easy to quickly press Ctrl+g, Ctrl+n, Ctrl+s, and then set the throttle to idle. Well, that's it for this post edit. Onward to flight testing!!!
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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby redneck » Tue May 03, 2011 6:59 pm

I'm finally ready for the demo flight. The demo flight is basically a non-troubleshooting flight that demonstrates use of FGFSFMC. My last undocumented test flight was cut short by a poorly placed set of power lines. Ouch. Anyway, here's the link to the currently live broadcast: http://j-tv.me/k4wMVs
Enjoy!
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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby redneck » Wed May 04, 2011 5:34 am

And now to demo it's usage with props: http://www.justin.tv/redneck1180/w/1160 ... medium=url
Enjoy!
Unfortunately, it had some issues. I have fixed them. Now, instead of climbing like a jet at cruising speed, the FMC will try to guess what Vy is and maintain that speed during the climb, giving you MUCH better climb performance. You'll climb like 10 times faster, and without stalling. Before I release a new demo of this particular fix, I'd like to further enhance the FMC's functionality. I plan to make it check the route manager, and create a simple route for you do not already have a valid route plugged into the route manager. I'll define what a valid route consists of both here and in the instructions, which btw, also need some serious updating.

A valid route consists of a departure airport, a final approach fix, and an arrival airport. That is all you need to guarantee that the FMC will be able to intercept an ILS to fly to the runway, so that it can satisfy the conditions that need to be satisfied in order for the program to exit and relinquish control of the aircraft.

That's another thing. You may be wondering why I just said, "aircraft," and not simply "plane." Well, it just so happens I got this wonderful idea of making the FMC truly universal by adding support for helis. How will I do this? Simple! Even though the Bo105 has the autopilot menu disabled, I can still bring up the settings with the F11 key, alter them, and activate them, which causes the heli to do something. And EVERYTHING in FG MUST be linked to the property tree in some way.

That is how I plan to get the FMC to generate a valid route for you. This means a little more work from you however, to result in less work from you :? So, you will enter the following additional information: departure airport and runway, arrival airport, arrival runway, and the exact runway heading. I haven't yet decided if that will be in true or magnetic degrees yet, however, once I figure that out, I'll be sure to add it to the instructions.

Back to the topic I was trying to explain earlier. Yes, I have plans to build functionality into the FGFSFMC for flying helis. There's only one slight issue I see. As with planes, you will have to have a valid route, and the nav1 radio tuned to the correct ILS freq. The takeoff will probably be the most difficult portion of the flight to code. I will have to do a manual takeoff with some custom logger attached to FG (shouldn't be too hard), and then I'll generate data for analysis. From that, I should be able to generate a magic formula to determine how much tail rotor RPMs, and how much cyclic, and in what direction, are needed based on collective pitch, thus creating an autohover system, which not only stabilizes the heli longitudinally and vertically, but laterally as well: something we do not yet have in FG AFAIK. Once I have an autohover system, I will program the FMC to slowly increase collective pitch, by setting it up to do so at a specific rate. Now, if there's one thing I know about planes, it's that speed is controlled with pitch and that altitude is controlled with throttle. I find that newbies just don't get this. Well, this FMC is not going to be a newbie. It's going to apply this concept to the heli, controlling its speed with cyclic and altitude with collective. Since FG's AP does not understand this, I will have to write most of the heli AP from scratch. Now, there are a few AP settings which may function okay: heading mode (any function) and perhaps VS and glideslope hold.

Hmm. On second thought, I really don't want to try to write a heli AP from scratch. Yes, the AP that will be used by the FMC, not the FMC itself, which I have written nearly from scratch (Remember to not only thank me, but whoever started that FGFSDemo project long ago ;)). See, the only BIG issue I see with trying to use the AP with helis is that the throttle axis is inverted with helis, so any attempt to use AT, or in this case, auto collective, results in very bad things happening, at least if you activate it while in the air. Unfortunately, that will have to be written completely from scratch. Shouldn't be too hard to make an auto collective function. Then again, I tried to make a custom AT for planes, and that didn't work, b/c the properties I wanted to write to weren't writable, even though they were in /controls, which FG's AP MUST somehow be writing to.

Well, if anything, I'm going to try to make it maintain speed with pitch up to the cruising altitude, then lock into that altitude, so if I just eliminate the cruise speed from the equation, then I'll be okay. That still leaves me with one problem though: descent. It will be impossible to descend at max speed and collective pitch... unless you want to die. Again, it seems that, at least at this point, I'll have to leave the collective pitch up to the pilot. This will NOT be completely set-and-forget for helis. It will simply take a LOT of the workload off. Anyway, I hope this actually works out okay, and that the properties I'll need to write to are writable, and that I'm not sparking false hopes in anyone. Alright, well, that's it for now.
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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby redneck » Thu May 05, 2011 12:45 am

Here's a demo of the new version of the FGFSFMC I'm working on, featuring the bug fixes for props: http://j-tv.me/kWv1tH.

EDIT: Work on the heli functions is now underway. I am assuming that the properties under /controls are non-writable based on past experience. Unfortunately, this means the pilot MUST takeoff manually. But don't worry! The rest of the flight, except for the landing, WILL be fully automated. Now, as to how realistic it will be, I can't be sure. Are you going to fly the whole flight uncomfortably tilted to the right? Idk. But, IMO it's MUCH better than nothing. So, the AP menu is disabled, eh? Not a problem for me :twisted: I'll fix you heli aficionados looking for automated flight solutions real soon.

EDIT2: Heli functions are nearly complete. I just gotta figure out why the climb mode is broken. It set up the route manager, but never activated it, so I had to go do that by hand. Then, it wouldn't do anything at all with the AP settings when it was supposed to. I mean, there's stuff in there for it to grab your current heading and hold it until you are up to 500 AGL, and there's stuff to grab your current VS and adjust it until you are up to cruise altitude. Now, cruise mode works fine, descent mode is well... weird. For some reason it was setting a descent rate that was too high. I got down to 200 AGL about 10 nm out from the airport. Then, the FMC was kind enough to completely disengage the AP just before exiting. So, then I had to turn the stuff back on, since the airport was nowhere to be found, climb, and switch to glideslope hold, and boy was that scary. As soon as I switched to glideslope hold, the heli pitched up hard, and then went into a spin! I thought I was done for, until I came up with this idea of using the tail rotor pedals to counter the spin. Worked out nicely. So, I was approaching the runway on the beam, with no nav equipment btw, at about 140 KIAS, and the heli is making all kinds of funky noises and crap. Then, I got this bright idea to, upon reaching 200 AGL, slam the collective all the way down while simultaneously yanking the cyclic into my lap. If you ever want to make a heli stop FAST, that's how :lol: So, I wound up being a bit of a ways away from the runway when I executed this maneuver, which nearly put me into another spin, btw, and had to bring the collective back up and lower the nose again. How sad. I stopped too soon. So much inefficiency. Sigh. So, in the end, I found a spot I liked, and set her down.
Well, I hope to wind up fixing the issues I had. I was foolish to think this was going to be easy considering that I already had the jet and prop modes done flawlessly at this point. But for now, I am unusually very tired. Might have something to do with the fact that I haven't slept in the past three days or so. Well, I did each day for a few hours actually. I thought those few hours would make a difference, but apparently not. I just can't get my mind off this project. So, anyway, expect completion hopefully tomorrow... or later today, or whatever.

EDIT3: OMG!!! I JUST FIXED IT!!! My FMC is now OFFICIALLY UNIVERSAL!!! Live flight demo broadcast coming up!
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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby redneck » Thu May 05, 2011 6:53 am

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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby redneck » Thu May 05, 2011 8:13 am

FIRST RELEASE!!!
http://www.mediafire.com/?1121zm11b5p0v1q

EDIT: The instructions have not been updated to accommodate heli mode. Please disregard the recommendation(s) in the instructions to not try using FGFSFMC with a heli. The instructions also lack documentation on how to get the FMC to create a route for you at this point. For now, just be sure to fill in all enabled text fields before clicking the Activate! button.
Please note that I have not yet tested the FMC with turbo/multi-prop planes yet. I am currently unsure of what will happen if you try to use FGFSFMC with such an aircraft. My next goal for this project is to address this issue. I'm going to have to do a few more flight tests. Hopefully, it's just a matter of updating the instructions. See, a turboprop is basically the same as a jet, but without the nacelle, and with a lot less fan blades. A multi-prop is basically multiple props, so nearly the same performance, unless you have at least four of them, like in the Lockheed L1011H Super Constellation, which, btw, is not supported by the FGFSFMC due to the fact that it lacks a GPS, which means it cannot use the route manager, which the FMC strongly depends on.

I also just realized that I have not made the source code available... yet. The source code consists of several classes. This is b/c the original FGFSDemo, which FGFSFMC is made from required a class just to be able to establish a connection to FG. Then, some classes had to be made to generate dialogs for allowing user input to change the connection parameters. Then, there are classes for accessing properties, as well as classes for writing to properties, and executing FG commands. Then, there is an Updater class which makes the program run continuously. And on top of that are the FGFSFMC-specific classes: the main program, which brings up the JFrame, and all the button handlers, which make the program do things depending on which button is pressed. So, basically, about half the source code is available from the FG Git repository, since I did indeed build FGFSFMC on top of an existing project. The rest? Well I have to figure out how to make that available. Now, I'm already thinking of ways I can do this. You tell me how you want it, and if you don't, then I will decide, and you may or may not like my decision. So, I'm thinking I could either copy the text (code) out of each class and post it here in separate posts, or you guys can PM me your email address so I can email the JAVA files to you. Alright, I should be done editing this post now. I will be making a new post to bump the topic up once I get turbo- and multi-props figured out.

EDIT2: In the README, it says you can use any port. This is a BIG mistake. I have updated the README in anticipation of my next release. In it I have mentioned about the need to avoid using well-known ports (anything less than 1500). I'm sorry for any inconvenience I may have caused by not thinking about that when I made the README.
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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby redneck » Thu May 05, 2011 8:39 pm

Alright guys. Time for me to do what just might be my last test flight to test for true universatility. I'll be testing with the DH-91 Albatross. It has four prop engines. So, it will be a little fast, kinda like a jet, but with the quick response of props. In this test, I'll be mainly concerned with the climb performance. Will it be way too slow? Only one way to find out! http://j-tv.me/lyoc3U
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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby redneck » Fri May 06, 2011 8:03 pm

Well... that went bad. So, anyway, I think I may have fixed that problem. Now for yet another problem. I decided that I was bored with routine flight. Let's see what happens when the engines fail :twisted: So, I thought about it, and came up with this: the FMC is not aware of the aircraft systems, and therefore will not even relinquish control of the aircraft to allow the pilot to hopefully guide it to safety. Well, if you're using Windows, you could open the Task Manager and use it to forcefully terminate the program, but who wants to do that? I know I don't. So, what if a computer could be nearly as smart as a human pilot, or at least responding correctly to the situation much, much faster than any human being possibly could imagine. This FMC knows the ABCs of total engine failure now, however, it is sadly unable to apply the knowledge I gave it. Basically, it repeatedly checks to make sure that the engines are cranking. I tried the running boolean variable. Guess what. Complete fuel exhaustion plus autostart system disabled later, and the running boolean variable continues to indicate that the engines are running, despite the fact that that is impossible. So, I'm thinking I'll just post my code and explain it.

Code: Select all
while (!FGFSFMC9.heliRB.isSelected()&&!FGFSFMC9.fgfs.getBoolean("/engines/engine/cranking")&&!FGFSFMC9.fgfs.getBoolean("/engines/engine[1]/cranking")&&!FGFSFMC9.fgfs.getBoolean("/engines/engine[2]/cranking")&&!FGFSFMC9.fgfs.getBoolean("/engines/engine[3]/cranking")&&!FGFSFMC9.fgfs.getBoolean("/engines/engine[4]/cranking")&&!FGFSFMC9.fgfs.getBoolean("/engines/engine[5]/cranking"))

While the you do not have the heli radio button selected (meaning you have selected a fixed-wing aircraft), none of the 6 engines it checks are cranking, do the following:
Code: Select all
{
      if (FGFSFMC9.propRB.isSelected())
      {
         FGFSFMC9.fgfs.setDouble("/controls/engines/engine/mixture", 1);
         FGFSFMC9.fgfs.setDouble("/controls/engines/engine[1]/mixture", 1);
         FGFSFMC9.fgfs.setDouble("/controls/engines/engine[2]/mixture", 1);
         FGFSFMC9.fgfs.setDouble("/controls/engines/engine[3]/mixture", 1);
         FGFSFMC9.fgfs.setDouble("/controls/engines/engine[4]/mixture", 1);
         FGFSFMC9.fgfs.setDouble("/controls/engines/engine[5]/mixture", 1);
         FGFSFMC9.fgfs.setInt("/controls/engines/engine/magnetos", 3);
         FGFSFMC9.fgfs.setInt("/controls/engines/engine[1]/magnetos", 3);
         FGFSFMC9.fgfs.setInt("/controls/engines/engine[2]/magnetos", 3);
         FGFSFMC9.fgfs.setInt("/controls/engines/engine[3]/magnetos", 3);
         FGFSFMC9.fgfs.setInt("/controls/engines/engine[4]/magnetos", 3);
         FGFSFMC9.fgfs.setInt("/controls/engines/engine[5]/magnetos", 3);
         FGFSFMC9.fgfs.setBoolean("/controls/engines/engine/starter", true);
         FGFSFMC9.fgfs.setBoolean("/controls/engines/engine[1]/starter", true);
         FGFSFMC9.fgfs.setBoolean("/controls/engines/engine[2]/starter", true);
         FGFSFMC9.fgfs.setBoolean("/controls/engines/engine[3]/starter", true);
         FGFSFMC9.fgfs.setBoolean("/controls/engines/engine[4]/starter", true);
         FGFSFMC9.fgfs.setBoolean("/controls/engines/engine[5]/starter", true);

If the prop radio button is selected, first attempt to restart the engines by selecting each one individually, setting the mixture to full rich, setting the magnetos to "both", and engaging the starter switch for as long as the sim continues to run.
Code: Select all
if (FGFSFMC9.fgfs.getBoolean("/engines/engine/cranking")&&FGFSFMC9.fgfs.getBoolean("/engines/engine[1]/cranking")&&FGFSFMC9.fgfs.getBoolean("/engines/engine[2]/cranking")&&FGFSFMC9.fgfs.getBoolean("/engines/engine[3]/cranking")&&FGFSFMC9.fgfs.getBoolean("/engines/engine[4]/cranking")&&FGFSFMC9.fgfs.getBoolean("/engines/engine[5]/cranking"))
            ActivateButtonHandler.main(null);

If all engines are running, quit engine out procedures, and go to the main, where you will be redirected back up to the top of the program.
Code: Select all
if (FGFSFMC9.fgfs.getDouble("/velocities/airspeed-kt")>(Integer.parseInt(FGFSFMC9.approachSpeedTF.getText())+20))
            FGFSFMC9.fgfs.setDouble("/autopilot/settings/vertical-speed-fpm", ((60*(FGFSFMC9.fgfs.getDouble("/velocities/vertical-speed-fps")))+100));
         else
            FGFSFMC9.fgfs.setDouble("/autopilot/settings/vertical-speed-fpm", ((60*(FGFSFMC9.fgfs.getDouble("/velocities/vertical-speed-fps")))-500));
      }

If you reach this part of the code, it is only b/c you are flying a prop and the engine restart attempt has failed. In that case, the FMC tries to guess what the best glide speed is, and if your speed is greater than, then it increases vertical speed by 100 fpm. Otherwise, it decreases vertical speed by 500 fpm.
Code: Select all
if (FGFSFMC9.jetRB.isSelected())
      {
         if (FGFSFMC9.fgfs.getDouble("/velocities/airspeed-kt")>(Integer.parseInt(FGFSFMC9.approachSpeedTF.getText())+90))
            FGFSFMC9.fgfs.setDouble("/autopilot/settings/vertical-speed-fpm", ((60*(FGFSFMC9.fgfs.getDouble("/velocities/vertical-speed-fps")))+100));
         else
            FGFSFMC9.fgfs.setDouble("/autopilot/settings/vertical-speed-fpm", ((60*(FGFSFMC9.fgfs.getDouble("/velocities/vertical-speed-fps")))-500));
      }

This is the same thing as above, only for jets.
Code: Select all
FGFSFMC9.fgfs.set("/instrumentation/gps/scratch/type", "airport");

Go into the GPS and set the search type to airports.
Code: Select all
FGFSFMC9.fgfs.setInt("/instrumentation/gps/scratch/max-results", (int)Math.round(FGFSFMC9.fgfs.getDouble("/position/altitude-ft")/100.0));

Set the max results to display to current GPS altitude/100, rounded to the nearest int.
Code: Select all
if (FGFSFMC9.jetRB.isSelected())
         FGFSFMC9.fgfs.setDouble("/instrumentation/gps/config/min-runway-length-ft", 5000);

If you are flying a jet, eliminate all results with a max rwy length of less than 5000 ft.
Code: Select all
FGFSFMC9.fgfs.set("/instrumentation/gps/commands", "nearest");

Execute the search for nearest airports.
Code: Select all
for (int x=FGFSFMC9.fgfs.getInt("/instrumentation/gps/scratch/max-results")-1;x>=0;x--)

Start with the second to last result index, and work your way back to zero, executing the following code below.
Code: Select all
if (90-FGFSFMC9.fgfs.getDouble("/orientation/heading-deg")<FGFSFMC9.fgfs.getDouble("/instrumentation/gps/scratch/true-bearing-deg")&&FGFSFMC9.fgfs.getDouble("/instrumentation/gps/scratch/true-bearing-deg")<90+FGFSFMC9.fgfs.getDouble("/orientation/heading-deg"))

If the airport is in front of the plane, do the following things below. Unfortunately, this is where the program crashes. For some reason, FG is returning an empty string, instead of a number. If it would work, here's the rest of what it would do.
Code: Select all
double [] rwyhdgs=new double[5];
            String[] rwys={FGFSFMC9.fgfs.get("/instrumentation/gps/scratch/runways/id"), FGFSFMC9.fgfs.get("/instrumentation/gps/scratch/runways[1]/id"), FGFSFMC9.fgfs.get("/instrumentation/gps/scratch/runways[2]/id"), FGFSFMC9.fgfs.get("/instrumentation/gps/scratch/runways[3]/id"), FGFSFMC9.fgfs.get("/instrumentation/gps/scratch/runways[4]/id")};

Create parallel arrays. We'll use them to figure out which is the best runway to choose once we have selected an airport. The FMC will assume all airports have no more than 5 runways.
Code: Select all
if (FGFSFMC9.fgfs.getDouble("/instrumentation/gps/scratch/distance-nm")<=((((FGFSFMC9.fgfs.getDouble("/velocities/groundspeed-kt"))/((60.0*FGFSFMC9.fgfs.getDouble("/velocities/vertical-speed-fps"))*(1.0/6077.0)*(60.0))))*(FGFSFMC9.fgfs.getDouble("/position/altitude-ft"))*(1.0/6077.0)))

If the distance to the search result is less than or equal to the distance remaining that the plane is capable of gliding based on the current glide ratio, run the following checks:
Code: Select all
if (90-FGFSFMC9.fgfs.getInt("/instrumentation/gps/scratch/runways/heading-deg")<FGFSFMC9.fgfs.getDouble("/instrumentation/gps/scratch/true-bearing-deg")&&FGFSFMC9.fgfs.getDouble("/instrumentation/gps/scratch/true-heading-deg")<90+FGFSFMC9.fgfs.getInt("/instrumentation/gps/scratch/runways/heading-deg"))

Look at the first runway. If we can reach it with a straight-in approach, do the following:
Code: Select all
if (FGFSFMC9.fgfs.getInt("/instrumentation/gps/scratch/runways/heading-deg")<FGFSFMC9.fgfs.getDouble("/instrumentation/gps/scratch/true-bearing-deg"))
                        rwyhdgs[0]=FGFSFMC9.fgfs.getDouble("/instrumentation/gps/scratch/true-bearing-deg")-FGFSFMC9.fgfs.getInt("/instrumentation/gps/scratch/runways/heading-deg");
                     else
                        rwyhdgs[0]=FGFSFMC9.fgfs.getInt("/instrumentation/gps/scratch/runways/heading-deg")-FGFSFMC9.fgfs.getDouble("/instrumentation/gps/scratch/true-bearing-deg");

Determine the course deviation required to turn from a direct course to the airport to line up with the runway. Hopefully, the relation in the case that we fly to a final approach intercept first, before turning to the airport. Of course, that depends on how far the INT is from the airport. I'll get to that later. Initialize the double array element at index 0. We'll save this for later.
Run the same checks on up to 4 remaining runways, while initializing the rest of the double array.
Code: Select all
String validRwy="";
            double minValue=360;

Create some variables. We will use these variables to compare how much we have to turn to line up with each runway at the airport. We want to make the smallest possible turn to rwy hdg.
Code: Select all
for (int y=0;y<rwyhdgs.length;y++)
            {
               if (rwyhdgs[y]<minValue)
                  {
                     minValue=rwyhdgs[y];
                     validRwy=rwys[y];
                  }
            }

Loop through the rwyhdgs array to find the minimum value for turn angle, and then determine which runway that number corresponds to.
Code: Select all
FGFSFMC9.fgfs.set("/autopilot/route-manager/input", "@CLEAR");
            FGFSFMC9.fgfs.set("/autopilot/route-manager/departure/airport", FGFSFMC9.departureICAOTF.getText());
            FGFSFMC9.fgfs.set("/autopilot/route-manager/departure/runway", FGFSFMC9.deprwyTF.getText());

Clear the route manager, and make sure the departure airport is still correct.
Code: Select all
if (minValue<=90)
               FGFSFMC9.fgfs.set("/autopilot/route-manager/input", (FGFSFMC9.destinationICAOTF.getText()+"/"+(180-Double.parseDouble(FGFSFMC9.destrwyhdgTF.getText()))+"/"+((0.5*(((((FGFSFMC9.fgfs.getDouble("/velocities/groundspeed-kt"))/((60.0*(FGFSFMC9.fgfs.getDouble("/velocities/vertical-speed-fps")))*(1.0/6077.0)*(60.0))))*(FGFSFMC9.fgfs.getDouble("/position/altitude-ft")*(1.0/6077.0))))-FGFSFMC9.fgfs.getDouble("/instrumentation/gps/scratch/ditance-nm")))));
            else
               FGFSFMC9.fgfs.set("/autopilot/route-manager/input", (FGFSFMC9.destinationICAOTF.getText()+"/"+(180-Double.parseDouble(FGFSFMC9.destrwyhdgTF.getText()))+"/"+((0.5*(((((FGFSFMC9.fgfs.getDouble("/velocities/groundspeed-kt"))/((60.0*(FGFSFMC9.fgfs.getDouble("/velocities/vertical-speed-fps")))*(1.0/6077.0)*(60.0))))*(FGFSFMC9.fgfs.getDouble("/position/altitude-ft")*(1.0/6077.0))))-FGFSFMC9.fgfs.getDouble("/instrumentation/gps/scratch/ditance-nm")))));

Use half the remaining glide distance (glide distance - distance to the selected airport) to create a final approach intercept, and add it. By using only half the remaining glide distance, we generate a distance cushion to allow a little room for mistakes. Mistakes would be the fact that the GPS does not take into account that it may take a few seconds to turn to the airport. As a result, there is a slight chance that the airport, which appears to be in reach, may in fact not be in reach. This is why we start at the second farthest airport, and not the farthest.
Code: Select all
FGFSFMC9.fgfs.set("/autopilot/route-manager/destination/airport", FGFSFMC9.fgfs.get("/instrumentation/gps/scratch/ident"));
            FGFSFMC9.fgfs.set("/autopilot/route-manager/destination/runway", validRwy);
            FGFSFMC9.fgfs.setInt("/autopilot/route-manager/current-wp", 1);
            FGFSFMC9.fgfs.setBoolean("/autopilot/route-manager/active", true);

Set the new destination and airport into the route manager, set the current waypoint to the first waypoint (not the departure airport), and make sure the route manager is active.
Code: Select all
if (FGFSFMC9.fgfs.getDouble("/autopilot/route-manager/wp-last/dist")<=0.75*(FGFSFMC9.fgfs.getDouble("/environment/visibility-m")*(0.5399568/1000.0)))
               break;

Shortly after the airport is in sight, the break point is reached, which causes the program to exit the loop, executing a block of code that disengages the AP and exits the program. Unfortunately, it will not always disengage the AP, but since it exits the program, you are free to manually disengage it. Just be sure the AP is off once you're over the rwy.

So, I'm thinking, for now, I'll comment out this stuff until I can get some help. Hopefully, I can get some help on this, as I'm sure this would be a neat feature to have in the FGFSFMC.
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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby redneck » Sat May 07, 2011 2:30 am

Well, so much for that. I've commented out all that stuff, and in place of it, made an autolander! I guess it's about time, right? So, anyway, here it is in its final testing stages before its next release: http://j-tv.me/iseENU
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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby Gijs » Sat May 07, 2011 8:22 pm

Just wanted to say that I enjoyed following the progress and that I will test & comment it when I find the time to do so. So you know you're topic is being read ;)
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Universal FMC powered by Java

Postby redneck » Sat May 07, 2011 9:07 pm

Well, so much for final testing. Okay, this time, I think I've got just about everything right. There are still a few bugs I need to fix, but I'm just worried about the autolander at this point. If all goes well, I'll release my current WIP right after this: http://j-tv.me/ioeozQ
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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Re: Universal FMC powered by Java

Postby redneck » Sun May 08, 2011 12:16 am

Gijs wrote in Sat May 07, 2011 8:22 pm:Just wanted to say that I enjoyed following the progress and that I will test & comment it when I find the time to do so. So you know you're topic is being read ;)

Thanks a lot. I was getting a little worried and confused that there were all these views, yet no posts from anyone else.
As for current progress, as you may have noticed in the above broadcast, the FMC failed to land the planes safely. However, if you were watching, you have heard at some point in which I mentioned a new idea for the autolander. This time, it's going to work. I just know it. It's almost fool-proof. The only thing that can screw this up is FMC lag. Anyway, I've decided that I need a better way to determine if the plane is over the threshold of the runway or not. Assuming that I am at 200 AGL is very problematic, since, at that altitude, if I am on the GS, that should set me up to be about half a mile out. While that is close, it's no good. So, I just now took a plane, and spawned on a runway that has ILS/DME, rather than just ILS. I Found my distance from the station and added it into the condition that checks to see if the autolander will run at all. So now, you must not only have a crosswind component of less than 15 kts, but all have a DME in range, AND be less than 0.2 nm from it. This should have you roughly over the runway threshold at an altitude of 80 ft AGL. Hmm. I better modify the autolander once more. See, what the autolander does is, once all those conditions are satisfied, it switches to wing-leveler mode, turns off the AT after setting a target of -999 (unfortunately, doing this does nothing towards bringing the throttles to idle before the AT is switched off), and then sets the VS to make the plane go into a dive to maintain speed. Then, when it gets closer to the ground, it decreases descent rate by 90 percent. Unfortunately, due to the FMC's tendency to lag, it never gets the chance to execute that command, bringing you down hard. So, to fix that, I will skip the dive, and hope that the FMC does not stall the plane.
Oh, and I don't plan on using the SR-71 for testing the FMC with supersonic jets anymore. I can't figure out why, but sometimes the FMC will miscalculate the required descent rate, attempting to force you down about 10 nm out from the airport. Now, since I put in a very special, magic, mathematical formula for calculating the required descent rate, this should NEVER happen, except in the event that the pilot enters the wrong TDZE in the FMC. Otherwise, it should be perfect. It seems to prefer to come in way to short if I use the SR-71. Otherwise, even if it's bringing you in too low, it will NEVER fail to catch the GS. So, I'll have to look into other supersonic jets now. Maybe I just won't worry about supersonic jets... at least for now. Idk. For now, I'm thinking I'll get the autolander working nicely with all subsonic fixed-wing aircraft before I release the latest version.
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: 3617
Joined: Mon Feb 02, 2009 3:17 am
Location: Pennsylvania, USA
Version: 240

Next

Return to New features

Who is online

Users browsing this forum: No registered users and 4 guests