KAPCOM

This project is not dead. A lot has happened since I last posted (most notably a new baby!), but I've recently obtained access to a 3D printer. I've wanted to print the throttle for my controller, so that seemed like an obvious choice to print it. After a couple of prototypes and a couple of redesigns, it's coming along nicely. It's a 7 part build that includes a chassis, a cover, two control arms, a handle and two end caps. The Vex potentiometer fits right onto struts I built into the chassis, so it's mostly tool-less.

I'm still waiting on one part and I have to re-print the handle with a bit more spacing. After that I might take a crack at printing  the body panels for the console rather than trying to cut plexiglass.

Many thanks to Josh who provided access to the 3D printer, help with fixing my models, advice on printing and the idea to use two arms.

It's been a long time since I've updated, so you could be forgiven for thinking this project is dead. It is not. My personal life has been demanding and I haven't had the time or inclination to work on this. Part of that was hitting a wall with the enclosure. I felt I lacked the skills to pull off an adequate DIY enclosure and I lacked the funds to buy a pre-fab one. I really liked the Retex Abox series, even though they are a bit small. I considered splitting the project into a controller and display, but the cost of buying the boxes would be absolutely prohibitive.

In all honesty, I was feeling quite down about the whole thing, until I found another project's blog. I really liked the design, modular layout and rather simple construction. I finally felt like I had a path forward. I reverse engineered his design and mocked it up in SketchUp. I really like it and I think I can do it, wish me luck.

Hey, just a brief update that neither myself nor this project is dead. Summertime's busy and I've been having very little time to work on this or play KSP at all. I have some ideas for how I'm going to construct the console which is the next major step. Hopefully as fall sets in I'll have a bit more time to work with.

I've been putting forth a pretty major effort to clean up the code and eliminate latent issues. I've integrated Travis-CI and Coveralls and started creating tests with py.test. So far I've hit 20% coverage, even if those tests are fairly "light" on actual testing. I've also integrated with QuantifiedCode for some code analysis, so I've been fixing those issue as well as making the repository PEP8 compliant (at least as much as possible, there are a few issues PyCharm is picking up that are non-issues).

I'm still investigating PEX and Pants as possible delivery mechanisms. I'm a little saddened that they don't seem to support Windows. Especially since Windows users are less likely to have CLI experience and a self-contained file would really be nice.

I'm getting close to final testing for 0.9.1. I want to do a bit more work with PEX before making a decision. Then it'll be testing and bug fixing time. If I do decide to add PEX packaging I'll probably release 0.9.1 without it and wait for 0.9.2.

I just tagged and released v0.9.0 on GitHub. This correlates to the video series I did earlier this month. Once that was done, I merged in my active development branch into the master and geared up for v0.9.1

Next release will mostly cover the stuff I've done since those videos. The landmark feature here is the web UI. There's also a lot of under the hood changes and improvements. I'm aiming for the end of the month. A busy work schedule and home hasn't really given me much opportunity to work on this recently. I'd like to test what I've worked on a significant bit more before releasing.

I've been solidly hacking away at the web UI for KAPCOM. This will provide a dashboard for switching between configuration modes as well as reconfiguring displays on the fly. So far, I have a fully functional, but not very nice looking dashboard and I have an in progress configuration editor.

I've opted to do this using Flask to serve up a static page which leverages jQuery to send AJAX requests back to Flask over an API which then queries the data from the KAPCOM object. I also threw in some charts

It sounds complicated, but it's really not so bad. It makes the whole thing very dynamic and loads without page refreshes. Behind the scenes, I had to do some work to make KAPCOM threaded and provide a way of interacting with it so the web UI would work at all. My AJAX and jQuery are definitely rough around the edges, but I'm getting more familiar as I go.

Overall, I'm pretty happy with how it's coming out. I should be able to finish the configuration editor over the next day or so. Once that's done I'll spend some time polishing up the dashboard and get it looking really close to the SpaceX interface.

Dashboard:

Configuration Editor:

