Space Shuttle Ultra 1.25 Revision B development
- Thread starter Urwumpe
- Start date
SiameseCat
Addon Developer
Should be fixed now.
Thanks. Another omission in the save/load state department is the BODY FLAP and SPEEDBRAKE mode PBIs on F2/F4. Currently they default to MAN when the better setting should be AUTO.
---------- Post added at 10:01 PM ---------- Previous post was at 03:18 PM ----------
Another thing that must be fixed is the attitude calculations for the OMS MNVR EXEC screens. Currently it is very much in error indicating very weird attitudes for straight up +X burns.
SiameseCat
Addon Developer
The OMS MNVR EXEC screens show the required inertial attitude, not LVLH. The shuttle should still manevuer to the correct (inertial) attitude.
Well, it doesn't, at least not in MM302. Just try it yourself with the STS17 de-orbit burn scenario. Very odd attitude for the de-orbit burn.
SiameseCat
Addon Developer
That's a problem with the scenario. The scenario starts with the maneuver already loaded, and the code assumes that the burn attitude will be loaded from the scenario (and the burn att isn't in the scenario). I can check in a fixed scenario. If you want, it should also be possible to change the code so the burn attitude doesn't have to be stored in the scenario file.
Thanks, that did the trick, to put the burn attitude in the scenario file.
---------- Post added 01-05-12 at 12:03 AM ---------- Previous post was 01-04-12 at 01:40 AM ----------
So has any ideas come to light regarding auto entry guidance from this document?
THE design document
Perhaps this will help you. I met Jon Harpold shortly before his death in 2004. He was the head of MOD (Mission Operations Directorate) at JSC at the time, and I did a presentation for him and his senior staff. A very quiet man, with an enormous intellect.
Anyway, if shuttle entry guidance had parents, Jon Harpold and Claude Graves were those parents.
I actually have some hardcopy pages of handwritten notes Jon made when he was working on the guidance algorithms; a prized possession to be sure...
http://www.google.com/url?sa=t&rct=...9qD-DA&usg=AFQjCNFM-8elgdkreN63vpZWbyecEif-mQ
Perhaps this will help you. I met Jon Harpold shortly before his death in 2004. He was the head of MOD (Mission Operations Directorate) at JSC at the time, and I did a presentation for him and his senior staff. A very quiet man, with an enormous intellect.
Anyway, if shuttle entry guidance had parents, Jon Harpold and Claude Graves were those parents.
I actually have some hardcopy pages of handwritten notes Jon made when he was working on the guidance algorithms; a prized possession to be sure...
http://www.google.com/url?sa=t&rct=...9qD-DA&usg=AFQjCNFM-8elgdkreN63vpZWbyecEif-mQ
SiameseCat
Addon Developer
I haven't had the time to look at the code Poscik checked in yet (I've been working on rendezvous burn targeting), but I think we're already fairly close to a working entry autopilot. I'm not sure how close the entry profile is to the real shuttle, though.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Yeah, but then, the problem is actually not the guidance algorithm itself, most components of it are pretty much standard technology today, but how to implement them in SSU, the pure software engineering part.
That would need some planning, since we essentially have two development paths now. My OI-1 branch that I started isn't yet done far enough to replace all we have by my reverse engineering of the AP-101 and its machine language. But I have already a pretty good understanding of how the Shuttle software engineers structured the software and how they would likely have implemented it - the GNC software is still not public, but early FCOS and SM software is on NTRS in the form of perfectly designed flow charts, reference lists (including HAL/S macros) and data description tables.
But that the C++ entry guidance code is Posciks field of responsibility, he would need to have the final word there. I can only offer my assistance on the high-level stuff, I could for example provide blueprints for the whole GNC 3 application.
The real joy will start when we try to merge the branch back into the trunk... but that is MY responsibility then, after all I decided to have a AP-101 emulation because NASSP also has the AGC.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
And don't forget to include the Blackdart in ther at some point.
It is included already, I develop both actually in parallel, because the tasks are very similar. :lol:
The Black Dart currently gets the virtual machine self-test procedure, the skeleton of the VM machine language is defined, additional VM operations will be included if needed for making the code run faster. Also I prepare a large A0 poster currently that contains the planned computer network of the Black Dart for reference (A mix between tree and omega-net architecture). a version that flies by using the new computer system will be a few weeks away, and that will be still pretty limited. But I can then already tell you which switches the computers will need and how the panel for that should look like, if you still want to do some modeling there. I plan to be in public beta testing phase already when I switch to implement the operating system and the Black Ada run-time library.
(Shameless ad :tiphat: )
The AP-101 emulation is almost done, the I/O functions still need to be implemented, I saved them for last in the hope of getting better information of the real thing, because I needed to "guess" operation codes there. HLASM is also getting there, I still have 20 weekend hours unused because of the move to a new flat. Testing is currently by simple binary ROM modules, the ROM modules will later be used for defining the initial boot sequence after an IPL. The core functions of the HLASM are implemented in a DLL, so you can include it in compilers...for example for HAL/S.
Poscik
Addon Developer
Our current entry profile is rather mostly linear. It just calculates average drag needed to reach target base. And this works pretty fine I think. Real reentry path should contain equilibrium glide phase, thermal control phase, constant drag phase etc. But this is out of my range at the moment. Current method is simply, and it's working.
And info: I think in January I won't be able to do anything. I have a lot of exams on uni, so I'm totally focused on it.
And info: I think in January I won't be able to do anything. I have a lot of exams on uni, so I'm totally focused on it.
Will this enable the operational use of the Rendezvous Radar mode of the Ku antenna?
SiameseCat
Addon Developer
I'm trying to simulate the SPEC 34 ORBIT TGT display, which computes the DeltaV values for rendezvous burns. The Ku antenna isn't involved at all. (The target vessel is being specified in the scenario file; eventually, we can have some kind of MCC vessel/display which would allow this kind of setting to be changed).
OK. Thought that you might be doing the entire rendezvous procedures. And the first use of SPEC34 is in ENABLE RENDEZVOUS NAV, BLOCK 7A. The RR gets involved at TI burn -00:50 through SPEC33 REL NAV ITEM 13. That is RR NAVIGATION, BLOCK 13B.
Then it stays in the RR mode through arrival on the RBAR.
Poscik
Addon Developer
Today I had some free time (in train ;P) to look at Entry Manual DaveS has posted. First - it is awesome document. And what I can say: drag seem to be calculated correctly, method is also correct, as with given speed we have to descend more to increase drag and vice versa. Just thinking about the way of getting reference h-dot. This also can be written to lookup table.
A lot of reading waiting for me, but I found this document very interesting, everything is well explained here. Thanks for that.
A lot of reading waiting for me, but I found this document very interesting, everything is well explained here. Thanks for that.
