cm2227

Does anybody want to help me with writing a hardware interface for MechJeb? I'm not a programmer and some tasks take much more time from me than from somebody who knows exactly what he is doing. Feel free to contact me!

Hello folks, there is a slight chance you already know what I'm up to. If not, I'm building a cockpit including controls for MechJeb. But, I'm not a programmer, so I would appreciate help on the software side. For starters I tried to determine wether mj was present or not. For that I wrote Type type = Type.GetType(MuMech.MechJebCore); if (type != null){do something} and I receive a compiler error saying MuMech.MechJebCore is of type "type" and invalid in that context. Thought I was smart. Who tells me why I'm not? Or is there somebody in this thread willing to answer more stupid questions or even do a full cooperation on the mechjeb part of my project? I don't dare to ask sarbian...

Sounds fair and okay to me, thank you for your work. I might continue asking stupid questions when I don't understand how your code works.

So that's how Canadians feel. Excuse me, I'll have some rye whisky with maple syrup from the Stanley Cup now.

As I have to write a mechjeb interface, it'll neither be short nor simple. I forked a copy of KSP to my git at https://github.com/cm2227/KSPSerialIO/blob/master/KSPSerialIO/KSPIO.cs. I will tell you about what I do and you can decide what to add to your code. I'll write you my mail adress by private message.

Dear panter, have a look at void controls() and void MainControls(byte n, boolean s). controls() reads pin input and calls MainControls to write the input value to the nth bit of the controls byte. So the defines you list, #define SAS 7 for example, don't apply to pins but to which bit in the control byte stores which binary information about a system (SAS in that case) to be turned on or off.

Sorry for the lame pun, but what was wrong with the old one? Anyway, congratulations!

There are still questions remaining for me. Do you want to work on your code together with me? If so, who writes which part? And how do we exchange code? Github?

I think I found another solution to the mechjeb question. A routine to check wether mechjeb is present, and all mechjeb specific functions are only active when mj is present. In the VesselData packet all values calculated by mj would be 0, and mj commands in the control packet would be simply ignored. How about that?

Actually this practice was started by Jim Lovell, who took the eyepiece of the OAT from Aquarius just before jettison. Fred Haise took some stowage netting, I think. Afterwards it became sort of a tradition of LM crews to take souvenirs from the LM to bring it home in the CM. I think they wanted to keep the memory up for their LM, which had carried them to the lunar surface and safely back to the CSM. It is hard to just throw away your spacecraft. I can't remember Al Worden giving details about which parts Dave Scott and Jim Irvin took from Falcon, but the story is totally credible in my eyes. Now, who wants to buy it for my simulator?

Would you consider a mechjeb-version and a non-mechjeb version, maybe a fork? I don't understand enough of the game architecture and c# to calculate these values in code instead of grabbing them from a plugin that actually does it. See for example https://github.com/CYBUTEK/KerbalEngineer/blob/a596fcfbd50ab08b828401c04c2e1ca8b941ae69/KerbalEngineer/Simulation/Simulation.cs, it is the source code of how Kerbal Engineer simulates all stages and comes up with stage and total dV. If you don't like the idea of accessing another plugin's data we should find another way.

MechJeb source code says float atmDv = (stats.atmoStats.Length == 0) ? 0 : stats.atmoStats[stats.atmoStats.Length - 1].deltaV; float vacDv = (stats.vacStats.Length == 0) ? 0 : stats.vacStats[stats.vacStats.Length - 1].deltaV; returns atmospheric and vaccum stage delta-V. float atmDv = stats.atmoStats.Sum(s => s.deltaV); float vacDv = stats.vacStats.Sum(s => s.deltaV); are the total delta-V stats. FlightGlobals.currentMainBody.maxAtmosphereAltitude FlightGlobals.currentMainBody.Radius are from Unity I must admit I have not yet started work on extracting data from MechJeb or controlling it. My coding skills are not that good. But I'll have to look into those issues for my project, so why not share it with you? Or would you prefer writing that code yourself?

