[1.12.x] Simpit Revamped (Simpit 2.0)

[Rogor]

What is this mod?

This mod is a revamp of Simpit, a mod initially created by Stibbons . This mod enables KSP to connect to an Arduino (using the companion Arduino lib) to exchange data between KSP and Arduino. This allows for the creation of custom controllers.

 

Installation from CKAN (should be available shortly)

If you want to install it manually, download here from here and follow the instructions from the README.

Source code on Github

Online documentation

Show me what I can do with it!

This mod is only a building block to use to create your own controller. Here are some examples of controllers to give you and idea of what is possible:

Original video by stibbons

 

A compilation of several controllers by Mulbin

Some other controllers posted on reddit

Special thanks to several users of this mod:

• Codapop
• TBM6070

How can I build one myself?

As with all things Kerbal: start small, play around until it works, then aim bigger! And when in doubt, ask the community for help.

Here is an instructable written by members of the Simpit Revamped team to help you start out. There is also several examples included in the Arduino lib.

Here are some useful communities:

•  Reddit r/KerbalControllers
•  Official SimpitRevamped Discord

You can also find several builds with documentation online with a quick Google search.

What functions are available?

Here is the list of all messages available, from the official documentation

In particular, you can get from KSP:

•     Altitude data (sea level and surface)
•     Velocity data (orbital, surface, and vertical).
•     Orbit info, including apoapsis and periapsis. (expended in the revamp)
•     Time to next pair of apsides.
•     Resource levels for all fuel from community resource pack. (expended in the revamp, need ARP to work even for stock resources)
•     Current Action groups, CAG status, SAS mode. (expended in the revamp)
•     Target information (distance, and relative velocity).
•     Current SoI.
•     Current DeltaV (stage or total) and burntime (new in the revamp)
•     Current Timewarp (new in the revamp)
•     Current Maneuver (new in the revamp)
•     Information on the ship (number of crew, etc.) (new in the revamp)

You can control :

•     Custom action group commands, with full support for Action Groups Extended actions.
•     Regular action groups (staging, abort, RCS etc).
•     Main throttle.
•     Vessel rotation and translation.
•     Wheel steer and throttle.
•     Camera (new in the revamp)
•     Timewarp (new in the revamp)
•     Emulate any keypress (new in the revamp, only on Windows)

 

What devices are supported?

KSP 1.12 is supported (it was tested on previous versions with success, but there might be some undetected issues).

It has been tested on Win10 by the team, and various members of the community have reported success on MacOS.

Arduino boards are supported (Uno, Mega, Nano).

License

This project is licensed under the Simplified BSD License.

 

The Simpit Revamped team (LRTNZ, Rogor, Codapop).

Edited November 6, 2021 by Rogor
Add the dependency to ARP

[Codapop]

I'm so happy to see this mod finally get the attention it deserves! It's been a pleasure working with you all.

[Leopard]

downloaded this and currently fiddling with some basic examples, seems very easy to use.

 

only have a crude joystick but have some actually useful ones on order so will be playing more soon.

Q: is it possible to get the current craft acceleration? only really asking as I was fiddling with KSPSerialIO, though these seems a lot more flexible and usable, just curious on acceleration to port one of the examples over.

testing currently using two altitude levels, which is working nicely

Excellent work

[Leopard]

having a play with this more now the decent joysticks have arrived, I've got a button hooked up and a red & green LED for the SAS mode

can activate and deactivate SAS, read the state back, very nice and very useful.

however the game always sets SAS to the default "heading hold" mode, I'm trying to change this but so far having no luck, e.g. I think the following should work but it doesn't

 

mySimpit.activateAction(SAS_ACTION);		// turn on SAS - this works

uint8_t dat[1] = {AP_PROGRADE};				// Select Prograde Hold
mySimpit.send(SAS_MODE_MESSAGE, dat, 1);	// Set SAS mode - this bit does not work

I can read back the current mode and available modes just fine, I would expect the above to turn SAS on in heading hold if prograde hold is not available, but even when it it the mode doesn't change.

 

the doc suggests  "The payload should be a single byte, possible SAS modes are listed in the AutopilotMode enum.", which is what I think the above is doing.

presuming I'm doing something wrong but not sure what it is?

[Leopard]

Have found a fix for this, the problem appears to be related to how the messages are sent to the game. It seems when you send them in the code they join a stack and are sent as when possible.

so my code adds a message to activate the SAS then immediately adds one to set the mode, because its a stack if the activate message hasn't gone this means the mode message will be sent first.

the game logs back this up showing the mode message arriving first, doing nothing as SAS is inactive, then the activation message arriving which sets SAS on in its default mode.

the fix in the Arduino code is reasonably simple.

firstly call

mySimpit.activateAction(SAS_ACTION);

and then immediately set a flag variable but do not try to set the mode, then in your message handler wait to see if you get an SAS mode change notification, and within that check to see if your flag variable is set - if so now call the code to set the mode, then clear your flag.

this makes sure things happen in the correct order.

this could be sorted in the library but to be honest this isn't a massive issue once you are aware of it and I don't think it will occur with other controls as SAS seems to be the only one you switch on/off and separately set a mode for

 

[epicer12]

Does Anyone Here Have Code for a 16x2 lcd with i2c that displays altitude and speed/ apoapsis-periapsis

 

[akut]

