Reddy

Members
  • Content Count

    55
  • Joined

  • Last visited

Community Reputation

54 Excellent

2 Followers

About Reddy

  • Rank
    GNC Specialist

Contact Methods

  • Website URL Array

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi Reddy,

    I actually made an account just to ask you a question.
    I'm studying control systems, and I just picked up kRPC so that I can start testing control systems, development, and design in KSP.
    I saw that you went and made PEGAS in ksp using kOS. That's really freaking impressive.
    I'm having a lot of trouble coming up with an ascent controller that's any better than:
    "Hit go, wait a bit, okay start turning, keep turning, okay now you're at altitude"

    Which feels really scripted, and not optimal at all, so obviously I'm looking to make something better.
    PEGAS looks like a good system to emulate. Would you suggest I try to come up with a comparable system if I want a really good ascent controller?

    What suggestions, tips, resources, things to look at would you have for someone who's trying to take on this endeavour?

    All the best.

  2. It sounds like a common problem with kOS and RCS steering. Try to run something like this: LOCK STEERING TO RETROGRADE. WAIT 20. UNLOCK STEERING. and see what happens. If you observe the same symptoms, it's the kOS fault (or your vehicle, but I'm not sure). @LAND ASAP I see you're trying to launch to zero inclination orbit. Where is your launch site located?
  3. Great mod, just the engines I needed - especially those tiny ones for small upper stages! Thank you I found one error however: the RO config for S5.92 seems off. Looks like you've calculated the mass ratio for propellant volumes instead of masses, and the dry mass of the engine is a tad too high (confused with the S5.98M?). Please compare the numbers with RO's own config (RealismOverhaul\Engine_Configs\S5_92_Config.cfg). Btw, the same thing with propellant ratio with S5.98M.
  4. Not at all, this is what the PRs are for - all improvements are very welcome, thank you @Pand5461! I've researched the apses difference thing back during the prototyping days - it's interesting, but the error is always there, even in a MATLAB simulation running at 1ms precision. Something tells me that this is just how the UPFG is and nothing that can be done about it at all. As Jim DiGriz said a few posts above, this implementation most likely never really flew the Shuttle - it was a good first draft, but likely received many improvements before actually being used in the GN&C. And there had to be something to improve on, right?
  5. @JohnMcLane Thank you =) Staging a payload can only occur if you have a sequence event set up... or if there is stage in vehicle but no corresponding physical stage to be dropped. PM me with the details of this issue as it sounds weird.
  6. Thanks, @JohnMcLane! One thing you must be aware of is that masses are not for the individual stages, but for the entire vehicle at this stage. So the CCB mass in PEGAS must also include the Centaur upper stage. I will make this more clear in the next update of the tutorial
  7. @Gousaid67's bug reminds me of a feature I wanted to request - or rather ask if it's even possible. I dream of a mod setup in which I am only allowed to see what my craft sees (preferably using onboard cameras - like Hullcam VDS), and the map view is only an astrodynamics reference. That is, all the nice scatterer effects, volumetric clouds, shaders etc. are only visible in the in-game view. Map view only shows maps, not the amazingly rendered planets; kind of like in SpaceX' streams when the vehicle coasts. In short, map view would look like this: But only after getting my vehicle in space I would get to see this: Could something like this be done, @Phineas Freak?
  8. PEGAS v1.1 is out now! Get it while it's still hot! List of new features includes: inter-CPU communication system by Patrykz94, roll control via user events, better throttle control via user events, new user event type (jettison) to account for the amount of jettisoned mass, stages can explicitly shut down engines (useful for Falcon 9 style missions), LAN and inclination as optional parameters (default inclination will be equal to launch site latitude, defualt LAN will be set for the launch to occur in 30 seconds from "now"), launch direction (northerly and southerly, as well as "nearest opportunity"), automatic seizing control from the kOS CPU part, as well as a few bugfixes: throttling now obeys the way Realism Overhaul works, sustainer-type stages are now handled properly, minor code clean-ups, GUI and documentation fixes. @Jim DiGriz I am tempted to shamelessly say that plus or minus, what matters is that it flies To be honest, I just don't have as much time as I used to, certainly not enough to research the intricacies of the algorithm again. I have already limited my activity to maintenance, bugfixes and features related mostly to KSP-side infrastructure (like events, stage handling, action group support etc.). For anything that touches the UPFG itself: I will review pull requests, perhaps assist in testing, but digging deep into it like I did in mid 2016 - unlikely. Though I am curious to read about your findings! You know, I started fiddling around with kOS in early 2015 because I pretty much mastered the game and flying a hundred ascents to build&resupply my orbital station became boring. This was when I wrote my first autopilot. Soon, in search of a bigger challenge, I tried RO, but found that my toy-level script was no longer sufficient. Later I found Orbiter forums and PEG, and this was about the last time I've really played KSP. Ever since it was only pencil&paper, MATLAB and if I ever launched the game, it was just to test/debug PEGAS. Rendesvouz launches were always on the horizon of what I wanted to do (orbital station servicing, right?) and initially I thought this could be done with the basic PEG the Orbiter wiki describes (or some extensions of it). Realization that it's not was what pushed me to research further, to come across UPFG and subsequently to spend another year working on this project. Implementing the algorithm made PEGAS everything that I ever wanted it to be. It might not do everything, there might be things that it could do better, and sure I do have more ideas to add - but for most practical purposes it's more than enough. To me it's at its pinnacle as a tool. Of course it's not over yet: there will be more bugs and fixes, requests and features - bigger and smaller, but for now I am happy with how it turned out. I feel kind of like the South Park guys at the end of the "Make Love Not Warcraft" episode. I can finally play the game
  9. @windystig The tutorial is what you're looking for. @Jim DiGriz I've just tried it. After changing this to +, it failed spectacularly. Although it's a nice find on the phidot identity - nothing should change and indeed nothing changes if this line is removed. It is very strange, why is this term even there (I'm thinking about figure 5-6 in the block diagram for block 5 in the original UPFG paper). In the current form it introduces nothing - vehicles fly perfectly with and without it. Changing it to anything else just makes things crash in all sorts of ways. It's just hard to believe that they would burden the GN&C computer with such a heavy line if it does exactly nothing...
  10. First of all, I have tried following your discussion from pages 3 and 4 but I'm not really sure whether the problems you're discussing are a matter of PEGAS code, that is: does it do something wrong or fail in some case? If so, please make it clear what happens and when, and if you have a suggested solution - go ahead I also welcome github issues or pull requests. Now, to answer some of your posts: @Pand5461 This is a bit tricky and very very empirical. I have tried approaches basing on steering vector and Tgo, trying to measure differences between the values calculated in consecutive iterations. The main problem that I was having was that UPFG sometimes converged (measured either way) on very wrong results (i.e. pointing 30+ degrees below the horizon and crashing) - especially on later stages. The basic logic is that I measure Tgo and see how it's changing. You have to be aware that kOS takes a good while to run through the entire UPFG routine, so some considerable time passes between the calls. What I'm doing is I measure that time and adjust the expected Tgo before comparing it with the algorithm's prediction. If the difference is small enough, I count that as a hit and run again. The point is to get 2-3 such hits in a row - this means that predicted Tgo is steadily decreasing with time. Now comes the trick part. Sometimes after staging, UPFG would converge (that is, pass said verification algorithm), but the result would be rubbish (pointing down). I admit I have failed to find the cause of that, but I located the issue to be somewhere in the internal state of UPFG that has to be preserved between iterations. Simply reseting it in those situations would make things run smoothly. The very idea was to check whether the steering vector is similar to the "good" vector that the previous stage had. If they were very different (above 15 degrees), the UPFG state would be reset and reconverged with brand new state - for some reason, it would always (to the extent I tested) converge on a good solution (good = one that got it into orbit instead of RUD on reentry). The reset mode would print a PRIORITY_CRITICAL message in the GUI upon being called. However, I haven't seen this message in a good while when flying my rockets - it might very well be the case that this behavior is not an issue anymore. @Jim DiGriz It appears so, yes. I will fix this the next time I sit down to code. The reason this was never a problem is that this branch of code is executed only when the alphas parameter is less than zero - and IIRC this can only happen when the vehicle is in a hyperbolic trajectory. @gsarducci Currently there is no such option. This is kind of counterproductive, since the whole point of PEGAS is to not have the vehicle locked at one attitude, but continuously change it in order to maintain an optimal trajectory. Wait, haven't I replied you in issues? Anyway, I'm considering implementing a more general event type - including one in which you could pass a function delegate into an event. This would basically let you do anything. Still, making the vehicle spin when PEGAS tries to change attitude (to a new steering vector calculated at every iteration) is not a good idea, because you would be effectively fighting against what it's trying to do.
  11. I am sorry I was absent for a while. As some of you might know, I am a PhD student - there are periods where I simply don't have time to pay attention to PEGAS and this thread. I've just pushed some updates to the main repository, here's the list of new features: roll control - you can define initial roll (vehicle will roll to that angle during the initial pitchover maneuver) via controls["initialRoll"], and then control the vehicle's attitude using events, better throttle handling - RO does not treat the throttle slider in an absolute way: 50% slider does not correspond to 50% throttle, but 50% of throttle range that an engine allows. PEGAS can now handle this (fixing issues with g-limited stages), at the expense of users having to input an additional key ("minThrottle") along the "gLim" in their stage definitions, new event type: jettison - allows user to inform the system of the amount of mass lost in a staging event, which is also important in acceleration-limited stages (eg. if a stage's dry mass included fairings, and then these were jettisoned, the vehicle will weigh less than PEGAS planned for - as a consequence, throttle will be lowered at a slower than expected rate, consuming fuel slower, causing the engine shutdown later than PEGAS scheduled the next stage ignition: as an effect, the constant-acceleration stage could smash into the next stage), several minor tweaks: PEGAS will change the control part to the currently running terminal on boot, lack of "message" key in user event will no longer cause it to crash, etc. We're almost halfway to the 1.1 release, which will include also the following features: launch with no LAN constraint (something like a "launch now" function - LAN will still be constrained, but it will be hidden from user and dynamically calculated), launch opportunities (ability to pick northerly or southerly launch, together with the option "nearest from now"), better atmospheric ascent control (I'm thinking of something akin to aim points for optional, additional control over pitch during early ascent). I'll read up on that thread later and try to reply you guys
  12. @Alpha_Mike_741 Thank you for that comment! Glad to hear such words of support @Pand5461 It looks right... INC and LAN explicitly, SMA, ECC and anomaly from the remaining 3 - although in a not so very transparent way. I agree. Confusion was on my end, probably due to my lacking understanding of anomaly, which is now more thorough thanks to you pointing that out. Regarding projections - I use that in my position corrector, yes, but not in initialization. I choose the initial rd by rotating the current r, instead of projection of r on target plane. But I suppose it would save 1 iteration of convergence at most, since right after that first iteration it is constrained to the plane by said corrector. You and @Jim DiGriz mention an important thing: accounting of rotating reference frame. This is of course merely a KSP quirk, since the SolarPrimeVector constantly changes for some reason and the axes of the reference frame with it. However, both our current state (r, v) and desired state (rd, vd) change in the same way - shouldn't that make fixes unnecessary? Or do the intermediate vectors, like biases, thrust integrals etc. have to be explicitly corrected? I spent a while pondering on that when coding the kOS version, but decided to try running without any corrections first, see how it works and fix if it's wrong - but it doesn't look wrong. This conversation would be nice to have on github issues, too, as it has potential of improving PEGAS I will also let you know that I don't feel strong enough in control theory to do anything regarding coast phases optimization. I tried reading a few papers months back, but this level of math is far beyond me.
  13. @Pand5461 What a coincidence, I was about to reply to you First, I agree with your finding that rgoxy wouldn't have to be calculated separately, and this optimization is something I would expect to find in assembly code for the actual guidance computer. But for the purpose of explaining the logic of the solution, I think they left it in a longer but clearer form deliberately. Same with normalization of iz, it might just make it easier to explain the maths in the simplest way possible. Regarding the usage of projection of r instead of r in the initialization, I was surprised that you noticed this as I was certain that my final code already does it. I am 100% sure I had it in place at some point, since I spent several hours on trying to come up with a good initialization method - none of the documents I read contained anything on that. Simplest answer would be that I temporarily removed this at one of the debugging sessions and forgotten to put it back in Now, onto your question, but please clear a few things for me first. Why is the current state "next to unusable in stock", and how would inclusion of coasting fix it? I see a potential source of confusion in the fact that you're mistaken about the current constraints: actually only 4 of 6 orbital elements must be specified: semi-major axis, eccentricity, inclination and LAN (argument of periapsis and true anomaly are free).
  14. @kerbinorbiter I assume it literally said "No boot file loaded! Crashing..." - if this is the case, it means PEGAS hasn't found one of the variables you are supposed to create. Take another look at the tutorial (I linked to a section of interest), make sure all 4 variables (vehicle, controls, sequence, mission) exist and are named correctly.
  15. Sorry for joining the party late. Thanks @Jim DiGriz for the research and confirmation that the solution I developed is sound Regarding the difference between correctors in 19790048206 and 19740004402 (and hence my code) - these are actually the same equations. To see this, let's first look at 19790048206, which does: vgo = vgo - 1.0 * vmiss where vmiss = vp - vd = v + vthrust + vgrav - vd, so this gives: vgo = vgo - v - vthrust - vgrav + vd. Which means we update our vgo by (vd - v - vthrust - vgrav) in each iteration. Now look at what 19740004402 does: vgo = vd - v - vgrav + vbias (I reduced the vgop and dvgo terms) but vbias = vgo - vthrust (block 5) so we obtain: vgo = vd - v - vgrav + vgo - vthrust. Let's reorder: vgo = vgo - vthrust + vd - v - vgrav and what we obtain is an update of vgo by (reordering further) vd - v - vthrust - vgrav. Which is exactly the same thing Jim, can you elaborate on the difference in how they do rthrust and vthrust?