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.