MrOnak

Not yet, after this weekend I might make one. Problem is that I have so very little time to actually work on the damn thing (I'm home only on weekends) that progress is slooooooooow

Hmmmm, that'd be a shame. I'll dig some more into their code

Oh well... guess I need to rearrange things. Again. BTW this is it, work-in-progress. All the blue rectangles are 7-segment displays or bar displays. Their spacing is not 100% spot on yet and I don't like the empty space next to the DSKY info lights. The latter is probably solved in case I need 5 more info lights for SAS, RCS, ...

Yes that's more or less the standard way of validating against zero with floating point math I like using things like (fabs(result - expectedResult) < 0.0001) or something to that effect. fabs() is part of math.h

Okay I just seized part of my lunch break to do some research. Aren't you already working with RCS, SAS and the like in KSPIO.cs Start() after the "sync inputs at start" comment? I checked kOS and they seem to just access the KSPActionGroup suffixes and validate against those. This is probably too easy, right? Update: Seems as if RasterProp also isn't doing anything more. https://github.com/Mihara/RasterPropMonitor/blob/b4618154ed11f96c8be3d9691ba1b154229e8e5d/RasterPropMonitor/Auxiliary%20modules/JSIActionGroupSwitch.cs Lines 49 following. Update 2 DAMNIT I just realized that if this is true I need to re-evaluate my controls layout for the box that I was about to put together this weekend Oh the irony

Ah okay I was afraid you might say that If I remember correctly RasterPropMonitor and kOS both have figured out a way to get the info though - maybe I find some time one of these days to search through their code.

I'd second Hakans opinion on this. Providing the SOI from KSP itself is inherently more reliable and stable. And with "reliable" I don't mean to imply that Amelias code has issues, but that it will invariably fail is SQUAD changes a parameter on one of the bodies that is involved in the calculations whereas the KSP-side of things would simply continue to work.

@Zitronen: This has probably been asked a few times already but my search skills fail me today . Are there any plans to send status information for SAS, RCS, Vessel Lights, Brakes, Gear (is there more? can't think of any) from KSP to the Microcontroller? I believe a single bit-mask of uint_8 should suffice to do this. That said I have no idea whether that is planned or even feasible. It'd be nice however if hardware controllers could display status lights for these things that stay in sync with the game.

@Amelia, yeah you're probably right. After all, Zitronen's plugin updates the Microcontroller only a few times per second (forgot how quickly, exactly), which leaves quite a lot of time for the microcontroller to "do stuff" in between. One thing to keep in mind though is that floating point math is really expensive on an Atmel microcontroller. Not that it will be cheaper on controllers from other brands, just comparing it to integer math. Here's someone who tested it with some dramatic results: http://www.avrfreaks.net/forum/multiply-divide-add-performance-various-data-types He basically generated two random numbers of float, int_8, int_16, ... each, and multiplied them, measuring the time it took. Results on the bottom of the first post . So yeah.. I'm a bit hesitant with floating point math since I know that but it's pretty much unavoidable in KSP where we deal with planetary masses and gravitational pulls at the same time. But beware that floating point error

Interrupts are your friend for stuff like that.

Heh, the processing power of the Atmel microprocessors is vastly underestimated usually. Don't worry, it should be fine. And besides... you don't change your SOI 99% of the time anyway, running the resolveSoi() once per second is MORE than good enough.

- 10 chars

I don't believe so, at least not for KSP. I'm relying mostly on keystrokes and use the "Joystick" device only for the analogue axis (pitch/roll/yaw/throttle and lateral X/Y). This weekend I'll finally have time to build the case for my project. Expect some pictures . Still got a lot of soldering to be done but I still hope I can pull this off before the year runs out.

I don't have my kOS scripts available during the week but if I'm not totally wrong I do this: - calculate 110% of the altitude at which space begins for the body you're on. I call this target altitude or tAlt. the 10% extra is my safety margin. - calculate the orbital velocity oVel needed at tAlt required for a circular orbit. - Launch phase: go straight up and keep your velocity at 90% of terminal velocity tVel for your current altitude. a simple PD controller works great for this. skip this step if you're on a body without atmosphere. go to next step once tVel exceeds 15% of oVel. You'll need the atmospheric density at sealevel for the body you're on to calculate terminal velocities - KSP wiki has them. - "Gravity" turn phase: adjust your thrust in order to keep time-to-apoapsis ttAp ~40s in the future. at the same time, adjust your eastward inclination so that you're angling 9° (or 10% of 90°) at 10% of tAlt, 45° (or 50% of 90°) at 50% of tAlt and so on. go to next step once your Apoapsis crosses tAlt. - circularization phase: angle 90° east. Calculate the required burn duration to circularize at Apoapsis. Cut throttle to zero whenever ttAp is > burn duration. throttle up if it is below burn time. The circularization phase is a bit rough and in fact I have found a better / smoother solution for circularization involving another PD controller logic but I can't for the life of me remember what was involved. That all said, good luck

Holy cow, a motor driven slider pot! I for one, welcome our new throttle overlord!

Check 74HC165 chips if you need more digital inputs. HC or HCT there in the middle, doesn't matter. If you need more output, the 74HC595 is your friend. Again, HC or HCT. Enjoy

What's working really reliably for staging in kOS at least is to trigger staging on sudden changes in fuel consumption. Of course kOS has the advantage that it is either kOS or you that is handling the throttle but that doesn't really make things more complicated, the controller just has to watch "throttleVal * fuelConsumption" (asuming throttle is within 0 and 1) to calculate the value to watch.

Subscribed!

Ah, illuminated pushbuttons... my nemesis. I found it extremely difficult to find good looking ones at a reasonable rate, too. Finally I settled on a small set that Adafruit has: http://www.adafruit.com/products/1479 They're available as momentary and latched varieties and in a few colors. They don't seem to be exactly those that Amelia used but it might be worth checking. Adafruit has global distributors, you should be able to get them from a local dealer if you're outside the US like I am. I ended up mailing them, they ordered them with their next batch from Adafruit and sent them to me at no extra charge.

The whole parser is wrapped up in the kspio_boardReceiveData() function in here: https://github.com/MrOnak/avr_KSPIO/blob/master/kspio/kspio.c This should be really easy to port. The only "trouble" I had was to find an UART library that worked natively on an Atmel microcontroller but I asume the one used in my port will work on the Teensy OR you'll be able to use the one that comes with the Teensy flavor of the IDE. In any case, good luck porting it and please report if you're successful. I'm actually very curious about Teensies now that I know they exist

Hmmm... I haven't used a Teensy myself but the communication between the game and the microcontroller is standard serial with a "custom" protocol if you want to call it that. I don't see why what wouldn't work with a Teensy. Just had a quick look at some more details of a Teensy - if you're using a Teensy 2.x then that seems to have an 8-bit Atmel chip on board. In that case my port of Zitronens Arduino code to AVR C probably run more or less right away: https://github.com/MrOnak/avr_KSPIO The Teensy 3.x'ses seem to run on 32-bit ARM processors (holy crap)? My code probably won't work out-of-the-box there but I don't see why it wouldn't be portable on a rainy day like today

Alright then, that pretty much means that your circuit is fine. So either your craft is "too good" to trigger the yellow/red LEDs or its something software-related. If I have time I'll check the log you posted tomorrow... too tired right now.

Easy test: Swap the wires. If your green LED works fine then swap the connection of the green LED to the Arduino with that of the Yellow one and see if now the Yellow one does the job of the green one. If it doesn't: Circuit problem. Rinse and repeat with the red one

You're right, that'd be 36 RC-filters plus Schmitt-Triggers, 32 of which are piping the debounced signals into 74165 Shift-Registers so that I can read all that with only four pins on the Atmel. The remaining four are connected directly to the Atmel chip and act as digital joystick buttons. I must say I find soldering quite meditative so I really didn't mind making that board. In case you didn't see it, the circuitry and code for that is available on GitHub: https://github.com/MrOnak/avr_usbhid_gamepanel PLEASE read the readme before you send the eagle file to a PCB fab though, since I didn't use it to make my circuitry I can't guarantee that it is error-free.

That's pretty neat! I'll probably borrow the idea having status LEDs for the switches for my own You might want to check Mulbin's simpit thread and list your project there as well by the way: http://forum.kerbalspaceprogram.com/threads/66763-Custom-hardware-simpit-repository-For-people-who-take-KSP-a-little-too-far