McDonnell Douglas MD-11

[Octal450]

ph-cor got f***ed by the AP somehow, and crashed into the ocean. The AP did not let go of the controls.

Then after using Instant Replay, this happened:



Also his breaks and spoilers did weird things.
I'm gonna investigate.

Josh

[tikibar]

Let's keep the current AP. I looked over the coding for IT-AUTOFLIGHT, in particular the NAV mode. You are using the true heading error supplied directly from the route manager. While this works for flying direct to a waypoint, there is a pitfall when you're on the course in a heavy crosswind. The aircraft will deviate laterally from the course, and as you approach a waypoint, it turns sharply to intercept the waypoint before straightening out for the next leg. In a worst case scenario, if the aircraft is far enough off the course leg, it will not be able to turn back enough to capture it and you miss the way point. That was the system that used to be in use in all my AP systems.

The way the AP is set up now, there is a fairly sophisticated Nasal script that works out the course for the entire leg between waypoints and the AP follows that line instead of the bearing to the waypoint. This system is derived from the one in use on the 777. It allows the aircraft to follow the programmed route much more tightly, and works a lot better than the older and simpler system.

You can still fly direct to a waypoint using the method on Boeing aircraft: select the waypoint on the CDU legs list by pressing the button to the right of the WP name. Then press "EXEC." This creates a leg from your current position to the selected waypoint and then NAV mode follows that leg.

I think the FADEC is going to be great. The thrust control system I've been developing to go with this AP should be able to cope with it just fine, as long as the FADEC outputs some kind of target thrust parameter. I use a target N1 on the 757/767 and a PID controller to adjust the throttles to achieve that value. I'm also working on my own speed with pitch mode to smooth things out over larger speed changes. Not there yet.

I've got a working hydraulic system now, and I'm working on tuning the range for the FDMs. Once I get the hydraulics hooked up to the controls, I have some ideas on how to split out the slats from the flaps. It will use some of the same nasal controllers.

PS. I had an incident with the AP that put me in the water in San Francisco Bay. Not sure what happened, but I'm investigating.

[Octal450]

Rewriting my last post, it made no sense -_-


The IT-AUTOFLIGHT that is currently public has some issues. That is why I scrapped alot of code, and redesigned it into a buggy V2.10, which I also scrapped, then into V2.11, also scrapped. I redesigned alot of controllers, and V3.0.0 is coming soon, funny thing, I actually used the 777's LNAV script. Hehe.

So that issue is non-existent.

IT-AUTOFLIGHT includes a basic FADEC, which uses values tweaked in the set-files (optional) to adjust if wanted.

Current features of the FADEC:
automatic switching between THR, CLR, and IDLE modes.
Thrust Limits, such as Takeoff, Climb, Cruise, MCT. FLEX coming later. (3.1.0?)

I also fixed the FLCH system, it is not allowed to dive in a climb, or pitch up in a descent. Works pretty well.

Also, autoland and vnav are in the works. Landed an MD-11 at -124FPM, nicely at SFO earlier today.

Maybe you'll reconsider when you see V3.0.0. The beta team I have has been testing around the clock, we are getting to Beta 3. I'd like to be use this plane with my AP. (since it may go into FGDATA!!!)

For some reason, the AP is quite unstable at times. Especially the altitude capture.

Josh

Josh.

[Octal450]

@tikibar

viewtopic.php?f=46&t=29589&start=30#p290856

[tikibar]

@it0uchpods

Looks like it's coming along. But you're still using true-heading-error for NAV. For the AP that's in the MD-11 now, you say it's unstable. Could you clarify that? If you try to capture altitude at 2000 fpm, it's not going to be smooth. Going from 2000 to 0 fpm suddenly is going to spill everybody's drink and shift all the objects in the overhead bins. The pilot should be aware of that and reduce vertical speed when approaching the target altitude.

In any case, I added a few lines to stabilize the transition from AP off to AP on in VS mode. This was not stable before and is what caused my crash a couple of days ago. It's working better now.

I also finished the hydraulic system. I connected the Auto/Manual button on the overhead panel, but the rest of the panel is not set up yet. In Auto mode, everything works automatically (naturally). All the hydraulic equipment is connected too. I also set up the slats and flaps so the first detent is slats only, then the second starts giving you flaps. So now those are separated. I didn't update the animations for the handle, though.

[Octal450]

@tikibar

Not sure if you read this:

V3.0.0 is coming soon

Beta 2 is 8 days old now, but it's stable. Only stable stuff goes on Github. Beta team still testing with me to fix bugs in Beta 3, which does have the new LNAV.

I also finished the hydraulic system. I connected the Auto/Manual button on the overhead panel, but the rest of the panel is not set up yet. In Auto mode, everything works automatically (naturally). All the hydraulic equipment is connected too. I also set up the slats and flaps so the first detent is slats only, then the second starts giving you flaps. So now those are separated. I didn't update the animations for the handle, though.

Wonderful!!!

I'll animate the flaps handle correctly. Then I'll push my new version with some fixes to aileron animations. And pedestral throttle levers are incorrect. rev animation is rotating strangely.

BTW, how did you do that with the slats? the timing is perfect now.

Josh

[tikibar]

@tikibar
BTW, how did you do that with the slats? the timing is perfect now.

I timed it with a stop watch before I reassigned the property, then set the transition time to (nearly) match. The controller is in systems.nas. It intercepts the flap commands and rewrites them to handle the slats first. If slats==0, it sets slats to 1 and exits. If slats are 1, then it proceeds to move the flaps. In the other direction, if the flaps are extended, it puts them away, and if the flaps == 0, it stows the slats. Search for FLAPS in all caps in systems.nas to check it out.

[Octal450]

OK well done!

done and pushed:

Flaps lever
aileron drooping
throttles and reverse lever fixed
flaps indication on PFD
changed QNH system on PFD to be accurate to MD-11


Note: Throttle levers should be animated with the joystick throttle. so I changed them from throttle-lever to throttle. only the animation is changed. reverse levers were animated wrong, fixed.

Josh

[Thorsten]

The controller is in systems.nas. It intercepts the flap commands and rewrites them to handle the slats first. If slats==0, it sets slats to 1 and exits. If slats are 1, then it proceeds to move the flaps.

You do realize that using a JSBSim <switch> and separate <kinematic> you can get the same logic without bringing Nasal into the fray?

[tikibar]

I realize in JSBSim a lot more things are handled through the FDM, but this one is YASim, so all the interesting stuff has to be done in Nasal. I'm reasonably good at Nasal and have a decent grasp of YASim, but I know next to nothing about JSBSim. I understand there are many advantages to JSBSim, but the time investment for me to get up to speed with it is too great for me at the moment.

[Thorsten]

You can likely do the same thing with property rules which are FG-native technology and work under JSBSim or YaSim.

From my own experience, I try to code all low-level stuff into the FDM (otherwise you will get framerate-dependent flight dynamics which you absolutely do not want) and even as much of the high-level stuff as far as feasible.

The thing is, FDM-side encoded systems give you a very clean state in that it is only defined through property values. Which means you can save/resume/init at the expense of writing/reading properties and there won't ever be transient dynamics. Whereas state encoded in Nasal variables significantly complicate the issue - you need to make sure the right loops are running, taken down,...

You might have to invest some time to learn how to use these bits of technology, but if you have to tune AP/FDM/..., the ability to initialize the plane in any state you want (think how long it takes to get to a near-stall at 36.000 ft if you have to fly there) is invaluable once you have it and will save you tons of time.

[Octal450]

Whatever tikibar did, it flies really well now. Great job.

The AP(?) has thrown me into the ground now 10/16 flights. Frustrating. I can't locate the issue.

Could be something else? Hydraulics? I got FLCH working well. Now just need to implement the thrust system sometime when I finish all the other stuff I'm doing...lol?

Josh

[tikibar]

Thanks, Josh! I pushed a few minor fixes: a couple of items in the fuel system; N1 for engine 2 was showing the value from engine 1 on the EAD; the altimeter setting was stuck at 0.00 in both HPa and inHg modes. Those are fixed. I also tuned the fuel consumption, albeit coarsely. The range may still fall a couple hundred miles short. But it's closer than it was.

What part of the flight are you experiencing the losses of control? And what AP modes? Does it happen when you make a change (to anything), or is it spontaneous? I got one reproducible crash mode fixed, and I'd like to try to reproduce yours to try to fix it.

[tikibar]

The hydraulic panel is now complete and pushed to the repo.

[Octal450]

@tikibar

No, its random. I cannot reproduce it.

Thanks for catching the EAD thing.

I have evened my repo to yours.

ph-cor had a few more incidents as well.

Josh