PeteWasEre

@Gameslinx Many thanks!! Much appreciated.

Hi Just wondering if anyone can help me out, on Armstrong the Highlands biome is not appearing. Using scansat to find my way around and the 4th biome is nowhere to be found. The strange this is i know i have collected science there in the past but that was prior to 1.4.0 update, has something changed? I can see it in the DDS and definitions, but it seems to be mixed up with the others and one has been lost. Note this is NOT a clean install, it has a bunch of mods. Just wanted to know if anyone had seen this before i go checking in a clean install. If not i will confirm seperately and also try to correlate to the DDS. P.S. I was going to park KSP until KSP2.. then i found this mod. Kudos to you, this is insanely good!

Great work! You really went all out on the features! I especially love the battery well idea, pure genius, that's straight to the top of my to-do list... I have given some thought to a Due upgrade too, a big reason i scrapped my autopilot panel was the lag on the mega or a comms mess to process on the PC. The level shift always put me off though as you miss one 5V and zap.... guess it just needs some care and patience! Might have to reconsider that too. The python lag is a problem, and i don't see a way around it without changing to another client language, probably C# which i have 0 knowledge of. I did though spend a LOT of time bench marking parts of the code to find the delays and rewriting sections to improve performance. If you are self taught in python like I am then its amazingly easy to write effective but inefficient code! I will have to take a look at your code as i have often wanted to have a 'fast' and 'slow' split so i can focus on time sensitive things like controls and camera. using KSPserialIO for the fast is a good idea to consider. Love the shiny look! If you are planning to add labels near switches i have had great success on metal with rub on 'letraset' style lettering for my guitar amps. They are hard to find these days but with patience and a quick coat of spray clear gave a really nice look and worth a search. Cant wait to see this evolve! And many thanks for the nod kind sir

Yep, retested with the 0.3.7 build and all appears ok! Thank you!

Hi The behaviour appears to be exactly the same after installing the latest dev build

Hi @djungelorm Just getting back into this after some real life intrusions! Thanks for the dev build! I am noticing a couple of issues now compared to 0.3.6 on 1.1.3. I am running the latest dev build and python has been updated using the PIP instructions you provided in a previous post. Firstly, camera mode query is throwing an error. >>> import krpc >>> conn = krpc.connect(name='Game Controller') >>> vessel = conn.space_center.active_vessel >>> cam = conn.space_center.camera >>> cam.mode Traceback (most recent call last): File "<input>", line 1, in <module> File "<string>", line 1, in <lambda> File "C:\Users\petern\AppData\Local\Programs\Python\Python35-32\lib\site-packages\krpc\client.py", line 88, in _invoke raise RPCError(response.error) krpc.error.RPCError: Field '.MapView.MapIsEnabled' not found. Second, i am struggling with propellants, as 'total_resource_available' and 'total_resource_capacity' give errors. >>> y <SpaceCenter.Propellant remote object #56> >>> y.name 'LiquidFuel' >>> y.total_resource_available Traceback (most recent call last): File "<input>", line 1, in <module> File "<string>", line 1, in <lambda> File "C:\Users\petern\AppData\Local\Programs\Python\Python35-32\lib\site-packages\krpc\client.py", line 88, in _invoke raise RPCError(response.error) Can you let me know if these are related to changes in the latest versions, or if they are bugs? Cheers Pete

Yep, I think you really need a PID approach. In my simple understanding before pulling out the old text book.. Delta Y control = C1 x E + C2 x Integral E dt + C3 x dE/dt where E is the altitude error. As i understand it, which is not saying much yet , the differential term is what will actively help to stabilise you here as you approach the target altitude. The integral term is what then manages small errors as they build up and the proportional term dominates at first when you are far from your target. You do need to do some tuning, but there are known methods. Ziegler–Nichols is a common approach and seems manageable, at least on first reading.

@Freshmeat My initial thinking is to make an AP mode that targets a rate of climb or descent. The PID in my case would give my a delta pitch that i can then modify my target pitch with to give to KRPC. If you are trying to calculate elevator position from the error i can imagine it would likely be unstable. A PID should give you a delta control to apply, which takes away the need to calculate the settling point. It should settle where it settles when your delta goes to 0. If I can do that then altitude hold should be a function of target ROC vs delta from altitude. So if I am within 100m, 0, and increasing from there. Thats the theory anyway.... will let you know how I go! Oh now you have me thinking! In the pics above i have a 3D orbital view... if I can do that, why cant I do a navball! Its just a rotating sphere with some markers on it. Thats going on the backlog... thank you! Bye bye frame rate though..... thats going to take some calculation!

