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 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.