Arduino Addon for Mac

[stibbons]

Merging the current plugin code to marzubus' branch was indeed easy. The code I have now looks like it's OK and builds cleanly on my machine, but I'll need some more time to test it properly. If you want to try it now you can check out and compile my branch of the merged code. Or just keep an eye on my pull request at https://github.com/unixunion/KSPSerialIO/pull/1

[richfiles]

Awesome! Always appreciate the work!

And I DID find the original thread and found

public float Pitch; //43 Vessel Pitch relative to surface (degrees)

public float Roll; //44 Vessel Roll relative to surface (degrees)

public float Heading; //45 Vessel Heading relative to surface (degrees)

This gets my basic navball spinning... but not maneuver nodes and heading vectors. I still need to be able to guide the targeting crosshairs.

What I don't see is degree values for the heading vectors (Prograde, radial, normal, and their inverses)... I suppose it's probably possible to calculate those from the orbital data (Ap, Pe, inclination, semi major axis, semi minor axis, eccentricity, orbital true anomaly) though I have no idea how to do that yet... I guess. The thing I don't see any way to do, is to get a reading on maneuver node heading or target heading.

Those two are MAJOR requirements for implementing a hardware navball... And I don't see them...

I wonder if MechJeb could be used as a bridge to get the maneuver node/target/heading vectors. Obviously Mechjeb has full access to all that info, so it presumably can calculate the necessary data. Might it be possible to extract the necessary data from MechJeb, when installed? Kinda like how the NanoGauges mod extracts Mach Speed and a few aero numbers from FAR if it's installed, but ignores that data otherwise?

[stibbons]

There's been some discussion on the original plugin thread over the last few pages about how to utilise the last 60 or so bytes available in the data packet. Velocity vectors like prograde, normal and radial are popular options, don't recall if the target vector has been mentioned. Probably best to chime in there.

And the plugin already contains some code borrowed from Mechjeb. I imagine the fastest way to do the heavy lifting for calculating vectors will be to do that again m

[richfiles]

Yup... Been working on a small novel over in that thread the entire time!

I also brought up the possibility of getting rate of yaw, pitch and roll, not by consuming data, but by sampling the already existing yaw, pitch and roll data and measuring change between samples against MET. That should be both a very simple calculation, i would think, and get the data without consuming more precious bytes, right?

Yeah, those 5 vectors are pretty much critical to anyone flying by instruments.

I'm considering, after finishing interfacing my REAL navball... Possibly seeing how hard it'd be to do a homemade navball, using off the shelf components. I used to work in manufacturing aerospace/defense motors, synchros, etc, so I'm very familiar with a lot of precision motor tech. I also have a complete understanding of the mechanical makeup of a navball. I even came up with a means to build one without the complex slip ring mechanism (you provide power with the left and right "wishbone" feeding power into the right and left side of the disc through simple wipers. You then have a photodiode/LED pair at the pivot on either side to transmit data into and out of the ball. A few capacitors filters the DC bus voltage, and an arduino pro mini or something like that sits inside to communicate with the outside of the ball, and to run the two internal motors. Externally, you have another small arduino drive the wishbone motor, optical communications to the ball's internal arduino, and the flight director/rate meters.

If I play is careful, it can be kept on the cheap. Cheap enough for anyone to put together.

If that becomes possible, then having those 5 vectors becomes significantly important to anyone that want to fly by instrument.

[stibbons]

So this build with the 0.17.3 packet format seems to work for my hardware on OS X. https://github.com/phardy/KSPSerialIO/releases/tag/v0.17.3-1

I had to drop the serial baud rate to 57600, but that might just be because my Mac Air grinds hard running the game. If anybody else has some time to test this release it would be appreciated.

[stibbons]

I've merged 0.17.4 and built a new cross-platform release. Give it a try: https://github.com/phardy/KSPSerialIO/releases/tag/v0.17.4-1

[stibbons]

Curious to know if anybody else is using this code on actual hardware. I finally got to test it fully on my reassembled and expanded system this evening (after doing basic func tests running the example sketch on a bare arduino) and had all manner of problems. Still trying to track down precisely where the error is coming from, but it would be nice to be able to confirm the plugin is working for others.

[nathangray]

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

Edited September 4, 2015 by nathangray

[stibbons]

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

Sorry for the delayed response.

There seems to be a couple of issues with this plugin on Linux. First of all, it won't work if you're running 32 bit KSP on a 64 bit Linux install - see my explanation on the github issue for it: https://github.com/unixunion/PsimaxSerial/issues/3#issuecomment-144391972

But even after that I'm seeing the same behaviour as you describe. The initial connection seems to happen, but nothing afterwards. I'm wondering if it's anything to do with this resolved issue. https://github.com/unixunion/PsimaxSerial/issues/1

[stibbons]

OK, things seem to be fairly stable for me on Linux now.

* 0.17.4 is slightly newer than what's on the front page of zitronen's thread right now, and has a couple of new fields in the VesselData packet. I've been testing with their demo13 sketch at https://sites.google.com/site/zitronfiles/KSPIODemo13.zip and it's been working for me.

* The configuration file does not set a default refresh rate. This means the plugin is trying to send a new packet every frame, which won't make your arduino happy. This is the config file I'm using right now:

<?xml version="1.0" encoding="utf-8"?>
<config>
    <double name="refresh">0.08</double>
    <string name="DefaultPort">/dev/ttyACM0</string>
    <int name="BaudRate">38400</int>
    <int name="HandshakeDelay">2500</int>
    <bool name="NoDetect">0</bool>
</config>

EDIT: Turned out I had the code working on Linux with an Arduino Uno, but the Arduino Mega in my controller wasn't connecting properly until I increased the HandshakeDelay. If you're having trouble with this plugin, increase that. I've changed my config above to set HandshakeDelay to 2500, which seems to work for me.

Edited October 8, 2015 by stibbons

[nathangray]

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?

[stibbons]

I'm only playing the game on Linux these days, using the plugin in this thread. But the code I'm adding to support all of the navball vectors will eventually be a PR against zitronen's original plugin (and then merged in to this one).