GLS
Well-known member
We're not even at the docking part yet, just the "initial capture" (via attachment) causes vessels docked to our target to undock.
Space Shuttle Ultra 4.0 PRESS TO MECO
- Thread starter Urwumpe
- Start date
Well, one way for now could be to required the vessels to be attached rather than docked. Then things will work. I do have an open feature request for proper docking event handling in the Orbiter core: http://www.orbiter-forum.com/project.php?do=gotonote&issueid=1204&goto=firstnew
GLS
Well-known member
Any progress on getting this out the door?
Becker
New member
Have noticed launch scenarios using ODS no longer work at the moment. Changing UseODS=TRUE to FALSE the scenario works.
GLS
Well-known member
Confirmed and currently debugging....
---------- Post added at 02:04 PM ---------- Previous post was at 01:34 PM ----------
OK, I found the problem and fixed it... and it still crashed... :facepalm: Turns out the post-fix crash wasn't related to the ODS, but it's our old ET crash again.
Anyway, the problem was that I didn't create a dummy attachments for the ODS when it is enabled, even though it's not being used ATM, so the attachment order became messed up = CTD. Fixes will be up in a little bit.
GLS
Well-known member
Anything I can do to help get this out the door still in 2016?
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Not sure there, theoretically, you could do the Centaur Animations as far as you can there and I just focus on the bellow animation component. I still have to do some basic math there to project the vertices of the bellow group on the skeleton in the initial state.
The final work on the real RCS implementation should depend on testing, testing and testing some more. If you can test this and provide accurate discrepancy reports to me, this would be great, after all, you know what input a developer needs.
GLS
Well-known member
The CISS animations are done and dusted for several months now. The current problem is that the CISS G mesh was changed and the coordinates were not updated == messed up animation. Then there's the whole bellows thing....
Are these RCS changes really needed now? What is there to be gained? Wouldn't it be better to have the new GPCs working, and then do the OMS/RCS "from scratch" with all the tanks, valves, I/Cs, switches and SW to monitor and control it?
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
In brief, they are broken and need to be fixed, right?
Aside of the current simplified RCS implementation behaving wrong in Orbiter regarding the forces and torques and that the fuel consumption was also way off with it? I remember looking at "reintegrating" it again, because we had issues during docking, as well as the Orbit DAP reacting very badly with real-world values.
We could push everything behind the DPS fixes. This would then mean, that a) I need a paid sabatical at work for a year to prevent this blocking the SSU development for longer and b) All development work would be either DPS or something outside the STS stack.
I am not sure that could work that way. a) is absolutely unrealistic, since returning from Denmark I was overwhelmed with work. b) would mean we turn from SSU to "NASA STS Support Systems Simulation Ultra" for a while.
I don't like it.
If you know a faster way to finish SSU, without depending on me returning to a regular 40 hour week, just fork me out, do a better implementation. I can't deliver a big change quickly right now.
I would still recommend doing this in small agile iterations and tolerate having to throw away about 20% of the code during later refactoring.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
That was the plan for me, but it looks like GLS wants to see it finished first and delay everything else for it. After all, finishing it incrementally would mean refactoring to integrate other subsystems with the new DPS.
For getting to the point, where the rest of the systems would be essentially plug&play, we would essentially just need a Meta-IOP, that simulates the I/O of a common set. If this IOP is then the interface to the rest of the subsystems, it doesn't really matter what happens on the other side of it.
If the IOP is the really only interface between the other systems the DPS, I'd go for it. Then the DPS would be able to proceed at it's own pace and not hold up anything else. It seems to me that the DPS is what has always been the "sound barrier" of SSU.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Yes, it is. It is essentially the subsystem that holds everything together. And it is the most complex subsystem as well, maybe even more complex than a single SSME.
The IOP is almost all of a GPC that communicates with the outside world, and it is a computer of its own actually. In a redundant set, only one GPC's IOP commands a bus and listens to the incoming data and the other GPCs IOP only listens, so a meta-IOP of a redundant set would actually be like a IOP that commands and listens to all data buses that are assigned to the redundant set.
Aside of the IOP, the GPC also has some registers for reading and setting discrete lines, but those are almost completely used for driving GPC related displays (like the CAM Matrix) and handling GPC related switches... and defining the number of the GPC, by three bits in one of the input registers.
GLS
Well-known member
I was under the impression that the new DPS would be available within a few weeks or months... apparently not so... 
(and I'm not "complaining", I know people have lives and all that stuff, and it all comes first)
So, maybe when I get tired from work on the SSU Workbench, I should implement a "poor man's" COMPOOL (or whatever it is called) as a SimpleGPCSoftware class, to centralize access to data like speeds, altitude, rates, etc.
(and I'm not "complaining", I know people have lives and all that stuff, and it all comes first)So, maybe when I get tired from work on the SSU Workbench, I should implement a "poor man's" COMPOOL (or whatever it is called) as a SimpleGPCSoftware class, to centralize access to data like speeds, altitude, rates, etc.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
I was under the impression that the new DPS would be available within a few weeks or months... apparently not so...
So, maybe when I get tired from work on the SSU Workbench, I should implement a "poor man's" COMPOOL (or whatever it is called) as a SimpleGPCSoftware class, to centralize access to data like speeds, altitude, rates, etc.
Well, do it if you think you are faster. I won't stop you.
I can even tell you if I will have the national holiday weekend.
Well, we do have some issues here. I just did a quick&dirty test and things are not working well. I tried a simple pitch up maneuver in LVLH, PRI with all axes in DISC RATE. The orbiter barely responded and when it finally did, it started a combined right roll, right yaw maneuver instead of just pitching up.
Manual, RHC. I later tried a DPS maneuver by taking the DAP back into AUTO and that didn't work very well either as it failed to stop at the set attitude.
---------- Post added at 07:07 PM ---------- Previous post was at 06:56 PM ----------
Another test, completely under DPS control this time. From P=90 to P=270 yielded no change in attitude at all. All axes reported 0°s. So it seems the RealRCS implementation is broken and for the end user not really good.
Similar threads
