Cunjo Carl

Members
  • Content count

    485
  • Joined

  • Last visited

Community Reputation

430 Excellent

6 Followers

About Cunjo Carl

  • Rank
    Rocket Fancier

Profile Information

  • Interests Science. All of it!

Recent Profile Visitors

1173 profile views
  1. Welcome to the forums, @aerodis! Nice detailing on the Jag', I especially like the classic enormous spotlamps. Let us know if you have any questions- good luck in your challenges to come! I'm impressed with how well you got that design to work on the fly, @tsgaerospace. Fine work! The bump at 12:55 had me biting my nails . Also, that craft had a mind of its own, you did a good job finding the balance between guiding it and letting it drive as it wanted. @Ragingdonut Hey, a tricycle! I have to admit, I wasn't expecting to see any in this challenge. They're notoriously difficult to balance for high speed driving, which makes the vehicle more impressive to me! Am I noticing you've splayed the rear wheels a touch for enhanced friction control? I know it's a little late for your run, but to answer your questions in case others have them: The car needs to be able to stop, though parachutes are a fine approach . I'd rather not have folk worry about droppable markers- just nip a bit off the distance if you take a mile to slow down! You only need to save the 1 kerbal, though I'll make mention of it if you have multiple kerbals hitch a ride. Again, great job balancing the trike!
  2. It was a good try, but I happen to know the next will be @Ultimate Steve.
  3. @ARS I'm a connoisseur of science minutia, so it's nice to know I can still call 'em! That is the coolest looking iso for your design mockup, did you draft that? I had to look up the name- cute reference Railguns are notoriously resistant to simple theoretical analysis. It's frustrating, because the elements that go into them are all pleasantly fundamental and politely linear, but when you get them all together it turns into a jumbly mess unless you make some.... not-entirely-justifiable assumptions. Especially in regards to heating. But They are double happy funtime for finite element analysis spreadsheets! We can Googlesheets a model together if it sounds like fun? For fair warning from the start, a system like the one you're proposing won't do much for boosting velocity, but it will be fun . It'd require about 20 hours of work, most of which would of course be up to you. I'd be happy to help get you started, though. Not trying to butt in, just an offer In any case, best of luck on your thesis!
  4. @Ragingdonut, Sounds neat!
  5. @ARS Should all work great! The first bit with the acceleration after the barrel can also be a little easier when calculated with energy rather than momentum. In this case, we can see the projectile as having a kinetic energy (speed) which gets added to by the force as it travels over that distance. The energy that gets added is conveniently force*distance no matter how fast the projectile is moving! Initial KE + Energy Added = Final KE 1/2* m * v12 + F * d = 1/2* m * v22 How do you know when to use energy (W=f*d), and when to use momentum (f=m*a)? It's tricky, sometimes you can use one, the other, both... sometimes you need both! In general, if something is happening over a certain distance it'll be easiest with energy, while if something is happening over a certain time it's easiest with momentum. Rocket stuff (like engines) are almost always firing for a certain time, so momentum reigns king around here. Finally, how is it accelerating after it leaves the barrel? Especially at 30g, it could be a rail gun . Railguns have a hard time getting the projectile started, so one concept has been to start the projectile moving with another means, and then finish accelerating it with the rail gun (in this case a snubby little 1m one). Of course the practical cons heavily outweigh this in general, but it's a fun rationalization! Where is the right place for homework questions, @Shpaget? Edit: If there happens to not really be a place, would you mind if I made an offshoot thread for them?
  6. So my little one and I were playing with legos the other day, and I somehow managed a Sojourner! Here's the same little rover after he made some creative contributions. Also, ♩♯ Oh Canadarm! ♬♩ (Re @DoctorDavinci) SO. Sciencey toys. What sorts do you have lying around?
  7. All good people of humanity appreciate the Geneva Convention. Sadly so do all good termites of termitity.
  8. @IncongruousGoat The CS/.NET RTE just finished downloading, and hopefully I can give it a shot tonight! Would you like to send me any pictures or things to put in topic? Now I finally got a moment to rearrange the topic, I think it's fine as is, just if you want.
  9. @Ultimate Steve If you want to keep going in vein with the rocket designs, you can always stage or see how _fast_ you can make it to the 10km mark?
  10. @IncongruousGoat Fixed! I'm looking forward to checking it out, by the way. Good luck, and sorry you had to fight with portability issues; those are never fun.
  11. Staging Optimally A spreadsheet planner and conversation place. We've all been there. After all the hours building a launcher to put X tons in obit, you want to make sure that payload can do just as much as kerbally possible! But it's hard to know exactly how many stages to put in the thing, and how large to make each. If your stages are too small, you're wasting deltaV pushing around extra decouplers and engines, but if your stages are too big, you're wasting deltaV pushing around empty fuel tanks! So where's the magic happy balance inbetween? Now you can find out*! *Software provider does not assume liability for engineers trying to saw engines in half to achieve "The most optimum ratio!!" At the moment, there are 2 programs which can find the optimum relative sizes of stages for your rocket: One option is @IncongruousGoat's C# & .NET automatic version available here: Github Link! It'll suggest engines for you: The other option is a GoogleDoc spreadsheet program, which you can also use as a planner. More info on that follows: Instructions: 1. Open the doc, and make your own sheet by clicking the "down" arrow by the "Template" tab at the bottom, and click the duplicate button. Rename your sheet and you're set to play around! 2. Write in the names of each stage your rocket will have, and the TWR they'll need as well as their engine specs (see the ksp wiki for a quick reference). 3. Then for the stage's scale, type in a guess of 1 (scale is just a convenient measure of size). Down below you'll see a huge field full of information for how changing this scale for each stage will change the final rocket's efficiency. Simply make the best changes, and soon enough you'll have the very optimum of rockets! Notes: The template has a rocket already loaded in so you have something to work from. Here's a picture! The underlying math doesn't care how big your rocket is, or what order the stages are in, but if you give it your payload mass and stage order, it'll read out how big each stage should be and how many engines it should have. The optimum efficiency tends to be fairly broad, so there's typically plenty of wiggle room to choose a slightly-sub-optimal scale to get a whole number of engines. You can also tweak the TWR requirements if you really want to see a whole number of engines at an optimum . IRL just round the sucker It handles asparagus staging and drop tanks, because I figure'd it'd be fun! It doesn't handle weird fuel tanks that don't have a 1/9 ratio, but I can add that in if it's desired? This system does scoot mass around between stages to let more efficient stages cover for less efficient ones. You'll notice if you have a particularly inefficient engine (thud), the optimizer will tell you the most efficient scale for that stage is so small it has a negative deltaV. This means that it would be better deltaV-wise to not even give those engines fuel tanks... that's sad, thud. Sorry. Whatever, I'm using them anyway! If you don't want to optimize a certain stage, you don't need to. The solver will optimize all the rest around it. Final Thoughts: Please let me know if it winds up being confusing in any way. I'd like to make it convenient and intuitive, but I have a peculiar design aesthetic by nature. I encourage community additions and am happy to share the math behind the calculator. There's also ongoing development thread for the underlying math here, and I'll be making a tutorial thread on how the system works in a few weeks. Huge thanks to co-conspirators @Abastro and @IncongruousGoat who helped with the math development! If this stuff happens to be your jam, please kick them a like in posts here and here. Thanks! Oh, once again, I'm flagging the good banana mod banana @Vanamonde in case another board is better. I'm planning to make a separate tutorial thread for the actual how-to stuff, but if tutorials is the best place, I can always roll the two threads into one? In any case, let's see where we end up. Brace for warp drive!
  12. @FancyMouse Er, I believe @Abastro was actually referring to my n-variable unbounded case not having a bunch of local maxima is hard to prove. Edit: Missed Abastro's reply, n/m! Fortunately, it seems to have only one max with some beautiful tapering near it in all directions. Solver central! Hey! Speaking of which, the new spreadsheet optimizer is up. Link I'm planning on beautifying and triple checking it Sunday (perhaps Sat) before posting it.... in discussion, I guess? I was thinking to link back here, and also link to prominently your solver when it's ready @IncongruousGoat if you'd like?
  13. Oh... I was wondering how to prove that! My "it's just a buncha things plussed together, shouldn't have local non-global maxima!" seemed a bit hand wavey. For your equation that found the expression that equaled out to constant C for all stages, I'm impressed you found the thing that balances the stages! I'm also happy it didn't have a log . My similar analyses of the n stage equations all hit dead ends at this point with pretty but unsolvable relations, so I'm glad this one worked out. I was starting to give up hope of finding a starting point to launch a heuristic approach, but this would be key. I followed right up to here! I wish I could say more, but I'm impressed with the result. How did you make the constraining equation g = <1,1,1,...>? I tried the old engineers tricks of linearization, and forming systems of seperable PDEs, but it all gets sticky or pretty-but-unsolvable. It's frustrating, because I feel like I keep getting so tantalizingly close. I hope one of your deeper analyses into the specific rocket systems pan out! Anyways, I've hit my head against the analysis enough, I'm thinking I'll try making the google sheet nice enough to post for others to use... Maybe with asparagus stages supported; I have a feeling that the folk who would like a deltaV optimizer are the same as the folk who like them some asparagus! It's all just book-keeping math from here, but would either of you like to join? If so, I'll send the link for the new version.
  14. A continuous number of stages isn't actually such a bad thing- it's pretty much the only difference between the specific-rocket and general-rocket case. The general rocket (where we don't declare a size or anything) doesn't care whether you have .25 of each stage or 1000, so long as the relative number of each stage to the others is known (or a variable). In this way, I think allowing yourself to go ham and declare the number of stages to be continuous is not a bad thing, it should apply nicely to the general case! Unfortunately, like you said, if you don't choose something to constrain the relative number of each stage, the math will just tell you to use your best engine and none of the others. My constraints are stage number ratios that need to be hardbaked into the optimization calculations, but maybe there's a cleaner way?
  15. Good luck, @Ultimate Steve! *nibbles snacks*