@djungelorm Thanks 1 and 2 sound nice as they would give user flexibility to configure as they like. If it's not too much to ask that would be a nice help. For 3 and 4 I completely understand, no need for sorry! It makes way more sense for you to work on things we cant do on the client side (like more API interfaces, oh what goodies will that bring!) than things we can. I only wish I was skilled enough to make that pull request! I am already thinking of ideas to get faster response, a seperate python AP process or maybe the KOS bridge. It will be a nice challenge for me. For 5 i haven't played with the parameters yet, but will do. I did read #310 and got confused very quickly... my control theory classes were almost 20 years ago... I will see how I go with those. However my thinking came from real A/C autopilots that generally dont have full control range. In RL this is more to do with safety, so the pilot can always pull up more than George pushes down, but it might help here. Will let you know how I go. Thanks again! Pete

I am serious, and don't call me Shirley! ah that movie never gets old! Thanks The buttons are right off eBay, caps and all. There are a bunch of vendors selling them, all in from China which means long delivery but you can't argue with the price at a buck each. The feel is nice but careful with solder temp as they are not super robust. The pin spacing is not quite 0.1" so it took some plier work to get them in, along with a good shove, then more fiddle to get them straight in the holes. There are heaps of styles of cap available (they just clip on) and colours also, and the LEDs are super bright. I had to add resistance to tone them down a few times. Here is a link to one - http://www.ebay.com.au/itm/331584970800?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT @tjsnhThanks for the praise! and if only it were that easy... there is probably $300 in parts in this now, and hundreds of hours. Without going to a production version its just not viable as it would need to be $1k to make it worthwhile. With mass buy of parts, proper PCBs with SMD parts the cost would come way down, but I don't have the skills to do that. However the build is the most rewarding part. I think a lot more people can do this if they just have a go, and heaps of people on here will gladly help answer questions or provide guidance to get people started. I will get to that intro tutorial for a basic HW throttle up as soon as RL stops getting in the way! Once you have one control working the rest is cut, paste and adjust. The rest is a housing but it doesn't have to be fancy. One guy on here made one out of craft sticks, and I have made a guitar amp that's based on a cake tin before! @Freshmeat I'm tryin' Would be curious to know what approach you used. I spoke to the KRPC Dev and he has no plans for higher level modes, so I need my own PID to turn altitude hold into a pitch command to give to KRPC's autopilot. I suspect similar issues when I have one PID driving another, and my control theory classes are approaching 20 years ago!

Hi @djungelorm I have been playing with the Autopilot now that I have a nice hardware panel for it, and I have a few ideas, suggestions, misunderstandings and general mayhem type things that mostly come from me being rather ambitious 1. Is it possible to separate the lateral and longitudinal modes? I went for a typical A/C setup and its normal to have Lateral, Longitudinal and Speed as 3 separate modes. So for example you can enable 'Pitch hold' but heading / roll is still free for manual control. In the current KRPC implementation it can only be on or off for both Pitch and Heading. 2. Would it be possible to allow the use of the roll target without heading? This enables a typical 'hold bank angle' mode of A/C and you can fly visually just change bank set. Currently you have to set a heading I think, but I want to have no heading target, just hold bank. 3. Any thoughts of adding an auto-throttle controller? I imagine the same PID approach should work but may require different tunings to respond to different engine spool up times. If you could also specify a velocity vector for it to target, and you give it vertical we now have hover hold and gentle landings too! 4. Any thoughts of adding higher level modes? Altitude hold, Rate of Climb hold, ILS maybe (glideslope and localiser), waypoint guidance etc. I know some of these, in fact all of these, could be done by driving pitch and heading, but if that is in a slow python module then i suspect osculations of two controllers talking to each other. 5. The autopilot, at first test really didnt like my high manoeuvrability fighter Massive overcontrol but it seemed the autotune didnt dial it out? it was persistent. Only reducing the control authority of the surfaces stabilised it. Would like to know your thoughts on limits of autotune, or if that really is the case could we have a control scaling factor? Say i let the AP have 25% of the control authority so I can still fly like a nutcase if I like? Thanks! Pete

