[19:08:26] NASSP Logging has been started by n7275 [19:08:30] Guenter! [19:16:49] Apollo 13, a bit more padload updates required. But I've had enough for today. I think I will do Apollo 11-14 as one pull request, all the missions for which we have the flown padloads [19:17:22] and if Apollo 7-10 is too annoying to deal with, then I will only update the launchpad data that I want to delete from the CMC init code [19:17:48] and I see the Skylab PR :D [19:19:50] 12 feels kind of pointless to do an update now haha, because we might get the rope fairly soon. But with the padload generator it's just a few click to generate a new one, so I'll do it. [19:20:33] sounds good [19:26:15] we just need to find the CSM Data Book revision 1 [19:26:23] revision 2 has the Apollo 12 padload [19:26:26] revision 3 has 13-17 [19:27:02] would be a help [19:28:24] our Apollo 7 padload was a lot of work for a lot of people over 15 years to figure out. I can replace it with a padload from my padload generator. It's just, without having a definitive source, does what I think the padload is likely to be override all that work... [19:29:17] I'd rather not change it unless I know it's the right thing to do. Not just "safe" to do [19:29:51] so I might just do a partial update [19:29:56] we'll see [19:34:34] Who knows, maybe Sundisk will miraculously turn up. [19:36:21] that would be fun. Although for the padload we will have to do a bunch of guessing... [19:47:43] where do you think I should leave off with Skylab? I should probably the IU class [20:04:45] maybe that is even too far, as it can't do anything useful yet [20:14:04] maybe I'll just stick some docking ports on it and call it good then [20:26:33] also a few more class capabilities [20:26:51] it doesn't even have a mass yet :D [20:27:11] moments of inertia, simplified drag model [20:27:18] some vessel basics [20:37:07] oh yeah those too [20:38:47] call it good when you can dock a DG to the Skylab and have the DG control the stack. So somewhat realistic mass, PMI and a docking port [20:45:40] you could even invest some time into some of these basics. Like, CG location. The mesh has a center, but it might not be the actual center of gravity [20:46:33] so before you fine tune e.g. docking port location and things like that, figure out stuff like that [20:47:43] Skylark has this whole separate docked DAP, might as well have a Skylab that already behaves correctly with SM RCS firing right from the start [20:50:30] night! [14:24:36] good morning [14:29:52] hey [14:31:27] time to create some more padloads... [14:32:40] creating is the easy part. Checking against our current one and being confident that the update is good, that is the hard part :D [14:35:15] at least you're doing most of them at once, so if someone encounters a problem it'll be fairly easy to track down [14:36:40] oh yeah, if there turn out to be bugs, I'll do a code fix and just generate them all again [14:36:49] how is Skylab doing? [14:37:26] fairly well so far, I have a few more things to track down [14:38:10] the diff is huge now because I shifted the mesh so that the origin is at the forward docking port, rather than at the centroid of the bounding box [14:38:47] I have an accurate mass and PMI; CoM location and drag need work [14:39:19] is that the center of the Skylab coordinate system, at the docking port? [14:41:59] I'm not 100% certian of that yet, but I did find a document that refered to a combined CSM+Skylab CG location in inches from the docking port plane [14:42:27] unfortunately without giving any useful numbers [14:43:12] operational data book probably has some good details there [14:43:26] I will look [14:43:37] https://web.archive.org/web/20100519095744/http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19770080483_1977080483.pdf [14:44:05] oh yeah [14:44:13] PDF pages 25-27 [14:45:23] careful with this document [14:45:31] it might postpone your PR by a few years [14:46:16] internet is being slow... [14:46:28] document is also large haha [14:49:36] oh my... [14:49:56] okay, I'll be back in like 2025 [14:50:04] cya [14:51:52] after the initial PR gets merged, the most interesting system is probably VHF ranging [14:52:01] ooo this has aerodynamic data too [14:52:02] then we have an easier time using it as a rendezvous target [14:53:06] haven't looked into it much yet, but I'm assuming that's somewhat of a transplant from the LM system? [14:53:14] probably [14:53:31] don't think they changed much in the CSM for that [14:53:47] so it must be very close to what the LM had [14:55:03] Apollo 12 padload, quite a few differences to our current one. Apollo 11, zero [14:55:22] 11 only has the IMU biases as a difference, that are padloaded as zeros [14:55:33] so I must have recently done some work on it :D [14:56:30] oh that could have been the "pre alpha" version of the padload generator, last year September [14:57:04] I have a vague memory of that [14:57:27] there was a bug with the solar ephemeris, I see a commit fixing that [14:57:30] I do remember that part [14:57:57] oh, before I forget [14:58:37] speeking of discussions from last year. do you remember the airfoil discussion on O-F about singularities? [14:58:55] oh yes [14:59:05] is there a new one? :D [14:59:11] do people finally believe in it? [15:00:33] oh the thread came up in a google search for me, but I was trying to remember if you had sugestion for something that could be implimented in Orbiter to avoid the issue [15:01:19] oh [15:01:22] hmm [15:01:42] I see how you're doing it in the CSM, but that approch would have problems for asymetric vessels [15:02:05] true [15:03:09] I had ideas, but they do make it a bit more difficult for the people who have to implement vessel aerodynamics [15:03:43] basically calculate the force and moment vectors entirely in the airfoil function [15:03:51] it isn't much of an airfoil then [15:04:08] Spacefoil [15:04:14] haha yeah [15:05:52] I'd have to do a bit of research again to really give a good answer for this [15:06:35] and it is quite a bad system for aircraft [15:06:58] to have the user create the force and moment vectors from scratch [15:07:36] it's still axis symmetrical, but I like how the NAA simulator calculates CM aerodynamics [15:07:50] I think from the standpoint of adding it to the API it would be pretty easy, most of the work would be done by the developer, then they'd just pass in a function pointer [15:08:20] I have looked at the code in Orbiter for this, it could basically be an alternative to airfoils [15:08:36] so you couldn't have an airfoil and this new system at the same time [15:10:41] hmm [15:10:51] I mean, it could still be somewhat simplified [15:11:03] it could still be coefficients and not forces the callback function provides [15:11:29] maybe CN, CY, and CA rather than CL and CD though [15:11:44] yep [15:11:57] and the same for moments [15:12:19] and as a function of all three rotation angles [15:15:15] and you still could do a axis symmetrical version [15:15:28] NAA simulator has a CA table and a CNY table [15:15:31] and the force vector [15:15:32] becomes [15:15:42] CA, CNY*sin(phi), CNY*cos(phi) [15:28:08] I have a short list of Orbiter features I will probably try to slip in at some point. Given the pace of development, I'm not in a big hurry. [16:22:40] I'll get my updated CG and simple aerodynamics pushed tonight [16:23:44] ah great [16:23:51] docking port defined in the config file I see [16:24:01] I think that's enough as a start [16:24:18] like I said, next I would like to see VHF ranging. Next PR [16:27:40] might cause a painful amount of compromises to implement such a detail sort of system this early on :D [16:28:34] like, the timestep of it might run into the Skylab vessel timestep initially, where in the LM it is buried in 10 layers of timestep functions [16:28:39] run in* [16:37:16] I think I can impliment it without implementing the whole VHF system [16:37:39] haha good [16:44:45] morning! [16:47:32] hey Mike [16:48:48] what's up? [16:49:24] making sure my padload updates are good [16:49:45] padload generator makes it easier... but not as much for e.g. Apollo 13 with Comanche 55 [16:50:11] can't check against the flown padload there [16:50:21] yeah [16:50:31] hopefully soon (tm) [16:50:39] I can't check against the Apollo 11 padload either :D [16:50:42] but not yet [16:50:45] as it's missing a page [16:50:56] but not a significant one [16:51:21] 2/3 of the RLS (which I can just take from the LGC) and lunar ephemeris, which is different in NASSP anyway [16:51:42] so not a problem [17:10:37] ok, 11-14 CMC padloads done. Now the hard part. 10 and before [17:14:09] ah yeah, the total mysteries [17:14:53] haha not quite, but I can't really refer to an absolute authority, the flown padload. So I need to make my own decisions for every line of the padload, where it differs from what we currently use [17:15:14] is the padload generator actually smarter yet for this rope? That is always the question [17:15:59] yeah, that sounds like a very tricky question :D [17:16:35] HORIZALT is the first good example of it. That's the altitude used in P23 to define the horizon you see [17:16:46] this value is astronaut specific, figured out in training [17:17:02] it's a difference between our current and future padload [17:17:31] had someone maybe looked up the value that was used on that mission? Tindall gives it for some missions [17:17:46] or did I just use the same value as Apollo 11 by default in the padload generator for now [17:18:04] that's what I have to look up every time now haha [17:18:58] not a critical difference of course, both values do work. But it's a difference and before I make padloads worse, I'd rather do the research [17:20:28] yeah, makes total sense [17:20:50] for Apollo 10 we could actually get a padload from the Alternate & Contingency Checklist, but we don't have it [17:20:52] ... [17:20:56] but we have it for 11 [17:21:00] I can fill the gap hahah [17:21:03] oh nice! [17:24:15] gap filled [17:24:46] I don't know if they already flew a padload in checklists before Apollo 10. The answer is probably no. [17:24:50] Pretty sure for 8 [17:24:57] that they didn't have it [17:24:58] not 100% for 9 [17:25:01] I was about to ask haha [17:25:37] for a start, there wasn't an Alternate and Contingecy Checklist [17:28:38] there was an auction of the Apollo 10. Very cruel, one of the example pages they give is the one with instructions how to do the backup padload [17:28:48] next page would have been the start of the numbers... [17:30:27] https://www.rrauction.com/auctions/lot-detail/338918805384288-apollo-10-flown-checklist [17:31:21] what would the page numbers have been? there is a collector I can bother who may or may not have a scan [17:32:24] hmm, I can't see page numbers [17:33:09] oh is it just the whole "erasable load update" section? [17:33:24] yeah [17:33:27] https://history.nasa.gov/afj/ap11fj/a11acc/a11-acc-10-f2-19.jpg [17:33:46] this is the Apollo 11 page that I also see in the Apollo 10 auction [17:33:58] and then it's just the tables that follow [17:33:59] https://history.nasa.gov/afj/ap11fj/a11acc/a11-acc-11-f2-20.jpg [17:34:22] 4 pages for Apollo 11 [17:43:34] email sent [17:44:35] nice, thank you [17:45:11] they do cheap slightly out with these backup padloads sometimes. The Apollo 15-17 one doesn't have the numbers for P15 for some reason [17:45:18] maybe it's only meant for TLC/TEC [17:45:32] if you had this issue before TLI, you are no go [17:45:48] but otherwise it's complete [17:46:58] the one from the Apollo 15 G&C Checklist is probably the first real CMC padload we had [17:47:33] I don't know why nobody had this idea before me. We had Artemis available, but nobody really had made a padload for it [17:47:45] not a useful one anyway :D [17:47:57] I took it for a spin then with this padload [17:48:12] like 2015 [17:51:03] oh man haha [18:18:45] n7275, I'm taking the short route and updating just what I have for Apollo 7-10 to remove CMC init code [18:19:00] so I'll add that to my PR [18:20:25] sounds good [18:22:07] then I should be done with this for now. At least I can do the code changes I want [20:47:12] night! [14:23:32] hey Niklas [14:24:27] hey [14:47:59] The skylab databook has force coefficients fitted to 2D Fourier series [14:49:57] They have their singularity along the +x [14:50:17] well, and -x too [14:51:30] for aerodynamics? [14:51:39] yeah [14:53:03] so CA,CN,etc become CA(alpha,phi) etc. [14:54:11] interesting from an interpolation standpoint, but the first thing that comes to mind is the method that S. Pines uses to eliminate pole singularities [14:54:37] I'd go with SetCW for now [14:54:46] it doesn't have singularity problems :D [14:55:24] oh for now, I'm not messing with anything that complex [14:55:31] pun intended [14:55:40] ha [14:55:49] SetCW does have the issue that it uses a 0.5x factor twice [14:55:57] so a drag coefficient of 2.0 has to be 4.0 in SetCW [14:56:08] and its calculation is a bit bad at 45° angles [14:56:32] eww [14:56:53] I have a small change to make then [14:58:27] I found out the hard way [14:58:36] later I checked in Orbiter code to confirm [14:59:12] Orbiter calculates the dynamic pressure, 0.5*rho*V^2 [14:59:23] and then for the drag force it does 0.5 again... [15:03:23] that probably explains why so many Orbiter addons feel slipperier than they should [15:03:55] also, Deltaglider DAP is pretty bad at docked skylab burns [15:05:05] haha [15:05:13] sadly so is the AGC DAP [15:05:59] the CG is 24 inches off of the docking port centerline [15:20:18] quite a bit. Probably due to the ATM? [15:26:14] testing my update for the revised CMC initialization [15:26:27] the shape of the Earth is biting us again [15:26:40] that doesn't change, it's always been like this [15:26:53] geodetic vs. geocentric latitude [15:27:27] loading the correct latitude like in the real padloads, which is also where the launchpad is visually in Orbiter, is actually 17km in error [15:27:48] morning! [15:27:55] CMC state vector is always a bit garbage after insertion [15:28:01] oh wow. that's a bit [15:28:09] hey Mike [15:28:14] hi Mike [15:29:07] yeah I was checking the math the AGC does at liftoff [15:29:18] to calculate an initial position vector [15:29:29] I did notice that our LC-34 altitude is 30 meters wrong as well [15:30:10] but yeah, 17.9km is what I am seeing [15:30:18] 1 meter if the shape were right [15:30:53] from error sources like the Earth rotational rate constant in the AGC [15:31:03] but totally doesn't matter, just 1 meter :D [15:31:36] for the same reason my idea for a EMS reentry challenge lua script doesn't really work [15:31:47] not without using a biased latitude [15:31:57] it lands off by many kilometers [15:32:10] I'm not sure it's a good idea to fix this in the padload though [15:32:19] we could do it [15:32:30] somebody needs to give the earth a good squish at some point [15:33:08] we have been using sort of biased landmarks for P22 [15:33:16] to be able to track them exactly [15:33:23] it's the same problem [15:33:32] We could use a bias latitude and the issue goes away [15:33:40] biased* [15:33:48] but like I said, latitude in Orbiter and the padload already agree [15:33:57] we would change it away from that [15:39:30] other than that my new CMC init code works [15:39:58] well I was checking any navigation or attitude issues after insertion [15:40:12] it's the same as before [15:40:22] so a bit bad :D [15:40:56] Skylark has its TEPHEM at a different address, so I still have to have that as rope specific code [15:41:21] only would be a problem with modified Skylark ropes... [15:41:37] we are a bit far away from that :D [15:44:05] lol yeah [15:44:45] if we get Skylark, disassembly will be quite an effort [15:46:34] we can do it. You, me and Norton [15:46:52] or realistically, mostly you and Norton [15:49:23] Norton will be the real MVP lol [18:29:44] thewonderidiot, have you ever encountered anything about that optical alignment targets at KSC, where P03 is pointing at? [18:30:08] there is a whole building for this purpose for the LV IMU, but that's not what the sextant is pointing at [18:30:22] hmmmmm no I haven't [18:40:08] maybe I find them on some old KSC map haha [18:58:22] I seem to reacall reading that they were on top of the VAB, not sure where I got that info or how accurate though [18:58:42] *recall [19:05:08] if they were, maybe I did something wrong with the procedure [19:05:16] or the padload. But the padload should be as flown [19:08:52] n7275, I see you are doing a ShiftCG now [19:09:24] I thought the ATM might shift the CG towards it [19:09:40] but it looks like the CG is now actually away from it, away from the centerline? Is that right? [19:10:24] I need to verify that one again, I think [19:11:04] unless there's something very heavy on the "bottom" of the station, then I'd say that is actually in the other direction [19:11:19] left handed coordinate system might be striking again [19:11:27] can be quite annoying [19:12:34] your concept makes sense I think. Define meshes and stuff like docking ports in the Skylab vessel coordinate system [19:12:47] for which we probably have good numbers, where the docking interface is etc [19:12:53] and then afterwards a ShiftCG [19:13:29] that mesh is very wrong, which is why I still have a mesh shift [19:13:46] right. And the center of the mesh is also not the center of that coordinate system [19:14:01] the lower docking port should be in line with the ATM axis [19:14:21] ouch [19:14:35] for the CSM I have kind of visually established the difference between the mesh and the CSM coordinate system [19:14:41] also the main docking port is 4cm to the left of the ATM [19:14:44] and then have this offset in one place only [19:15:08] I guess getting these things super exact isn't worth it yet with this mesh [19:15:13] and there are random floating mesh bits [19:15:45] there isn't even a COAS target [19:15:50] right [19:16:05] I'm not sure we can pull away Jordan from the Virtual Cockpit right now :D [19:16:21] but visually it should be somewhat possible to dock with [19:16:45] yeah, just did that with the scenario editor, to a DG [19:20:44] yeah, I'm fairly certian I have a (Y?) axis sign error [19:21:33] and I would agree about the VC work :) [19:21:52] Alex made our LM mesh from scratch [19:21:56] maybe we can ask him :D [19:22:47] I bet if I tried to make something like Skylab in blender it would look worse than what we have now... [19:23:08] same [19:24:04] I can make great textures though...using the MS paint spray-can tool :) [19:24:10] that's why I won't even try [19:25:06] about a decade or so I went through a tutorial [19:25:10] like a very simple rocket [19:25:21] I've tried exporting stuff from Solidworks/Inventor but the mesh topology is just horrible [19:25:24] with a program for Orbiter, called Anim8or or something [19:25:47] ahh yep good ol'e Anim8or [19:25:55] ok, not specifically for Orbiter [19:26:04] maybe you could just export a msh file [19:26:39] I think it had 3ds format output and then there was a commandline utility called 3ds2msh [19:27:10] ah yeah [19:27:22] thats as far as I got [19:27:52] same [21:00:56] night! [14:27:42] good afternoon [15:01:22] hey Niklas [15:05:36] got that CG location figured out? [15:05:39] i fixed the Skylab CG, it is on the ATM side of the centerline [15:06:06] how are axes of the mesh in Orbiter, is it like the CSM? [15:06:16] Y and Z axis exchanged [15:08:20] x=y, y=z , z=x [15:08:42] fun... [15:08:59] well from my point of view, with that fixed, drag fixed, Skylab 2 scenario uses our Skylab [15:09:02] I am happy [15:09:34] okay, I have no issues with ht being merged then [15:11:06] s/ht/it [15:12:10] I can merge it when Max has confirmed that his requested changes are done [15:13:39] I re-requested a review from him [16:12:23] morning! [16:12:54] hey Mike [16:53:16] n7275, Skylab merged [17:09:16] yay! [17:27:41] I don't really need extra projects, but Skylab attitude control systems sound kind of interesting to me... [17:36:41] attitude control would be nice to have [17:37:45] I'm hesitant to add any systems stuff too early, but would would you need anything electrical for that? [17:38:06] probably not [17:38:38] how does even implement CMGs in Orbiter... [17:38:42] does one* [17:38:59] it will also need the standard 6 APS thrusters like a S-IVB [17:39:15] I know there was a CMG addon for the ISS [17:39:21] not sure the code is available [17:41:26] it is [17:41:56] ah [17:41:58] cheaters [17:41:59] SetAngularVel [17:42:12] The problem is there is no function like AddForce for moments [17:42:31] :( [17:42:50] I wonder if using SetAngularVel causes any issues [17:43:34] when I got a bit desparate with the aerodynamics I was thinking of inducing a moment with AddForce that cancel each other out [17:43:49] can still work of course, but I didn't 100% figure it out [17:44:25] but yeah, SetAngularVel would overpower e.g. the CSM firing thrusters [17:44:28] that's not realistic [17:46:44] I wonder if they reused the electronics to switch the FCC to control from the CMC [17:46:51] to switch it from IU to Skylab's own controls [18:02:01] looking at Orbiter code, I don't see any reason why there couldn't be an "AddMoment" function, there just isn't one [18:49:58] right. I would probably still start with a AddForce solution [18:50:07] or really first with the thrusters [18:53:11] oh yeah, we could just use AddForce; for some reason I had it in my head that it only acted through the center of mass, it takes two vectors though [18:54:21] wow, I can't read today haha, you already said basicially that.. [18:55:59] yeah, I think I had some coordinate system issues with creating moments like that [18:56:03] don't remember [18:56:12] but it sounds kind of simple enough [18:56:21] 6 thrusters, moment arm 1 meter for simplicity [18:56:27] 2 for each axis [18:56:40] always cancelling each other out in force [18:56:44] just providing a moment [18:58:04] that would work [20:36:36] night! [14:43:13] hello [14:44:10] hey Matt [14:48:22] how much are you using the CSM VC? [14:48:35] how often have you accidentally displayed a cue card? [14:49:26] accidentally? I don't think I ever have [14:49:51] I only use 2d for the optics, everything else is in the VC [14:49:53] for me it's the boost/TLI procedures one [14:50:05] left of the DSKY [14:50:33] the clickspot for that extents from the velcro left of FDAI 2 to right next to the Verb/Noun buttons [14:50:34] sometimes I forget where the click spot is to hide them though [14:50:59] I'm pretty sure other people have mentioned accidentally displaying that one [14:51:07] often by clicking back into the sim [14:51:19] I'll ask on Discord, but I might split up that clickspot [14:51:33] so that it's only the velcro at the top and then the connection between the two at the bottom [14:51:38] but you have a good point [14:51:46] hiding them can be tricky [14:51:53] so this might not be a great change [14:53:09] maybe if there were a slightly darker spot where the velcro is? is there any glue showing through on actual cards? [14:53:15] three at the bottom* [14:53:17] hmm [14:53:48] maybe not so much, as the cards we use are scans of the actual Apollo 15 cards [14:54:19] one other way would be to have a different click area for a card that is currently hidden or shown [14:54:27] larger area for the card currently showing [14:54:41] so that you click on velcro to make it show [14:54:45] but a larger area to make it go away [14:55:08] would complicate the code though [14:55:46] yeah that sounds dangerous [14:56:13] nah, not dangerous really. Just a bit more complicated [14:56:26] and difficult where cards overlap other panel areas [16:20:11] not that I should be putting to much toward this yet, but I did try plotting CA and CN vs alpha and phi [16:21:48] hey where you have detailed data, might as well make use of them haha [16:24:43] morning! [16:33:14] hey Mike [16:33:17] hey [16:37:00] I looked at the Fourier coefficients and decided I neither wanted to type then, nor did I want to implement anything that calls sin() and cos() hundreds of times per timestep. I think in an actual implimentation I would just make a big lookup table [16:37:28] yeah I think that's the way to go for these airfoil functions [16:38:00] for the CM I am using a three dimensional table now, but that's still pretty cheap calculation wise in comparison [16:38:56] a function that just enters indices into an array is pretty cheap [16:40:05] where we have good, complete, data here, this would also be a good showcase for a new OAPI function [16:41:19] that we can't use until we switch to OO [16:42:06] for anything else, I have my Jan Roskam and Bernard Etkin textbooks I can hit the appropriate people over the head with :) [16:43:19] yeah, until we switch to OO, I'm fine staying with the SetCW method [16:44:32]