nathangray

Looks like it has the needed information available.

I'm not sure about the source of the lag, so I'm open to ideas on how to narrow it down. A comparison with the web interfaces shows about the same delay between operating a control and the on-screen response, so I'm leaning toward Telemachus or KSP itself. Here's a snippet of the debug while quickly changing the throttle from max to off: {"t.universalTime":17020.1764956399,"f.throttle":1} Sending data: {"run":["f.setThrottle[1.000]"]} {"t.universalTime":17020.29649564,"f.throttle":1} Sending data: {"run":["f.setThrottle[0.367]"]} {"t.universalTime":17020.29649564,"f.throttle":1} Sending data: {"run":["f.setThrottle[0.015]"]} {"f.setThrottle[1.000]":0,"f.setThrottle[0.367]":0,"t.universalTime":17020.41649564,"f.throttle":1} Sending data: {"run":["f.setThrottle[0.000]"]} {"f.setThrottle[0.015]":0,"t.universalTime":17020.53649564,"f.throttle":0.367} Sending data: {"run":["f.setThrottle[0.000]"]} {"f.setThrottle[0.015]":0,"t.universalTime":17020.53649564,"f.throttle":0.367} Sending data: {"run":["f.setThrottle[0.000]"]} {"f.setThrottle[0.000]":0,"t.universalTime":17020.65649564,"f.throttle":0.01499999} {"f.setThrottle[0.000]":0,"t.universalTime":17020.65649564,"f.throttle":0.01499999} {"f.setThrottle[0.000]":0,"t.universalTime":17020.65649564,"f.throttle":0.01499999} {"f.setThrottle[0.000]":0,"t.universalTime":17020.65649564,"f.throttle":0.01499999} {"f.setThrottle[0.000]":0,"t.universalTime":17020.65649564,"f.throttle":0.01499999} Sending data: {"run":["f.setThrottle[0.000]"]} {"f.setThrottle[0.000]":0,"t.universalTime":17020.77649564,"f.throttle":0} Messages to Telemachus start with "Sending data:". You can see that Telemachus does not immediately respond with the correct value, but that it takes a bit, even though it acknowledges the change in its response. On the other hand, the flag waving at the launch pad is not exactly smooth right now, so system load might be an issue... To be honest, I did it just to see if I could. There are two other things I'd like to try now. I have one of those emergency stop buttons, and I think I can get a fully self-contained abort button. I'd also like to see a remote docking control.

Using an ESP8266 and Telemachus to create a WiFi Kerbal controller. I'm mostly focusing on buttons here, since tablets work great for display. Currently just a proof of concept, it connects over WiFi so you're no longer tethered to one computer. Source and a compiled binary available on Github

It's been a while, but I see you're working with a Teensy for your navball. Is that working with Linux (64 bit), or are you doing that on Windows?

Tried & failed, with no good messages in the debug log. It seems to start working, and the log says it's connecting, then the hardware reports connection lost. The LEDs seem to blink, then immediately turn off. Connecting on Ubuntu at 38400 baud

My controller is still in prototype stage. I'm not sure it needs to get farther... I'm using openbeam for the frame, aerospace-grade cardboard, and various leftover bits from other projects. This controller features audible alarms for things like low power, and the Quiet! button is for ignoring them. The buttons light up to match game state, I'm using these ones: https://www.adafruit.com/products/1439 Under the missle cover is a momentary switch, so I just push it up for stage, then flip the cover down to prevent accidents. The joystick is for the camera. Big thanks to zitroen and marzubus for their work on KSPSerialIO: http://forum.kerbalspaceprogram.com/threads/66393-Hardware-Plugin-Arduino-based-physical-display-serial-port-io-tutorial-%2817-Dec%29 When Telemachus gets updated, I hope to put my tablet in the top and use it for all the displays. Code is available, if anyone's interested. I'm still looking for a good joystick for actual flight.

Thanks marzubus, I had a quick test on ubuntu 14.04 with some jumper wire, and the simple tests seem to work.