I have an Autopilot Well I have a working panel at least, still working out how to drive KRPC autopilot but it does fly and follow commands. The ghosting in the first pic of the LCD is me being too slow with the camera, its just about to change! (If you get the reference you are showing you are as old as me ) The panel was a lot of fun to make, and quite different from the others. Physically I previously used panel mount HW everywhere but this time the switches were board mount so i had to make and mount boards to hold it all to the panel, and that meant more visible screws on the front but the black hex heads look ok so I don't mind. The only frustrators are that the graphic printed in a slightly lighter grey (printer settings i think??) and I couldn't get the power button cap in silver or the others in black. Minor annoyances to tease my OCD only. The LCD was also a difference but so damn easy to integrate I am wondering why i never used them elsewhere. Just hook it up and go, though the Liquid Crystal Library is very slow and causes an overrun at each screen refresh which is only on user input, and at 40ms its still ok. With the blue LCD and the blue lit switches I think it looks quite nice! Balancing the LED levels was a bit fiddly though, and chewed up a lot of resistors. All the lights in the switches and the LCD itself are linked to the main dimmer knob so they dim really nicely with the rest of the panel. LCD contrast is a pot on the back though, i tried a LP filter approach but it didnt work so I went old style. It shouldn't need to change much, only drift with age. The code is a bit more extensive than usual as i am handling all the switching on the Arduino end and only transmitting the final result to the Python code to avoid lots of data transfer. This was compounded by the 3 axis approach I am pushing for and that I want to be able to select the next setting whilst the first is held. This took me back to good old C Structs and lots of arrays but they worked really neatly. So in the photo you will the Lateral axis is on and set. In the vertical axis I am preparing the next mode and I can change this as much as I want until I am happy then press 'Set' and it will lock in and look like the lateral mode, or cancel to go back to the current mode setting. Finally the speed setting shows you what happens when the axis is off. The master CANCEL will turn off all 3 modes for when it goes pear shaped.... Its built so that each axis can just add modes to a struct with their own min/max, multipliers (so I don't have to change altitude 1m at a time!) and with individual prefix and suffix for units. I can just add them whenever I like. Transferring to python was fun as i had to split INTs into multiple bytes and then recombine, and the out of the box doesn't handle negatives well! A custom function fixed that and now it works nicely, and the focus is working with KRPC to understand how it tunes gains as my first trials oscillated... a LOT. It seems to not like fighters with massive control ranges.... shame I do. Nice thing is though you can overwrite the AP with the stick still and then let go and it takes over. I am still working though the docs, the schematics are done but the design doc now needs updating. The plan from here is: 1. Get way more AP modes, will need to work with the KRPC dev to get this going 2. Implement a queue for cautions and my new clear caution button (Cautions should flash at first till cancelled). 3. Keep working on the Python GUI especially for atmospheric flight and rovers. 4. MOAR DOCUMENTATION! 5. Migrate to 1.2 and all the joy that upcoming KRPC builds are promising 6. Play KSP! Till next time! Pete

That makes me wonder that it could be a nice intro tutorial for people who want to get into HW panels. I see a heap of comments on all our simpit threads about people who love the idea but dont know where to start. I am tempted to write something up, if there is interest I can then add more to it. Might have a crack this weekend if I have time.

You could try dry transfer lettering, sometimes called rub on lettering or used to be branded Letraset. Its not that easy to find but there are a few supplies on ebay that have a range of fonts and sizes. I have used them before to label the front panel of guitar amps and the results were excellent if you take your time to line up the letters and dont rush. Now that i think of it I am wonding why I am not using this for my indicator lights!!

I haven't used KRPSerialIO so i can't offer a comparison, but I can say that as a noob to this style of programming (I have a real time C on UNIX background) it was pretty easy. The KRPC documentation is good, the author is always happy to help answer questions, and it gives you the freedom to choose a language you like. Heaps of examples exist in the docs and online. There is a lot of information available through the interface but so long as you plan out and manage your data transfers performance is ok. Minimise calls and use streams for repetitive data transfers. The only bit that did my head in was the reference frames, but this is a maths and geometry issue more than a KRPC issue! @ryan00793 if you want to see the KRPC python code or the Arduino ino you are welcome to take a look on github, or hit me with questions.

@Wabbit Yep, stick on dry erase. A roll of more than a meter cost a few bucks on ebay. Works a treat. Oh and by far the nicest fine control is the throttle. Powered landings are soooooooo much easier now. I can hover at will.

@Wabbit Thanks! The controls take a bit of getting used too, but once you have the muscle memory and dont have to look for switches it feels the same or better. It feels more tactile than the keyboard. You do move more (which probably isnt a bad thing ) and while it wouldn't work for a fast paced game for KSP its fine.