I wanted to ask if there is a simple way of displaying numbers and text in a console of sorts for debugging. I'm testing my joystick and I need a way to see the values that I get from the joystick live i.e. while I'm moving it. I can't use the serial monitor while the program is running. I also read here: https://bitbucket.org/pjhardy/kerbalsimpit/wiki/PluginConfiguration.md that when I set the Verbose to True, it would log in so way. But how?

[akut]

On 5/11/2023 at 4:43 PM, akut said:

I wanted to ask if there is a simple way of displaying numbers and text in a console of sorts for debugging. I'm testing my joystick and I need a way to see the values that I get from the joystick live i.e. while I'm moving it. I can't use the serial monitor while the program is running. I also read here: https://bitbucket.org/pjhardy/kerbalsimpit/wiki/PluginConfiguration.md that when I set the Verbose to True, it would log in so way. But how?

I found a way. If anyone has the same problem you can use:
 

  String text = "r " + String(roll) + " y " + String(yaw) + " p " + String(pitch) + " x " + String(reading_x) + " y " + String(reading_y);

  mySimpit.printToKSP(text, NO_HEADER);

This will print to the KSP console (Alt+F12)

[richfiles]

struct vesselPointingMessage
#include <PayloadStructs.h>

A vessel orientation information message, including velocity orientation.
Public Members

float heading
Heading of the vessel (between 0 and 360, as indicated in the navball.
90 when pointing east, 180 when pointing south).

float pitch
Pitch angle of the vessel (between -90 and +90.
0 for an horizontal craft, +90 when pointing up, -90 when pointing down).

float roll
Roll angle of the vessel (between -180 and +180.
0 for a plane on the runway, ready to takeoff).

I'm trying to understand why the Heading (Yaw), Pitch, and Roll values here are done in entirely different scales and ranges here?

Heading is what I would have expected. 0-360 degrees. Simple. It's what the Navball shows.
Roll is... acceptable... -180 to +180 is still a 360 degree range. I can adjust for that...

Pitch though... -90 to +90 degrees? what even is this? It's only 180 degree range!? How do I even depict the other 180 degrees on my navball with half a rotation's worth of range? In space, vessels can be in retrograde, you know, and this pitch range does not seem to account for this. My original plan for my navball was to have three Arduino Minis handle each axis, doing the same calculations on just different parts of the data packet, but this... confuzzles me? 

How can this show the full range of a vessel's attitude if it doesn't encompass the full 360 degrees of pitch?

[Tetopia]

There now is a Simpit version for KSP2!

[Tetopia]

On 7/10/2023 at 9:04 AM, richfiles said:

I'm trying to understand why the Heading (Yaw), Pitch, and Roll values here are done in entirely different scales and ranges here?

Heading is what I would have expected. 0-360 degrees. Simple. It's what the Navball shows.
Roll is... acceptable... -180 to +180 is still a 360 degree range. I can adjust for that...

Pitch though... -90 to +90 degrees? what even is this? It's only 180 degree range!? How do I even depict the other 180 degrees on my navball with half a rotation's worth of range? In space, vessels can be in retrograde, you know, and this pitch range does not seem to account for this. My original plan for my navball was to have three Arduino Minis handle each axis, doing the same calculations on just different parts of the data packet, but this... confuzzles me? 

How can this show the full range of a vessel's attitude if it doesn't encompass the full 360 degrees of pitch?

Imagine you start heading 0 degrees with 0 pitch and then slowly pitch up until you have a pitch of 89 degrees. Then you keep rotating in this direction further than 90 degrees pitch. At this point your heading flips by 180 degrees and your pitch starts to decrease again, until you reach a pitch of 0 degrees at a heading of 180.

[richfiles]

On 2/23/2024 at 5:59 PM, Tetopia said:

Imagine you start heading 0 degrees with 0 pitch and then slowly pitch up until you have a pitch of 89 degrees. Then you keep rotating in this direction further than 90 degrees pitch. At this point your heading flips by 180 degrees and your pitch starts to decrease again, until you reach a pitch of 0 degrees at a heading of 180.

I get the logic behind it, if you're doing atmospheric flying, but it just feels like it'll make my life programming a physical navball very messy. 
I'll have to map those three differing variants of axes, including that one mashup of two axes, to three identical physical 360° rotational axes. Just not looking forward to that...

It's just that it's all a very flight oriented way to look at things, which is fine If your vessel's being built in the hangar. This is Kerbal Space Program, after all... When I'm in space, in a vessel I built in the VAB, I'm almost always working from an attitude based reference, not a heading based reference. In space, I can be pointed dead backwards, but my "heading" is still the exact same orbital path I was on already. I'm still hurtling away through space, along the same orbit, in the exact same "heading" as I was traveling before my attitude correction... I'm just in a retrograde attitude. In space, it's about the attitude in relation to said orbital path... your "heading", if you will. In space, I don't want my navball to show my heading at all. I want my attitude shown in relation to my heading, specifically, my orbital heading. The direction I point doesn't affect where the orbital heading that I'm referencing is until I actually initiate a burn and change my orbital path.

In the real world, having the navballs corrected to an orbital horizon reference instead of directly displaying relative gyroscopic heading was not actually considered till later in the development of the Apollo program, but was ultimately considered so critical, that in a vessel where every ounce counted, they literally strapped the ORDEAL (Orbital Rate Display Earth and Lunar) module and all it's electronics in box on the wall next to the "waste storage bags" and wired it into the navballs. They didn't have time to redo the main instrument panel, and they decided adding a heavy box and wiring wrapping half way around the command module was just that important!

Now I get to figure out my very own ORDEAL spaghetti code to fix my navball's reference. I somehow feel like I get the name...