Sensors, coils, magnets

[Azimech]

I like the KAL-1000. But I must admit, I've never used it before. The thing always felt as "unfinished".

Almost 5 years ago I needed some way of having an ignition system for my piston engines. I did it using scripts, using libraries to create sensors, transistors, and capacitors. It worked but I halted development.

While piston engines are not the scope of KSP, hear me out. IMHO the problem with the KAL-1000 is that it can't use sensors like the angle of a robotic arm, the distance to a different part, energy levels, temperatures, the distance to the ground, the angle of a surface, difference in the amount of light etc. All RL robots use sensors, all we have is a timing based system.

Coils and magnets: wouldn't it be nice to be able to build generators and motors? Could be simplified like the thermal system. Just omit some factors. Could be as easy as using an electric motor supplying energy when being driven, like a lot of them do in real life.

This shouldn't be part of the base game to raise difficulty. Don't want to use it? No problem, you can "complete" the game.

Thoughts?

[Dientus]

I wouldn't be against it, but is this similar to this thread?

 

Or where you thinking of something different?

 

[K^2]

This might get merged, but it does kind of feel like it can be a separate topic, so I'm going to reply here.

One thing that I would really like to see is sensors we can use as an axis similar to how the KAL-1000 works. Like, if you pop a barometer (pressure sensor) on the ship, it should show up as an additional axis in the action group list. Then if I add a KAL-1000 onto it, I can effectively pass the pressure data through a curve to drive an output or trigger actions based on some threshold.

That seems like it'd be very easy to implement, would allow meaningful addition of other sensors, like accelerometers and gyros, and it would allow for some very interesting builds without introducing the complexity of fully scriptable system. In fact, I kind of want to see this in stock KSP and maybe that can drive a lot of discussion of what that would look like in KSP2. Because we technically haven't even heard anything about the state of robotics in stock KSP2.

[Dientus]

That was my thought, not that I'm more than a hobbyist mind you, but if it's at that level it does seem easy to implement into existing framework. (No not an echo I promise!)

 

Of course first thing in my mind is what kind or how many sensors? New ones like altimeters or gyroscopes? (Which I personally would love) or just the science sensors we have now like barometer or temperature?

 

I see in my minds eye a failsafe to be sure a probe extends landing gear, or maybe at Pe, record and transmit science. Things like that.

 

Edited March 8, 2021 by Dientus
spelling

[K^2]

10 hours ago, Dientus said:

Of course first thing in my mind is what kind or how many sensors? New ones like altimeters or gyroscopes? (Which I personally would love) or just the science sensors we have now like barometer or temperature?

There is a lot you can do with existing sensors. Like, if you are on Kerbin and you need to get altitude, you can make an inverse pressure curve in KAL-1000, feed barometer reading to it as scrub position, and you'll get altitude on the output. Yes, only relative to sea level and only within the atmosphere of a specific body, but it's a great start.

Likewise, an accelerometer fed into the play rate input of the KAL-1000 can be used as an integrating accelerometer. Infamously, a pair of gyros and a single integrating gyro accelerometer comprised the guidance of the V2 rockets, so you can do quite a bit with this.

Of course, this is invention out of necessity, and it'd be easy enough to add a few extra sensors to make things a lot easier. A barometer might as well have a direct pressure-altitude readout that adjusts for whichever body you're on, provided it has atmosphere, of course. Gyros seem like a must. Ground radar can work great to give you altitude, up to a limit, relative to ground on any planet or moon.

I am a bit less confident about something like GPS. Without having to build a constellation, it feels overpowered, and making something that works with arbitrary constellations a player might build becomes far more complex than simple sensors we are talking about. But since we are talking about KSP2, there is a piece of proposed tech that gives you GPS-like capability anywhere in the galaxy. Pulsar navigation is still very much in experimental phase, but it can, in theory, get you precision to within a few hundred meters anywhere you might reasonably end up going. And since it uses pulsars that nature was gracious enough to place for us already, it requires no special construction. Just a set of x-ray sensors and some analysis software to count the pulses and do the math.

[Dientus]

13 minutes ago, K^2 said:

 

Likewise, an accelerometer fed into the play rate input of the KAL-1000 can be used as an integrating accelerometer. Infamously, a pair of gyros and a single integrating gyro accelerometer comprised the guidance of the V2 rockets, so you can do quite a bit with this.

Xactly! Yes these sensors very much on the wish list! Of course, we start moving into rudimentary autopilot if we can read and make our crafts react to sensors like these. 

 

I like the thought of building radar stations on a planetary body to make sensors more accurate to a given location. But for sake of gameplay over tedium, I would imagine one per stellar body of sufficient size would suffice?

[K^2]

31 minutes ago, Dientus said:

I like the thought of building radar stations on a planetary body to make sensors more accurate to a given location. But for sake of gameplay over tedium, I would imagine one per stellar body of sufficient size would suffice?

For games like KSP, I kind of like the approach of things working correctly under the hood, and then presentation gets simplified for the player. Like, when you are running a rocket engine in the game, it needs to be fed oxidizer and fuel and will give you different thrust depending on the fuel flow and external pressure. But what you, as a player, get presented with, is just a throttle axis that you set as percentage of maximum thrust under given conditions. The game figures out for you where the engine should get fuel and oxidizer from and how much.

In a similar vein, if we had some sort of a method for combining sensor readings to improve quality, I would probably expect the game to solve it correctly, such as by using Kalman filter, but that can be done completely in the background. As a player, all you should see is that if you collect more data, you get better precision.

Of course, there is still a matter of when and what data should be combined. A classical use case in robotics is combining range-finders and accelerometers when you want to keep track of position and velocity. This sort of goes back to the GPS discussion above. Roughly speaking, if you have a GPS or similar distance-based measurement of your position, you can look at changes of position over time and compute your velocity. Because you are taking multiple measurements, you can have very precise measurement of your velocity even with significant uncertainty of position. So a GPS might only get your position within a few tens of meters, but it will track your velocity to within a fraction of a meter per second quite easily, because it will measure your position a bunch of times and take an average. Problem is, this kind of measurement takes a while to respond to any changes. Clear on the other side, you can measure accelerations and adjust velocity estimates rapidly. Problem is that the errors in this measurement accumulate over time, so if you try to measure velocity only from accelerometers, the result will drift over time. So the solution is you combine the two inputs, again, with something like Kalman filter. That can give you very precise velocity measurements that are stable over time and respond instantly to any acceleration.

For the game, I suppose, this could be presented as a purely inertial navigation unit to begin with, which can only be so precise, and then can be "upgraded" by placing more and more satellites or ground stations to augment the position and velocity readings. That seems like a reasonable option to do something like this.

 

Clear on the other side, of course, is the DIY approach. If we get scripting or some other means of performing algebraic and logical operations on sensor input, then it could be an interesting challenge to build your own filters for collecting and combining data from multiple sources. That does, however, start crossing into a different kind of game.

[Dientus]

I think I see... as a compromise between over simplified and over complicated while trying to stay true to realism within reason.  I think that may not be too bad. I think I could get behind that.

 

Depending on how others feel, level of depth could be a simple choice option as well... maybe a choice between "realistic" and "kerbalistic" to try to appeal to more types of players who may not want in depth placement of satellites or stations?