ytmytm

Hello I just wanted to let you know that I managed to connect to kRPC using a low cost WeMos D1 Mini board with ESP8266 WiFi chip. The code is an ESP8266 core Arduino project and github repository is here: https://github.com/ytmytm/espkrpc The platform has 4MB of flash and there is about 80KB or RAM available for application so it's not possible to use C++ client provided by kRPC. I use only 20% of the flash but already 40% of RAM, without counting the dynamically allocated objects. Instead of Google protobuf I used Nanopb - a library with low RAM usage, aimed for microcontrollers. Because of this I had to reimplement the services too. At the moment the code in the repository reimplements the script from kRPC tutorial. So I have a device that I can just connect to a powerbank and it will automatically sends a rocket up, to 100km apoapsis using autopilot and brings the Kerbals safely back. I don't know why, but having this as a physical thing that I can hold makes me more happy than using MechJeb :). In both cases my input is minimal. The real reason I had in mind while playing with this was to use it in custom control/display designs. In my KSP Gegi project I used a Python script running on the game host to act as an interface between simple serial commands sent over USB to Arduinos to display something (LEDs, LCD) and back to react on button presses. Using this approach I can get rid of this dependency and keep whole control panel as a one box that only needs power. For current Arduino users - you can also think about it as a KSP Serial IO on steroids. The ESP8266 chip will connect over WiFi to the game and send back any information transcribed to data packet according to your needs.

I agree. Once you get it running is quite easy and very powerful. If anyone is looking for a starting point, please consider my project: https://github.com/ytmytm/ksp-gegi/ There is Python script (gegi.py) running on PC that acts as an interface between kRPC server and serial I/O. It translates messages from the game into simple commands understood by Arduino code - to turn LEDs on/off, move analog meters or show something on LCD. It also translates messages from Arduino side (when knob is moved or a switch changes state) into kRPC requests - to change state of RCS or throttle. The Arduino side is completely independent from kRPC, it's just a driver for buttons and displays, so I could easily debug it using serial monitor by simply typing commands.

I didn't try adding streams ot each part. I took the plunge with C# programming and I tried adding my own RPC. Thanks to your excellent documentation it was quite easy and I'm very happy with the result. Now the status comes back instantly and there is no noticeable delay that could interfere with user controls. When I started with this project I overlooked in docs that it is possible to use 'getattr' as argument for add_stream. Now I rewrote my code to use streams whenever possible and it really, really, makes a difference. This rewrite gave my controller another boost. Now, really the only limiting thing is the microcontroller speed. Thank you again!

Thank you for warm welcome and suggestions! I have visited those threads and I took a lot of inspiration from there. I didn't do many landings yet, but it's clear that a landing mode with this key information will be much more useful than what I already have. Your hint about putting on OLED display deviation from prograde points me in some direction. kRPC exposes a lot of information about vessel position, orientation with respect to various frames of reference. So that would be one mode. Now I'm thinking that second mode would be for docking. I would need some indication about relative speed and if my vessel is parallel to the target. For the next revision I would go with four analog gauges too for power/fuel/mono and G-force. The last one is not necessary for flight at all, but it's nice to have for extra immersion effect. It gives me instant feedback of engine power once I move the throttle up.

