c4ooo

Hi, streaming video from other mods, like Alcor screens or the camera mod (HullcamVDS iirc) into YARK was something I looked into in the past but could not figure out at the time. Right now I am in college and don't have time to work on big projects anymore.

Assuming KSP 2 is as moddable as KSP 1, I'm sure mods like KSPSerialIO will get ported over. But it may take time since there seems to be less activity in the scene right now compared to previous years. I actually have a mod + external program for this, though I suck at packaging distributables so it may be a bit difficult to set up.

Hey, looks like the download was never updated. It should be at the most modern version now. As for the connection issue, can you try the newer version and provide more info if there are still problems? Plugin: https://github.com/c4ooo/YARK/releases Display: https://github.com/c4ooo/YARK-MFD/releases/

Hmm, looks like your post disappeared Anyways, I removed the disable-sas code in my own plugin, and it seems to work fine. I based a lot of my TCP plugin on yours, so I think it may be worth a shot in your plugin too. Maybe the internals of how input is handled got changed sometime after you added joystick input? The reason I brought this up is becouse I was looking through Advanced Fly By Wire and noticed that it doesn't disable SAS on joystick input. https://github.com/linuxgurugamer/ksp-advanced-flybywire/tree/master/AFBW

I can literally only see 2 posts at a time without scrolling

@zitronen Hey, What exactly was the point of the turn-off-sas when joystick-was-used code? I was trying to improve joystick input a little and noticed that sas was turned off with joystick input. Seems like this was introduced in 18.3.

Hey, as a said in last post, I redid the UI and added some stuff like a docking alignment indicator. I made a video showing how to use the MFD. Never made a vid like this before so its not very good though

Unfortunately I don't think that's really in the scope of what I am trying to do. The main issue is that the amount of data I have access to is a lot less then what is available to mechjeb, or what would be available through kRPC. As a sidenote, I did away with the dumb console-to-open windows thing and am in the process of making the UI a lot more straightforward:

Are you talking about controlling pitch yaw roll? Maybe the axis config is set wrong to where KSP receives the data but ignores it? (See above)

"#define" defines a macro that gets replaced by the preproccessor before your code even gets to the compiler. Macros are really just dumb text replacements and should be treated as such, but that's not to say they aren't handy. "const" is a language feature that gets interpreted by the compiler, and has type safety and other features just like any other variable. Both are equally useful for defining stuff like I/O pin numbers, but #define macros can also be used for compile-time #if#else blocks.