Houston, we have progress! Its amazing just how much time this takes. A few days surely and it would be done right? only out by a few orders of magnitude.... the problem is I think of new ideas faster than I think of solutions... On the panel HW I tidied up the dimmer knob and the light boxes. Basically its done but I will wait to put the decals on the lights as I might change the function of some of them. However I have started cutting the Autopilot panel that you can see in the lower left of the panel image. The big rectangle is to hold the 40x2 LCD display that has also arrived (more on autopilot later) and works, proving very simple to hook up using the Arduino Liquid Crystal library. I now have to wait for the buttons to arrive as there are 21 buttons to go in to the lower area! I found some nice buttons with blue LED markings so it should look 'spacey'. A lot of work has been going into the GUI SW. Getting the text going was easy enough, even the tabs with variable data like the rendezvous tab that can switch targets, or the systems tab that shows resource lists. Getting the plots going though was challenging! I started with the Launchplot based on some excellent work i found from Github user marioferpa and have since done a lot of tweaking. The orbit plots are all new work and the 3D view to get the angles right really stretched the mental muscles! They work mostly well, they don't like highly eccentric or hyperbolic orbits though, that will take more research. I made it so you can show either orbit plot, or both, so you can get a larger view and to ease load as rendering the #d plot is expensive. Need to optimise this part, with both plots is over 250ms, which with a 250ms frame rate is annoying. With no plots its 35. So i need to do some work on the remaining tabs, but areas like the resources and temps on the systems page, and the runway ILS data will need KRPC updates to finish. Also the GUI does not handle vessel switch or scene switch well, that needs some further investigation. I also made it so the GUI can run without the panel, so even when I am KSP'ing the old school keyboard way i still have my data The autopilot concept is taking shape in my head. 3 axes; vertical, lateral and speed. I want to divide the LCD up into 3 areas and show the mode and set point for each axis. For example for vertical modes will be pitch, altitude hold, rate of climb, and for lateral mode heading, bank angle and if i can get waypoint info then that too! Speed mode is only hold, except i am thinking hover mode for landers too? For each axis i will have 6 buttons: mode up/dn, setting up/dn, set and cancel. Then a master power, engage and cancel button. The beauty of this architecture is that i can just add one mode at a time as i figure it out. Documentation is progressing. The Arduino code is fully documented now, but the python side will probably wait till i nail the architecture a bit more. More than anything i need to actually PLAY KSP, rather than code, to find more bugs! Cheers Pete

Ok, its a liveware problem! I followed it back to the declaration and for some reason its picking up the remove method from builtins, not the remove method for the stream object. It only happens where i have a list of streams i am trying to iterate through. If I work on a stream object directly, even if it is an element of a list, no warning appears! In the code the first part gives a warning, the second doesn't. However i think the warning is false as the code correctly closes the stream so its all good. for x in list_of_streams: x.remove() list_of_streams[0].remove()

Hi @djungelorm Thanks for those responses, they all look great! A quick minor thing that might be a bug. I am trying to dynamically open and close streams of resources but in PyCharm the stream.remove() method is requesting a mandatory parameter 'x', It comes up as method remove(self,x) and gives me a warning if i dont give a parameter. Note it works fine without any parameter, but my CDO (its just like OCD, but with the letters in the right order!) forces me to remove all warnings. Cheers!

Oh, I forgot one! I am getting strange readouts for orbit.inclination. I am in an equatorial orbit of the Mun and MechJeb pins my inclination at 0.15. However KRPC is reporting vessel.orbit.inclination as 2.88 radians, or 165 degrees. Other orbital parameters completely align with MJ. Is this a bug or a liveware problem? Cheers Pete