This is a control panel that I constructed for KSP. It is a prototype and I still learn what works and what doesn't. On the bottom of this post there is a plea for help and ideas. This is the project's page with build log, more pictures and some extra information how it was built, what I learned over the time and how the very first prototype on a cardboard looked like: https://hackaday.io/project/8891-ksp-gegi This is the project's source code repository: https://github.com/ytmytm/ksp-gegi This project wouldn't be possible without kRPC mod: http://krpc.github.io/krpc/ The enclosure is made out of gutted IKEA LACK shelf and inside there are two Arduinos: one Arduino Micro Pro for USB Serial communication and HID joystick emulation and one Arduino Mini Pro for handling extra I/O. The knobs on joysticks are just wooden pegs. Throttle potentiometer was salvaged from a broken humidifier. Joysticks work without any extra software support - simply as USB joysticks. The status indicators and display data are transmitted over serial port and parsed by Python program that talks through kRPC with the game. Here is an overview of the schematic and connections. There is no proper schematic as it evolved as it was built. Features Status display Analog display of remaining electrical power Analog display of current G-force acceleration felt onboard Warning LED for low fuel condition; will be on if less 20% of fuel remains and blink if less than 10% of fuel remains Warning LED for low power condition (as above) Warning LED for overheat condition; will be on if any part of the ship is heated to at least 60% of its max temperature and blink if it is heated to at least 80% of maxiumum temperature Status indicator LEDs for vessel lights / gears / rcs / sas; green is ON, red is OFF and if the status of the switch doesn't match status in the game then the relevant indicator blinks (for example if I have sas switch ON but in the game it is OFF the green sas indicator will blink) 16x2 LCD display with three modes of action (first one doesn't match the label on the picture): Eccentricity and inclination of vessel's orbit Apoapis + time to apoapsis, periapsis + time to periapsis (orbit mode) Speed and horizontal/vertical surface speed (surface mode) 128x64 OLED display with uncertain mode of action (the switch below has three positions) Current orbit data: horizontal line is major axis, vertical line is minor axis, if the eccentricity is not too high then also an ellipse with proper eccentricity; an additional line shows orbit inclination (like a hand on a clock between hours 12 and 3) I don't have idea for two remaining modes yet, so the switch remained unlabeled Controls Two 2-axis joysticks are presented to the host as one 3-axis joystick with 3 rotation axes, a throttle, a rudder and some 32 buttons. Those analog joysticks have buttons under them but if you push such button then you can't make any accurate moves anymore. So I configured the microcontroller to enable extra axes if button on the opposite joystick is pressed. For example the joystick on the left works as X/Y axis mode if button on the joystick on the right is released or X/Y rotation if it is pressed. Knob for time warp control Knob for throttle control Abort / Stage mode switch for EMERGENCY push button (in a very Kerbal way - make sure that you are in the right mode before panicking to enable parachutes instead of next stage boosters) Mode switch for LCD display with 3 positions Mode switch for OLED display with 3 positions Toggle switches for lights / gears / rcs / sas When not connected to Python interface/kRPC this control panel works like a toy for my 3-year old son. The red/green indicators will turn on and off as expected with toggle switches. The analog displays will move their hands if you turn time warp and throttle controls. And OLED screen will show the position of both joysticks (two dots in two circles, like goggly eyes). It is enough to just connect it to a powerbank. Status What is very nice Switches and indicators are very useful for the game. With two joysticks I can finally do EVA with intuitive control and the RCS control for docking (translation+rotation) is also easy. LCD display with orbit parameters is very useful too, but I should mount it slight angled (it's not very well visible if I don't look straight on it). What is not nice My woodwork is ugly, The labels are temporary. I had no idea how to mount joysticks (this is why one hole is round and the other rectangular) and the wires inside are a mess. What doesn't work (HELP!) That OLED display has 128x64 pixels, the top 16 rows are yellow, remaining 48 rows are cyan. In my code I wrote a simple graphics interpreter so I can send from Python interface commands like "draw line from here to there; put pixel here; draw a frame from here to there" etc. There is also possibility to put text on OLED, but it works too slowly and I would avoid it. At the moment I simply have no idea what kind of information to put there. The information must be useful for space flight, should be graphical in nature and must fit on a tiny 128x64 (16+48) screen. I put a 3-position switch under this display so there are three modes of display possible.

Thank you for this great mod. It made my custom KSP controller actually possible: https://hackaday.io/project/8891-ksp-gegi This is a bunch of controls and displays connected through two Arduinos (Mini and Micro) to USB. The source code for both controllers and python interface code is here: https://github.com/ytmytm/ksp-gegi Without much thinking I put there a warning light for overheating. Only later I realized that it's not that easy to find out if there is any part of the ship that overheats. Right now I do this: self.temp_pct=max([max(part.temperature/part.max_temperature,part.skin_temperature/part.max_skin_temperature) for part in self.parts]) So I have to go through all parts of a ship to find out what is the maximum of ratio of current temperature of a part to its max temperature. Then if temp_pct is above 60% the warning LED is on and if it is above 80% it blinks to attract attention. It's OK, right now this works. But is there a better way? It takes so much time that I had to move it to a separate thread, otherwise displays and user controls would be blocked.