The issue is with a specific IC chip on the arduino or wrong driver on your PC as far as I know. So you just got lucky in terms of what IC was used by the designer of your specific arduino (I think genuine ones don't work while knockoff Chinese ones work a lot of the time?) . As for analog vs digital, all the data is converted to digital anyways when being sent over the Serial interface, so it doesn't matter

I'm trying to write up my progress here

Input Matrix: I planned to have around 40 input switches in my control panel. Having a separate MCU pin per switch would not only be a pain to wire, but also make me quickly run out of MCU pins. The solution is to use a matrix. A matrix allows a grid of devices to be wired into a series or rows and columns, and "scanned" one column at a time. Thus instead of having 40 wires, I can instead have 5 row and 8 column (for 13 total) wires. The idea is that you send current down a single row at a time and see then read the side to see which switches are on, then send current down the next row. This is a little bit reversed in my setup, but I will explain why later. Having 6 rows 7 columns would technically allow be more switches for the same amount of wires, but having 8 column wires allows me to easily read all the pins at once using the PIN register. If you want a good explanation read here: https://www.dribin.org/dave/keyboard/one_html/ Now, switches need either pull down or pull up resisters. For an input matrix, using pull down resisters makes more sense. However, most MCUs have internal pull up, not pull down pins. This means that the output has to sink current from the input. This is kinda backwards and makes less logical sense, but it works on the amels. Here is the schematic: Notice how there's a diode per switch. The diodes prevent ghosting (see above link), but in my setup they also prevent a HIGH (ignore) from flowing from the output to the input. To read the middle vertical row of switches, I can output HIGH/LOW/HIGH. This allows the current from the 5v to sink through the middle vertical row, but not through any of the other rows. If the switch is open, the 5v can't sink to ground, and the input port reads HIGH for that switch. If the switch is closed, the 5v sinks to ground the output port, and the switch reads LOW. Wired up, it ends up looking kinda neat: Input Matrix part 2: code First we set up the ports we need to use: DDRD = 0b11111111; //38,X,X,X,18,19,20,21 DDRA = 0b00000000; PORTA = 0b11111111; //29,28,27,26,25,24,23,22 1) First we set the direction (DDR) register of bank D to 0b11111111, this sets pins 38 ,18, 19, 20, and 21 to output mode. This bank will have the output pins we use to select which row of switches we read. 2) Then we set direction (DDR) register of bank A to 0b00000000, this sets pins 29, 28, 27, 26, 25, 24, 23, and 22 to input mode. This bank will have the input pins we use to read the switches. 3) Then we set the output (PORT) register of bank A to 0b11111111, this starts outputing 5V to the pins through the pull up resisters. Steps 2 and 3 is like setting INPUT_PULLUP mode for all the pins in bank A. Then, this is how we read the switches: PORTD = 0b11111110; delay(10); switches[0] = PINA; PORTD = 0b11111101; delay(10); switches[1] = PINA; PORTD = 0b11111011; delay(10); switches[2] = PINA; PORTD = 0b11110111; delay(10); switches[3] = PINA; PORTD = 0b01111111; delay(10); switches[4] = PINA; Using PORTD, we set LOW one pin at a time. This "activates" the corresponding row. Then we read the states of the 8 switches in that row using PINA. The delay() part is kinda needed becouse, do to the length of the wire (some switches are up to a meter away from the arduino!), or do to capacitance, or do to black magic, the wire that selects the row may "ring" for a bit before it actually goes LOW/HIGH. This will cause weirdness like reading row 1 into switches[0] and switches[1] while also reading row 2 into switches[1] and switches[2].

FUEL (analog displays): Next I decided to work on the analog displays. The displays I used where 5 volt voltmeters that you can get off of ebay. disassembling the meter, I took measured the faceplate design and recreated it in CAD. From there, I added marking and added text labels. I wasn't sure if I wanted the text to be horizontal or curved on the G and VERT meters so I made two variants. Then I printed out the designs and glued the paper to the faceplate. I also drilled some holes in the meter housing for LEDs, these will be used for warning lights later. This was the final result: Finally I wired up all the negative sides of the meters to ground and the positive sides to the PWM pins on the arduino. Controlling them is easy, all calcculations are done on the PC, the arduino simply recieves 8 bytes and uses them to set the pulse width for the 8 meters in a for() loop.

I have started wiring the electronics for the panel. I will try to make a post for each area of the panel. Power: Due to the number of LEDs I have planned to use, as well as the LCD monitor I needed to power, I knew I had to use an external PSU. One of my first thoughts was to use an ATX PSU. They are very powerful, easy to come by, and provide like 3 different voltages (as well as a standby 5v), plus can be turned on/off by shorting a PSU_ON signal to ground. Instead of having a simple on/off toggle, I thought it would be cool to have a "push to start" button and a "toggle kill" switch. Since I needed something to "store" the on state after the push button was depressed, I decided to use a relay. When the "push to start" is pressed, the standby line is used to close a relay. When the really closes, it shorts the PSU_ON to ground, turning the PSU on. As the PSU turns on, it starts outputting 5v, which keeps the relay closed even after the "push to start" button is opened. Finally, the "toggle kill" is used to cut the 5V going to the relay, allowing the PSU to be turned off. Throwing in a couple LEDs and I get this circuit: The two diodes before the relay are needed since you can't short the 5V and STB lines together. They are both 5V, but are generated by different circuits in the PSU. (And also, I forgot to draw the rays coming off of the "on LED" ) The wired up circuit looks like this. You can see the ATX header on the left. And here is the push button and switch from the front:

Yea, just wanted to point this out In my panel design (yes, after 4 years I finally started soldering stuff together ), all processing is done on PC and the arduino just acts as a dumb proxy between the PC and SPI led drivers, voltmeters, and switch matrix, so implementing this correction will be easy to do.

wut The video demonstrates the use of the NN for simulating cloth. There is absolutely nothing to suggest that it would work well for rockets, and the claim that using NN will magically "boost performance with 1000fps" is ridiculous. NN aren't a magic solution to every single problem as some people like to paint them as. NN = Neural Networks

One problem with this deign is that the the potentiometer position (X) isn't 1 to 1 with the lever angle (Theta). Because of this, when the lever is far from the center, dX/dTheta is going to be bigger than when the lever is at the center. (Same change in angle is going to result in bigger change in pot position at the edge than at the center) To get the "true" lever position you would have to do something along the lines of Theta = atan(X/L), where L is the distance from the pivot to the potentiometer track (when the lever is perpendicular to potentiometer track). (sorry for 3 year late reply )

Speaking of reddit, I thought someone should mention the Kerbal Controllers subreddit in this thread. Seems to be somewhat active.

Do you guys think covering the wood panels with aluminum tape would make for a good aesthetic?

Once again, if you wanted to preserve the numbers after the decimal, you need to multiply your float by 10 or 100 or 1000, then when you cast it to integer you will still have the numbers after the decimal. However I don't even see why you need to cast from float to int, any competent programming language will just allow you to use the floats directly. Good job reinventing the wheel with your own casting function though ¯\_(ツ)_/¯ Edit: it sounds like you are reading the data *as an integer* and casting it to integer, you need to read the data *as a float* and cast it to integer.

Isn't this what you want? If you want to use an integer but still express some of the values behind the dot, all you have to do is multiply the float by 10^x or 2^x, then convert to int, then remember that your integer is actually 10^x or 2^x times smaller then its raw value.

Um so... 0x447a0000 *IS* 1000, just in a special format. One thing to understand about low level programming is that data is just raw numbers, and gets its meaning from the context it is used in, if that makes sense. What you are trying to do is convert the float into an integer. Almost all languages have a built an int() function to do this for you. One thing to be aware though is that int() truncates the float, you need to be aware of this if you require the numbers after the decimal. That being said though, if your language is any good you should be able to do all your calculations using the orignal floating point number, however float math is slower than integer math, especially on old CPU / MCUs.

Fuel data is stored as 32-bit floats. (zitronen why? >_> ) 1000 as a 32-bit float is 0x447a0000, according to this website, so your value makes perfect sense. On an aside, how are you planning on using this mod without an arduino?

What floating point data are you talking about to be exact? You might have to convert them to integers or something for them to work correctly with the API for your readout. Otherwise, the formatting of the structures is found in the original post.