Hi @djungelorm I've been working away at my GUI and have some questions and feature ideas I'd like to raise. 1. Part temps - I note there is an open issue on KOS related to adding part temps so currently that's not an option. I also spent some time reading on how to extend KRPC and came to the conclusion that with zero C# experience its not a wise approach for my blood pressure. Therefore could I request something around max temps be added? Not sure what forms it should take yet but what I am really interested in is the part closest to blowing up. Some thoughts are: Return the n hottest parts and their associated max temps Return all parts that are above x% of their max temp Though I wonder if you can stream something like a list of 'parts'? I guess you can only stream attributes? There is probably a few ways to approach this, the end result is I would like to show say up to the top 5 parts closest to melting and the % of max temp 2. Rendezvous Data I am trying to replicate some data I currently get on MechJeb, or via the map view, in my GUI. I can see how I can get target vessel orbital info, relative velocity and position etc. However I cant see how to get intercept data? Specifically I am thinking closest approach distance, time to closest approach, relative velocity at closest approach etc. That is, the interaction of the two orbits. Is this possible? 3. DeltaV So I can get a total vessel deltaV but I am struggling to get it per stage. Resource and ISP per stage is ok, but mass is hard. For the current stage its ok as I can subtract the resource mass I will use up from the current mass to get my empty mass (or close enough, I wont eat that many snacks during a burn!). However I cant see how to do this for future stages without summing the mass of parts_in_decouple_stage and subtracting from the current mass and imagining what resources are gone etc. If we can get 'Mass in decouple stage' using the cumulative flag = True it should work for the start mass and the end mass is again based on the resource burn. Possible? 4. Waypoint data In the game you can set Nav waypoints, and I would love to be able to provide guidance to those in my GUI. It will also help later as I want a Nav mode for my autopilot. Is it possible to expose the waypoints? I am mostly interested in reading them but I guess setting would be useful too. Thanks! Pete

Have a look at ULN2803 Darlington arrays. They worked a treat for me to run 12v lights from a 5v signal, and they are designed for either 3.3v or 5v. Simply connect your output (straight from the arduino or a shift register) to the 'base' input. On the other side your 12v goes to your lights then to the 'collector' input of the array and you have instant switches. It also has a common which is meant for flyback diodes if you are powering motors, but put it through a switch to ground and you have an instant light test button. Also if you want to dim the lights you can add another NPN between the ULN2803 and ground and run a PWM signal to it. However beware that this will then require diodes between your signal and your darlington array, otherwise it will power back through your arduino! I have a schematic here if it helps: Docs Repo

Hi All Status update time. All the functions of the controller have now been implemented and the HW oops's have been removed. The panel is essentially fully functional now. 'Controls Not In Agreement' logic has been implemented to prevent inadvertent switch errors on vessel change (what do you mean gear was up!?!?!?!) and it nicely uses the print on UI features of KRPC so it looks natural. Vessel and focus switch turned out easier than i though thanks to the wonders of Python List comprehension! They are embarrassingly small lines of code now. A lot of bugs got squashed in the process and now I am down to a lot of out there cases that are due to the nature of KSP. Like using LOX tanks with only Liquid fuel for an air breathing engine shouldn't give fuel warnings. The lego nature of KSP makes for a lot of variation! Still it has forced me to think a lot and some elegant solutions evolved! A LOT of work then went into optimising the Python code. I moved the Python / Arduino relationship from serial to parallel but the real killer was the number of RPCs I would execute. However I just cannot express how awesome KRPC streams are. Set them up once and they pump data to you at no cost. So temperatures, resources, gear states etc are now all streams, and this made the output processing so fast (<1ms instead of 50-100ms) that paralleling the arduino was pointless. Python is waiting for the arduino now at that point. Removing a lot of dynamic building of lists for static items also helped, and when needed are refreshed on staging. A nice part of the streams is that they don't die if a part is lost so my crashing the ship doesn't crash the program. The python module now runs under 60ms mostly with the odd spike that i cant control. It's enough. I also started the graphics side which runs as a separate process. After an epic and painful journey through all the python GUI addons that i couldn't get to work (i'm looking at you GTK and WxPython!) , I am back at good old TK. Its boring but it works. Basic functionality of message passing and data sharing is done, and I can show panel and game data on the screen, so i can now proceed to build the rest. And finally I have started documenting this by drawing up the schematics. They can be found in my github repo If they help anyone else then they have achieved their purpose. My current todo list: 1. Finish the HW - graphic touch ups, labels for the indicator lights 2. Continue documentation 3. Continue Python graphics 4. Bug squashing 5. Keep working on the Atmospheric Autopilot module and panel design. 6. Figure out Github better so i dont track everything in Excel! The main system element will get a boost again when the next release of KRPC comes out as it has a few fixes and features i need to continue. Till next time, be good to your Kerbals. Pete

@Malekal237 I have placed all my current code and documentation on Github here: Github Repo. I plan to update this frequently as my system grows. Hopefully it will work, I am a Git first timer. If it doesnt work let me know, and if something doesnt make sense I am happy to answer any questions! Pete