Well that sounds great to me. As I'm constantly changing my development goals, you might regret working with me. Anyway, here is a preliminary list of additions that I deem necessary for my project: (I call the Arduino Mega with keypad for issuing commands to MechJeb "colossus" and the one managing all displays "luminous".) [StructLayout(LayoutKind.Sequential, Pack = 1)] public struct VesselData { float dVTot; //43 Total delta-V remaining for current vessel float dV; //44 Delta-V remaining in current stage float Atmo; //45 Atmospheric height of body currently orbited float R;//46 Radius of body currently orbited byte state; //47 Used to tell colossus wether MechJeb is active or not or wether the plugin can accept orders } struct ControlPacket { String opcode; //command packet from colossus to MechJeb, needs interpretation in plug-in }; The opcode command packet is what I intend to use for controlling MechJeb from the colossus unit. The packet looks like program#argument1#argument2#, for example 12#85#4 would read Program 12 (ascent guidance) to 85km orbit with autostage to stage #4. Of course this requires not only functions to call MechJeb members, it also requires a string parser to decode that information. If you have suggestions for improvement, feel free to tell me. To solve the multiple serial question I'm pretty much committed to using a single connection between the PC and colossus, and copy the VesselData to luminous as luminous does not have any functions requiring a connection to the PC, it is just a passive (but complex) information display.

Don't tempt me. I'd love to build a Gemini Simulator or something.

Of course I appreciate you doing any work on your project which I can use. But I have already found a few points where I have to add code to your plug-in to make it work with my project. I would add to VesselData dVtotal, dVstage, planet radius and atmospheric height. And the ControlPacket needs MechJeb commands for my purpose. So what I'm trying to say is I could write this for you to incorporate into your official release. Same applies to the multiple serial connections.

Thanks for the advices. Yes, I intend to use a font without serifs, like on the Apollo CSM panel. And I haven't played much with the X-52 throttle yet. But I will watch closely for irregularities in the throttle curve.

I already bought a can of sixties-style cream colored paint.

Hey guys, I'm using the code on my own project. Do you think it is possible with reasonable effort to connect the plug-in on two seperate serial connections to two different arduinos?

Is anybody willing to actually help me with coding? Not only the MechJeb stuff, also general things.

@Mulbin: Please change the link for my project to this post: http://forum.kerbalspaceprogram.com/threads/77921-Custom-Control-and-Display

You will see my project is the third in the thread you linked - - - Updated - - - What I want to accomplish in the near future is controlling MechJeb in DSKY-style (not NOUN and VERB based, but similar). I already assembled a field of 12 buttons for direct mechjeb Smart-A.S.S. commands like PRO, RETRO, TARGET+ etc. that don't require numeric input. But I dream of a sequence like this: The LCD reads "Ready for input. Enter command:" You press *11# on the keypad like your cue card told you to load MechJeb ascent guidance. The LCD reads "Ascent guidance was requested. Please provide desired orbit altitude in km: " You press 125# on the keypad This goes on for inclination and other details (auto-staging has its own switch) Finally the LCD reports "Ascent guidance active and ready for lift-off. Press * any time for disengage." Automated landing would work similar. Interplanetary transfer is more complex, but feasible. I guess the C# coding for the KSP plugin interacting with MechJeb poses the largest obstacle to me.

Further not yet visible plans are: Adding 5 MAX7219 ICs to control the 7-segment displays Second LCD right of the center line (centered on the cross indicated with pencil right to the numeric displays) Second Mega handling non time-critical tasks, i.e. not updating any displays based on serial communications Second Mega receiving own 2x16 display and acting as input system similar to DSKY with its own keypad Additional switches for flight modes, power supply and test circuits

