artwhaley

Members
  • Content count

    503
  • Joined

  • Last visited

Community Reputation

370 Excellent

About artwhaley

  • Rank
    Sr. Spacecraft Engineer
  1. Well, I hold alt to make a named save occasionally. It's only happened twice. But still. It could have been anywhere else. Or... they could have NOT used alt as the modifier for named saves! And yes it's totally rebindable. I'd done so after the first time it happened, but when it happened again the other day I had to make a snarky forum post to work out my minute bit of rage. It did NOT save to persistent.sfs in that instance though... so the cool thing I was sure I could only pull off once was lost and sure enough... I could only pull it off once. Whatever it was.
  2. And found it, I think - I'm going to link in the code here for those that come after. I converted them to radians and shifted the AN and DN properties to +-pi so they'd be in the same number space as the anomaly properties. Thank you so much for the help everyone! //AN var degrees = FinePrint.Utilities.OrbitUtilities.AngleOfAscendingNode(InternalOrbit, target.Orbit.InternalOrbit); if (degrees > 180) degrees -= 360; return Math.PI * degrees / 180; //DN var degrees = FinePrint.Utilities.OrbitUtilities.AngleOfDescendingNode(InternalOrbit, target.Orbit.InternalOrbit); if (degrees > 180) degrees -= 360; return Math.PI * degrees / 180; //Inclination var degrees = FinePrint.Utilities.OrbitUtilities.GetRelativeInclination(InternalOrbit, target.Orbit.InternalOrbit); return Math.PI * degrees / 180;
  3. The second one DOES look promising for finding the angle between the planes! Thank you! I'll try it out, though I'm still looking for how to find the longitude or mean anomaly or time of the intersection.
  4. I'm working on adding a couple of methods to KRPC to enable automated rendezvous and now need to get the data required to match planes. To me, this seems like I want the relative inclination and the mean anomaly or true anomaly of the AN/DN? I, as I always do on these sorts of questions, took a look at the mechjeb orbit extensions (which ought to all be added to the stock orbit class!) but before I go once again implementing half of that file all over again for myself, I thought I should ask if there was a simple way to get just what I need to enable a user to match planes out of KSP?
  5. If it's a design I'll use more than once I write a KRPC script to manage abort modes. For example on a shuttle launch when it detects an abort it might - Do nothing but lock steering to prograde as long as SRBs are burning, then Separate the SRBs. Decide based on altitude and thrust whether it's an Abort To Launch Site, Abort Down Range, or Abort to Orbit Inform pilot which abort to fly and put range and altitude markers on screen for selected landing site, or fuel and orbit stats for ATO - release steering to pilot For a station I might run an abort script that sees the action group and separates the command pod, orients it retrograde, and deorbits then eventually triggers parachutes all on it's own. I think that writing software for rockets is as important and fun as designing the hardware in the VAB!
  6. Putting the keyboard shortcut for saving after a difficult maneuver right next to the windows default shortcut for 'exit without giving the program time to update the savefile' seems like something that deserves a bit more thought?
  7. The source must be visible, so it can be peer reviewed for malicious content. That is not the same thing as available for reuse in any way you don't have specific permission (license) for. The person that types it still owns it and decides who may use it for what, and has the right to pursue legal remedy if the license is violated, even if that seems unlikely to be worth the trouble. It would still damage your reputation and the good will of the community. Intellectual property is property none the less. Wonder if NASA has given any thought to whether they can use Mechjeb on real rockets?
  8. I was amused enough that I just went ahead and added this to my KRPC script. I've got a few more things to do before I make another pull request but you can get the version on my fork at https://github.com/artwhaley/krpc-library You'll need to download the rover.py and the pid.py files and then in the same directory you'd create your script. You don't have to understand everything in the rover or pid files to use it. You just need to make a script that will call the functions. As an example this script could look like: import krpc from rover import rover_go conn=krpc.connect() ## connect to KRPC ## next create a waypoint. Replace the coordinates (0.05, -75.0,) with the lat and lon you want to drive to wp1 = conn.space_center.waypoint_manager.add_waypoint( 0.05,-75.0, conn.space_center.active_vessel.orbit.body,"Waypoint1") rover_go(conn, wp1) #call the rover script. ## the rover script will then do it's thing, recharging when battery is low and autosaving every 5 minutes ## if the situation looks nominal enough.
  9. I wish I knew Wings3D enough to help! Surely someone will wander along? It's also a generic enough to the program question you might ask for help in a Wings3D forum - someone will be able to get you started unwrapping. It sounds like you're probably just missing a keyboard shortcut or something similar to deselect.
  10. Or KRPC. Here in the new script library you can see my rover autopilot example. It brings the rover to a stop every 5 minutes and autosaves (but DOESN'T overwrite an autosave if it detects the rover is tipped or stuck... so you always have the last 'good' save). It would be an easy thing to add a function to check EC and do a stop and deploy until the EC was back above a threshold. If you decide to go the KRPC route I'm happy to add that function in for you if it seems to do everything else you want. My experience with mechjeb's rover autopilot - if you try to apply the brakes while the autopilot is engaged it immediately disengages them and accelerates again - so any mod you want to use the way you've described is actually going to have to turn off the mechjeb autopilot and then reengage it, if you're using mechjeb to drive. That's not a hard thing to do if you're making a mod from scratch and if you get everything else ready I'll show you how to do that with reflection. Is this within the realm of mechjeb's new scripting module? I haven't played with that. Anyway - the link to my KRPC demo folder is: https://github.com/krpc/krpc-library/tree/master/Art_Whaleys_KRPC_Demos
  11. Also, Mechjeb has an option to display these bits of data... and a lot more. I can't remember in which window you turn it on, but it's got a LOT of in flight markers if you want to also show thrust vector, angle of attack, error from commanded heading, etc!
  12. This looks fun! I've got a start on a ksp simpit myself that is going to be 'big' too! But mine gets stalled as i get distracted. My daughter's only a year old though, so it'll be up and running before she's old enough to enjoy it with me! I'll look into lawnmowerlatte's python to arduino bits - I am working on an example repository for KRPC scripts, and was going to do a KRPC to Arduino example using pyserial to get the data out via my own protocol, but seeing that someone's already done a KSP specific version here, I will do some research to see if I should be using it instead for the example. My criteria for deciding that, and the criteria I'd recommend you use for deciding if you're using it is the overhead. I think more than the python loop slowing you down, the baudrate of the serial connection to the arduino could be your bottleneck. There's no reason that pyserial couldn't be talking to two different arduinos, but without looking at lawnmowerlatte's code I don't know if his system is set up to make that easy or not? You can absolutely connect multiple python (or other language) clients to one KRPC server instance at the same time, so hypothetically you could have two different python scripts, each pointed at a different serial port and each grabbing or passing different data via KRPC, which would be one way to make your application 'multithreaded,' and tighten up each of the loops to minimize lag from the serial connection or python interpreter execution? Having the most efficient protocol possible and putting the processing jobs spread out between the various processors is going to minimize your lag the most. Instead of polling buttons in python, it would be better to have the Arduino do that and have it send them as efficiently as possible to the python script... for example as a bit mask, so it would only take 2 bytes of serial data to pass in 16 button states? Plus the libraries and techniques for debouncing and such are well established for Arduino. I've never played with true multi-threading in python, but it exists- so it would also be possible for you to move communication to a 'background thread' and use what you'd consider the 'main or foreground' loop to do higher level processing? There's also the possibility of hitting a KRPC bottleneck too... if you're trying to pull A LOT of data out at a high rate. I know that setting a refresh rate for streams is something that's on the long term plan for KRPC but I don't think that feature is actively being developed. I think compiling a list of all the data you want out of KRPC is a good first step, then assigning a realistic 'minimum polling rate' for each of those fields - you may need orientation data as fast as you can get it, but you probably DON'T need lattitude and longitude any faster than once a second- from this 'prioritized list' we can figure out the most efficient way to communicate with KRPC - what items should be retrieved via a stream and what should be retrieved via repeated polling. My advice on pretty much ALL of this is keep soldiering on without it... until the lag becomes a problem, and then let's figure out where it's coming from and how to open up that bottleneck. Glad to see you working on this!
  13. Yes, Djungelorm is way smarter than me, but I try to contribute fixes when I find a problem! I ALSO found (find, but have stopped complaining aloud about it) the indentation instead of just using parenthesis all willy nilly to be frustrating at times, though I am STARTING to understand the beauty of encouraging people to all write code that essentially 'looks like python' by doing it that way. But still. Having a program refuse to execute because there's an extra space at the beginning of a line is annoying, right? ((Okay, I apparently still complain aloud a little.) Yes, Pyserial is the way I'd probably pass things to the navball too! At the moment we're working on getting a repository of KRPC example scripts built and perhaps I should do a Pyserial example that shows how to push some data to an arduino? I'll think on that! It's here https://github.com/krpc/krpc-library if a couple more examples are useful to you. Definitely let me know when you get stuck! The example I posted above should pass out the data for one navball if you replace the three print statements (or augment above or below them) with the Pyserial command to send your data however you'd like!
  14. I'm glad to hear you got the KRPC code working! I should have provided more info sooner! That was example code in Python that would run on the PC in a Python interpreter - and then you'd add to that last while loop code that used a python serial library to push either raw data or processed motor movement commands out to the arduino. But it sounds like you've got it working! Also, I had very similar code using telemachus ages ago! I was running it on one of the TI Launchpads that has built in ethernet and a whole BUNCH of IO pins. Never got around to finishing the cockpit... but it'll happen eventually. And when it does I may well build one of your navballs! I've been wondering about getting KRPC working directly to arduino? There is some work being done on getting the google protbuf library to compile for microcontrollers, which would be the big hurdle to jump I think... though I think the project would be a bit over my head. But it's so easy to make an arduino talk to an intermediary program, there's no real reason it has to run natively on the arduino. Something I MAY work on is building a raspberry pi distribution that has python and krpc and some scripts for various ways to display data all prebuilt so you could just write it to an sd card, and if you wanted physical interface perhaps edit a .cfg file to map buttons or indicators to the GPIO? But I digressed! If I can help any more with the KRPC side let me know. I'm fairly familiar with it!