I got everything working to support multiple Arduinos and multiple control modes tonight. Probably the hardest thing I've worked on, just because of how complicated the data structures have gotten. It's all working now. Definitely needs a lot of testing with multiple configuration modes, but that will come with time.

In any event, I got it all working with the Raspberry PI so I now have a functional wireless controller!

Next up I'll probably take a look at creating a web based configurator/viewer.

My Raspberry Pi came yesterday, so went ahead and set that up. I had a few hiccups setting up KAPCOM, but it worked once I figured those out. I ended up needing some additional software packages:

sudo apt-get install python-pip
sudo apt-get install python-dev
sudo apt-get install python-xlib

With those installed, http://setup.py happily ran and installed the other Python modules. I also set up Synergy for sharing my trackball to my KSP machine. The instructions on Adafruit were mostly correct, but I also had to run the following commands:

sudo apt-get install libcurl4-openssl-dev
sudo unzip ext/gmock-1.6.0.zip -d ext/gmock-1.6.0/
sudo unzip ext/gtest-1.6.0.zip -d ext/gtest-1.6.0/

section: screens
	KAPCOM-Pi:
	Mac:
		meta = alt
end

section: links
	KAPCOM-Pi:
		right(0,100) = Mac
		left(0,100) = Mac
		up(0,100) = Mac
		down(0,100) = Mac
	Mac:
		# left(0,100) = KAPCOM-Pi
end

section: aliases
	Mac:
		Mac.local
	KAPCOM-Pi:
		KAPCOM-Pi.local
end

section: options
	keystroke(F1) = switchToScreen(KAPCOM-Pi)
end

Very happy with the progress I'm making. I'm going to spend some time at lunch working on the mode and Arduino code. Once I get that done, I can go back to working on the enclosure.

I've been working on changing the configuration and Python to accept support multiple modes and multiple devices. It's still a work in progress, but it's getting there.

Meanwhile my changes to Telemachus were just pulled into the latest build, so simple joystick mapping is easily doable even without my custom build.

So last night I was brainstorming how best to accomplish multiple configuration modes and I was sorta struggling with how I implemented the joysticks. While it works, it is far from elegant. Each `Joy.toString()` returns a comma separated list of the axes: i.e. -1,-1,-1 or 0,0,0 or 1,1,1 or something in between. Because the Telemachus API only has `setYawPitchRollXYZ`, I have to aggregate both responses into a single API call.

It's not bad, but it makes `Joy0` and `Joy1` special snowflakes and not as easily interchangeable as the rest of the system. If I wanted to implement separate controls for spaceplanes, it'd have to be very specific code and not just reuse what I'm using for all the other devices.

So that got me thinking: maybe I should put in a feature request for this? Unfortunately, the author hasn't been really active recently. I decided to search the repository and see if I couldn't reverse engineer what I needed. It turned out to be a single place in the repository, so I added two separate methods `setAttitude[yaw, pitch, roll]` and `setTranslation[x, y, z]` and submitted a pull request.

This was probably not the right thing to do since I hadn't tested it at all, but I put it out there in the hopes that it might be someday pulled in. This morning I woke up and decided to try my hand at building a mod. Seeing as I had zero experience with this and no environment setup, I started with the Telemachus docs. I did hit some snags.

• Being on a Mac, Visual Studio is out. I opted for Xamarin
• You need to download and install Unity 4.6.5
  • Don't use MonoDevelop, I couldn't get it to build properly
• You need a Windows install of KSP for the KSP_Data (cf. step 2 from Telemachus wiki)
  • You might be able to get it from KSP.app/Contents/Data, but it wasn't a 100% match.
• The post-build script is Windows only.
• Either deal with it, or use DwarfPlanetTossing's fix
• Even with this fix, it didn't seem to work 100%, so make sure when you copy out the .dll's, you get the newly built ones.
• I'll say it again, check the timestamps of the .dll's. I spent far too long combing the code for what went wrong when the solution was I was still using the old version.

Anyway, all that said and done, I was able to successfully build Telemachus from source with my new contributions. I'll be using this build from now on and it'll make life MUCH simpler for the planned modal inputs.