Hello KSP community, I decided to move my thread here as it is not about plug-in development anymore. After christmas 2013 I started my own hardware project. I began with thoughts about using a USB interface board to connect my own buttons and gauges to the game. Then I realized I can do bigger. In this forum thread I would like to share the history, accomplishments and failiures of this project. Project overview I'll keep this overview updated, although I'm not sure wether I should write all updates in the title post. Nevertheless, here is what I'm working on. I'm building my own cockpit with custom controls and displays. The cockpit consists of two parts, which I call the control panel and the console. It can be operated by a crew of two or a single pilot. The control panel houses buttons, switches and in the future a single LCD. The console part has a X-52 flight joystick and throttle, translation joysticks, keyboard, a trackball (to be added) and several switches, buttons, gauges and displays - LCD and 7-Segment. The digital backbone and design requirement is a single USB connection to the PC. Logic units inside (apart from the obvious USB devices) a USB keyboard controller managing the buttons and switches (via another microcontroller) acting directly on action groups or KSP keyboard controls, an Arduino Mega for managing the displays (which I call luminous) and a second Arduino Mega called colossus for entering command codes remotely similar to the DSKY unit in Apollo spacecraft but acting on MechJeb. May 5th, 2015 I continued my work through the winter, but only recently I achieved some serious progress. As described before I switched to Polystyrene modular panels. Now I can work on individual modules or the whole console just like I want. Quick overview of improvements: New instrument panels, way more switches, new power supply with contrast and brightness for all instruments and LCDs. Jump to the end of this thread for detailed progress description. November 25th, 2014 Well I did probably almost nothing all Summer long. But I picked up my work and reworked the hardware side. I ripped away the dashboard and the wooden structure on the back, which became too heavy. I rebuilt the dashboard support structure from riveted aluminum profiles, and all the dashboard instruments and switch units will be mounted on modular panels so they can be modified or moved. I abandoned the principle of using a single-piece dashboard, because I simply had one chance to cut the matching hole for one instrument, and if I made a mistake I had to start over. There will be pictures soon. Just take a look at the picture. I waste several centimeters on each side of the panel. Can't wait to fit some instruments to the new structure. May 16th, 2014 I'm proud as a duck because I reached a major milestone today. For the first time ever I was able to display real-time vessel data from KSP. This would not have been possible without the plug-in from Zitronen, which at the moment I use without changes on the KSP side. The arduino software incorporates Zitronens example code. May 9th, 2014 I was able to repeat yesterdays success. For the last two weeks I've been working occasionally on the colossus hardware, but the software was not really functional. Today I finished the primary loops. Now it can ask the pilot for the next command, look up how many arguments the command needs and send all this information on a serial line. Have a look at the colossus setup while running. All inputs are numerical and entered with the # key, whereas * acts as decimal point. Nothing spectacular, but I'm proud of it. The array of 10k pull-down resistors is present because I only recently realised I could have used INPUT_PULLUP instead. The LCD is not the final one, which will be 16x2 as well but white on blue like luminous. I also intend to use a single potentiometer like the one shown for adjusting all LCD contrast voltages at once (and a second one for brightness). Of course that means the LCDs have to be identical. On the luminous side I also made progress. Alarms are triggered properly now. If any value triggers a master alarm, the master alarm and buzzer will definitely tell you. Also each alarm (like monopropellant or battery level has its own dedicated LED. You can then quit master alarm with the right button, but the individual alarm LED remains illuminated as long as the alarm condition persists. During that time no master alarm can be triggered by the same alarm. Only when a value returns to normal and then back to alarm level it can trigger another master alarm. The master alarm buzzer happens to be cheap and sounds pleasantly unpleasant. May 8th, 2014 The past two weeks have brought progress in several field. I split software development into three different projects. The actual KSP plugin, arduino software for display and for data input. I suspended my work on the plugin (I actually havent't played KSP in weeks, all my free time for KSP goes into the project), but I intend to modify zitronens plug-in. I need communication with my display system on one serial port, and command interpretation on a second. Maybe I can extend zitronens plug-in to support two open connections and MechJeb commands. In all due decency I named the software part for displays "luminous" and the one for data input and command interpretation "colossus". Here I have a quick pic of the current luminous setup in running state. It shows two LCDs with various information, the flight mode switch, voltmeter for battery level and an LED column. At the moment I'm working on proper master alarm detection and the warning LEDs. I want a useful logic which allows the pilot to quit a master alarm and the same source of alarm can only trigger the alarm again after it has returned to normal condition. That means you would get a master alarm for low battery level and quit it. The master alarm would only be triggered again after battery level has returned to normal and then to low again. Next update will probably be about the colossus part. April 24th, 2014 I'm actually making huge progress in the last days. I owe that to my lack of work at work and the incredible support of my wife, who treats this project as if it were her own. I decided on ordering a second Mega µC, this one being a clone from SaintSmart. This pic shows the current state. I'm working on several things currently. This time I focus on the instrument panel alone. That is the angled board with the lcd and the meter etc. Best is to describe it from left to right. The LCD to the left will be the consumables and EECOM display. It is currently connected directly to Mega#1 for test purposes. Later it will be driven by its own RS232 controller, which I still try to build myself. If that doesn't work all LCDs will be wired to the Mega with I2C LCD drivers. But I intend to reduce workload on Mega#1. Below a group of LCDs will indicate alarms, warnings and status. The master alarm LED will be joined by an ugly-sounding beeper which came in the mail yesterday. Next is a voltmeter, connected to Mega#1 for monitoring battery level in %. The scale is already adjusted, meaning 1mV equals 1% batt level. The little black joysticks have been discussed on reddit and are described in my imgur gallery. If you don't know either of them, here are the links: http://www.reddit.com/u/cm2227 http://cm2227.imgur.com Newest addition to the panel is the numeric display. Three 8-digit and four 4-digit seven segment displays will show various figures depending on display mode. There will be a selector switch for lift-off, flight and descent mode, each having its own set of display modes and alarm conditions. For example flight mode will show apoapsis and periapsis on 8-digit displays, which is pretty much useless during powered or unpowered descent. April 17th, 2014 After I gave up entirely on USB LCD controllers I also suspended my work on RS232 LCD controllers. I made my own circuit boards (layout and etching) but I just couldn't get them to work properly. March 2014 I gradually expanded the wooden structure to house more parts and circuitry.This state shows the instrument panel installed, and also a wooden structure behind it to support power supply and future PCBs. Mid-February 2014 I threw away the first button assembly and started over. A wooden case houses 20 buttons and 6 switches. The hole is for a LCD to be added. Inside, a PIC microcontroller converts the switch states to key strokes. Together with the console it looks like this. Not much circuitry is installed yet, apart from a USB hub and a prototype USB LCD controller, which I discontinued after finding out that the corresponding USB library only supports one device. I was not yet into Arduino or similar microcontrollers and actualle tried to avoid them. The coordinate switches for translation control are just standing there unconnected to check their placement. January 9th, 2014 This is where I started. A USB keyboard controller and some buttons. The USB interface I bought never got to use. And I put some joysticks on a board.

@Mulbin please change my horrible photo to this one: Thanks!

Adding the last two post together I can agree that the cost per lb to LEO is way lower for a Saturn V launch. But that was not what I denied. I (and the post I referred to) were talking about cost per launch. And I agree that the comparison is unfair. Nothing to argue here. But another aspect of the shuttle design history came to my mind. Through reading the book "Digital Apollo" I learned much about test pilote attitude towards piloting spacecraft. And it appears to me that the astronaut community of the Apollo era vowed for a spacecraft that can be flown, not just controlled. That ruled out all non-winged designs, at least in the opinion of the astronauts. Remember the influence people like Slayton and Shepard had on management, add the military's dogmatic requirements, grind it through the realities of politics and you get the STS, with all its flaws and wrong estimations. I wouldn't like to find out my launch costs are increasing instead of decreasing, because I find out what had been done wrong or too careless. And always remember: A camel is a horse designed by a committee.