Sensor Reporter for kOS

[woodywood245]

I would actually like more sensors for kOS.

now.. if only there was a rangefinder and this could grab the data from that...

Exactly. Throw in a sonar and a weight/touch sensor and we are golden.

I haven't made any official announcements about this, but I am actually working on a project to solve the not-enough-science issue. While the 0.22 update was great, I still prefer using sandbox mode, and so most of the new things don't affect me. As a result, I've started creating new sensors and science instruments that do actual science, with real data.

So far I have one sensor completely written, modeled, and tested. I will be releasing the parts as I build them, packaged together in one mod, and they will be Science Reporter compatible.

The current part I have built is a dynamic pressure sensor, which I built specifically to work with kOS, so that you could easily find your max Q, but it still works like an ordinary sensor also.

Parts I have planned, or have already written (but not modeled and tested):

• A long-distance laser rangefinder, with accompanying retroreflector. Attach a retroreflector to a vessel, send it to the Mun or something, then use your long-distance rangefinder, and it will tell you the distance. This is intended to be similar to the Lunar Laser Ranging experiment.
  
• A spectrometer for determining the contents of an atmosphere. At the moment, it's only written to determine if there's oxygen present, but I am hoping to expand that significantly in the future.
  
• A seismometer. When on, and on solid ground, this sensor will detect seismic activity. For the sake of not boring the pants off of users, quakes happen much more often than you'd expect. However, I've added some low-level noise for realism.
  

Those are what would be in the first two or three releases, depending on how quickly things get finished. The list of things I'd like to add go on from there. If you guys are really interested in a mod like this, I will create a thread for it, and we can discuss what kind of sensors and instruments you'd like to see added.

I have another couple mods in the works, but things aren't quite ready to be talked about yet, in case they fall through.

[Volt Cruelerz]

I haven't made any official announcements about this, but I am actually working on a project to solve the not-enough-science issue. While the 0.22 update was great, I still prefer using sandbox mode, and so most of the new things don't affect me. As a result, I've started creating new sensors and science instruments that do actual science, with real data.

So far I have one sensor completely written, modeled, and tested. I will be releasing the parts as I build them, packaged together in one mod, and they will be Science Reporter compatible.

The current part I have built is a dynamic pressure sensor, which I built specifically to work with kOS, so that you could easily find your max Q, but it still works like an ordinary sensor also.

Parts I have planned, or have already written (but not modeled and tested):

• A long-distance laser rangefinder, with accompanying retroreflector. Attach a retroreflector to a vessel, send it to the Mun or something, then use your long-distance rangefinder, and it will tell you the distance. This is intended to be similar to the Lunar Laser Ranging experiment.
  
• A spectrometer for determining the contents of an atmosphere. At the moment, it's only written to determine if there's oxygen present, but I am hoping to expand that significantly in the future.
  
• A seismometer. When on, and on solid ground, this sensor will detect seismic activity. For the sake of not boring the pants off of users, quakes happen much more often than you'd expect. However, I've added some low-level noise for realism.
  

Those are what would be in the first two or three releases, depending on how quickly things get finished. The list of things I'd like to add go on from there. If you guys are really interested in a mod like this, I will create a thread for it, and we can discuss what kind of sensors and instruments you'd like to see added.

I have another couple mods in the works, but things aren't quite ready to be talked about yet, in case they fall through.

While I'm not opposed to what you listed off, what I was referring to was something more short range, like a form of sonar (obviously only works if there's atmosphere) that comes in long range (integer precision and a max range of ~500m), medium range (single precision with a max range of 50m), and short range (double precision with 5m range). Perhaps a more advanced version later in the tree would be justified as working with radar or stereoscopic vision that has longer range and/or doesn't require atmosphere. Things that work on a finer level than existing systems and give you measurements from a non-standard location for applications like hovering or docking.

[woodywood245]

While I'm not opposed to what you listed off, what I was referring to was something more short range, like a form of sonar (obviously only works if there's atmosphere) that comes in long range (integer precision and a max range of ~500m), medium range (single precision with a max range of 50m), and short range (double precision with 5m range). Perhaps a more advanced version later in the tree would be justified as working with radar or stereoscopic vision that has longer range and/or doesn't require atmosphere. Things that work on a finer level than existing systems and give you measurements from a non-standard location for applications like hovering or docking.

That would indeed be very handy. I was planning a short-range laser ranging system, but I am open to other systems as well.

[Camacha]

While I'm not opposed to what you listed off, what I was referring to was something more short range, like a form of sonar (obviously only works if there's atmosphere) that comes in long range (integer precision and a max range of ~500m), medium range (single precision with a max range of 50m), and short range (double precision with 5m range). Perhaps a more advanced version later in the tree would be justified as working with radar or stereoscopic vision that has longer range and/or doesn't require atmosphere. Things that work on a finer level than existing systems and give you measurements from a non-standard location for applications like hovering or docking.

This is pretty much what I was getting at. I think KSP, kOS, Sensor Reporter and probably soon Infernal Robotics are an amazing combination if you enjoy robotics, science and space. Now flying is great, but when you try to do any type of accurate movement or anything with a rover, you will quickly find there is a distinct lack of options when it comes to those things.

The other day, I send two rescue rovers to a mishap. Without sensors or an elaborate system in which they all report to each other where they are, colisions are bound to happen. It would be very nice to have realistic short range and medium range detection capabilities, with each their strengths and weaknesses. That is what my inner engineer wants to do. That way you can accurately measure whether your skycrane landing site has a suitable slope gradient, instead of guestimating it and hoping for the best.

O yeah, I was wondering: is it possible to use expressions that are more in line with kOS? I got them working at the moment, but each time I need one I have to look at a previous one I did because the syntax is less than obvious.

[woodywood245]

O yeah, I was wondering: is it possible to use expressions that are more in line with kOS? I got them working at the moment, but each time I need one I have to look at a previous one I did because the syntax is less than obvious.

Are you referring to the exclamation marks being used for namespaces? Or something else?

[Camacha]

Are you referring to the exclamation marks being used for namespaces? Or something else?

That is one of the things, yes. The brackets() at the end can also be confusing in long calculations with lots of brackets and grouping. Ideally it would just be something like

gravimeter on.

laser on.

usonic on.

set dist:laser to range1.

set dist:usonic to range2.

I do not have a clue how that would work from a technical point of view, but I know that would be easiest from a user standpoint.

[woodywood245]

That is one of the things, yes. The brackets() at the end can also be confusing in long calculations with lots of brackets and grouping. Ideally it would just be something like

I do not have a clue how that would work from a technical point of view, but I know that would be easiest from a user standpoint.

I would LOVE to be able to do those things, but unfortunately, I'm limited by kOS.

In versions of Sensor Reporter prior to 1.3.2 (the kOS 0.9x compatibility release) all of the functions used colons, as it fit in with the kOS code well. However, the expression system for kOS was changed in version 0.9, and the colon became an operator for internal namespaces. As a result, kOS is unable to recognize that sensor:grav() is an external function (external functions are stored as strings). Instead, it looks for the namespace "sensor", and doesn't find it. Earlier versions didn't use this method, and so I was able to get away with using colons.

// Using colons in kOS 0.8 and earlier.
print sensor:grav().
> 9.80695477026689

// Using colons in kOS 0.9
print sensor:grav().
> Unrecognized term: 'sensor'.

As far as the parentheses are concerned, all function calls require the use of parentheses. It's a convention of almost every programming language, and it's a technical requirement of kOS. Without the parentheses, kOS doesn't know that you're trying to make a function call, and thinks you're looking for a variable.

print sensor!grav.
> Unrecognized term: 'sensor!grav'.
print sensor!grav().
> 9.80695477026689

One advantage of kOS is that the language is freeform, meaning that whitespace (usually) doesn't matter. As a result, if you're having too difficult a time working with complex formulas, you can try breaking them up onto separate lines. You may also consider using an editor that highlights matching braces as you type them in, such as Notepad++ (I use Notepad++ with a kOS syntax highlight definition I made). Lastly, you may want to enter sets of brackets together, then write their contents on the inside. Some programmers use that technique in C-like languages, where braces of all kinds are commonplace.

For example, when I write an if-statement, I usually do this:

if [condition]
{
}

if [condition]
{
// now i write my code here
}

Maybe you could do a similar thing with parentheses? I don't know if I could (I'm accustomed to remembering how many I need and when), but maybe it's worth a shot. Another technique that I use when I can't tell for sure if all of my braces match is to count them on my fingers. I add a finger when I have an open brace, and remove one when I have a closing brace. If I get to the end of the statement or block and have zero braces, I know everything's closed. If I have an extra close brace, I know I'm missing an open, and if I have fingers up, I know I'm missing that many close braces.

Edited November 19, 2013 by woodywood245

[Camacha]

I feel a tilt sensor should also come in handy. I did some research on the heading and bearing commands in kOS, but I think calculating tilt is not yet possible, not without using funky trickery like utilizing a couple of other crafts as known reference points or something at least.

As far as the parentheses are concerned, all function calls require the use of parentheses. It's a convention of almost every programming language, and it's a technical requirement of kOS. Without the parentheses, kOS doesn't know that you're trying to make a function call, and thinks you're looking for a variable.

As a user, I am looking for a variable. I understand the technical difference, but for a user it is not very different from asking for the altitude. I guess it comes down to working with what you've got vs. user ease and a consistent language for all calls and functions.

I guess it would be possible if one was to merge your code into Kevin's?

Maybe you could do a similar thing with parentheses? I don't know if I could (I'm accustomed to remembering how many I need and when), but maybe it's worth a shot. Another technique that I use when I can't tell for sure if all of my braces match is to count them on my fingers. I add a finger when I have an open brace, and remove one when I have a closing brace. If I get to the end of the statement or block and have zero braces, I know everything's closed. If I have an extra close brace, I know I'm missing an open, and if I have fingers up, I know I'm missing that many close braces.

Oh, I always get it working in the end, but say one out of five times things do not work as intended, I have to split the whole thing up into bracket groups and see where I made the mistake. It is usually in math bits like ((maxthrust - (mass * sensor!grav())) / mass). It is not impossible, just confusing at times.

Please do not take this post as complaining, I am just trying to consider the experience from the user point of view

[woodywood245]

I feel a tilt sensor should also come in handy. I did some research on the heading and bearing commands in kOS, but I think calculating tilt is not yet possible, not without using funky trickery like utilizing a couple of other crafts as known reference points or something at least.

Actually, calculating tilt is fairly simple with a little math.

You can calculate the difference between two vectors using the geometric definition of dot product of vectors: A·B = |A||B|cosθ, where A and B are vectors and θ is the angle between them.

Rewriting, the equation becomes (A·B)/|A||B|= cosθ. Solving for θ, you get θ = cos^-1((A·B)/|A||B|).

If a vector, V, is represented as V=<x,y,z>, then A and B can be represented as A=<x₁,y₁,z₁> and B=<x₂,y₂,z₂>. Therefore A·B = x₁x₂ + y₁y₂ + z₁z₂.

Now, using the UP vector for A, and the FACING vector for B, we can translate this into:

set a to up:vector.
set b to facing:vector.

set dotprod to (a:x * b:x) + (a:y * b:y) + (a:z * b:z).
set tilt to arccos(dotprod / (a:mag * b:mag)).
print tilt.

Alternately, you can calculate the dot product by multiplying the two vectors together using the kOS component-wise multiplication, then adding the components together.

set c to a * b.
set dotprod to c:x + c:y + c:z.

This runs under the assumption that pointing straight up is 0 degrees tilt, and pointing sideways is 90 degrees tilt. Tilt values over 90 degrees mean you're pointed towards the ground.

Edited November 25, 2013 by woodywood245
Changed x to theta and asterisk to dot. Added algebraic calculation of dot product.

[Camacha]

Now, using the UP vector

I totally overlooked the UP-vector, as I always set a predetermined angle and have no experience with UP. I have refrained from looking any further at your explanation, as I like to work things out myself as much as possible. This should make some interesting things possible though!

Edited November 25, 2013 by Camacha

[woodywood245]

Sensor Reporter 1.4 is out!

http://kerbalspaceprogram.com/sensor-reporter-kos/

As of version 1.4, kOS 0.7 is no longer being supported. All single-precision returning functions have been removed. Do not use sensor!____f() functions anymore; they won't work.

On the upside, I've added four new math functions, and a new vessel function:

math!log(number) - returns the base-10 logarithm of the given number.

math!logb(number, base) - returns the logarithm of the given number of the given base.

math!ln(number) - returns the natural logarithm of the given number.

math!e() - returns the natural log base constant e.

vessel!isp() - returns the sum of specific impulse of all active engines.

Also, I've moved all non-sensor functions to a PartModule called kOSExtensions. These functions are available regardless of whether you have any sensors on the spacecraft. Sensor functions are still only available if you add the appropriate sensors.

[Camacha]

vessel!isp() - returns the sum of specific impulse of all active engines.

Is it the rated ISP or an actual measured ISP?

[woodywood245]

Is it the rated ISP or an actual measured ISP?

I believe it is the measured Isp. The number that comes out is the same as the one in the engine's context menu.

[goldenpeach]

I have a little problem: I can't use the gravioly detector.

When I write:

print sensor!grav().

the terminal ouput this:

Unrecognized term: 'sensor!grav()'

What I have done wrong?

Edited December 5, 2013 by goldenpeach

[woodywood245]

I have a little problem: I can't use the gravioly detector.

When I write:

print sensor!grav().

the terminal ouput this:

Unrecognized term: 'sensor1grav()'

What I have done wrong?

That is an excellent question. It says "sensor1grav()" instead of "sensor!grav()" on the output?

[goldenpeach]

Oops...

It's my mistake: it say "sensor!grav().

I edited my post to remove the mistake.

[woodywood245]

I have a little problem: I can't use the gravioly detector.

When I write:

print sensor!grav().

the terminal ouput this:

Unrecognized term: 'sensor!grav()'

What I have done wrong?

This kind of problem crops up occasionally for me, and I'm not entirely sure what the root cause is. But, to assist with figuring it out, what version of kOS are you using? Also, are you using the latest version of Sensor Reporter (v1.4)? And lastly, if you are, you can hit Alt+F2, and that will bring up the Debug Console. Sometime along the list after the vessel load, you should see a series of external function registrations. It will look like this:

[LOG 17:14:57.845] stage manager starting...
[LOG 17:14:57.845] all systems started
[LOG 17:14:57.907] Adding math!pi
[LOG 17:14:57.907] *** External Function Registration Succeeded
[LOG 17:14:57.908] Adding math!log
[LOG 17:14:57.908] *** External Function Registration Succeeded
[LOG 17:14:57.908] Adding math!logbase
[LOG 17:14:57.909] *** External Function Registration Succeeded
[LOG 17:14:57.909] Adding math!ln
[LOG 17:14:57.910] *** External Function Registration Succeeded
[LOG 17:14:57.910] Adding math!e
[LOG 17:14:57.911] *** External Function Registration Succeeded
[LOG 17:14:57.911] Adding vessel!velocity
[LOG 17:14:57.912] *** External Function Registration Succeeded
[LOG 17:14:57.912] Adding vessel!gravconst
[LOG 17:14:57.913] *** External Function Registration Succeeded
[LOG 17:14:57.913] Adding vessel!isp
[LOG 17:14:57.914] *** External Function Registration Succeeded

Hopefully, somewhere in the log, it will say:

[LOG 19:15:49.956] Adding sensor!grav
[LOG 19:15:49.957] *** External Function Registration Succeeded
[LOG 19:15:49.957] Adding sensor!grav!str
[LOG 19:15:49.958] *** External Function Registration Succeeded
[LOG 19:15:49.958] Adding sensor!grav!toggle
[LOG 19:15:49.959] *** External Function Registration Succeeded
[LOG 19:15:49.959] Adding sensor!grav!active
[LOG 19:15:49.960] *** External Function Registration Succeeded

If "Adding sensor!grav" does not show up, let me know. Alternately, you can send me the log (via email or something, you can PM me for that), and I can analyse it.

[goldenpeach]

Avery lines you are talking about are there.

However, after the line ***External Function Registration Suceeded there is this text(in red): [Exception]: NullReferenceException: Object reference not set to an instance of an object

There is this red text after the "***External Function Registration Succeeded" for every line involving the gravioly.

I downloaded the plugin yesterday(4 december,if we don't live in the same time zone) so I think I have the latest version, and I use the version 0.9 version of KOS.

Let me know if you need more informations!

[woodywood245]

Avery lines you are talking about are there.

However, after the line ***External Function Registration Suceeded there is this text(in red): [Exception]: NullReferenceException: Object reference not set to an instance of an object

There is this red text after the "***External Function Registration Succeeded" for every line involving the gravioly.

I downloaded the plugin yesterday(4 december,if we don't live in the same time zone) so I think I have the latest version, and I use the version 0.9 version of KOS.

Let me know if you need more informations!

I'm pretty sure the problem is on the kOS end of things, and not on the Sensor Reporter end. The architecture of my mod is quite simple, but sometimes it has problems interfacing with kOS. I will dig into the kOS source and see if there's something wrong with the function registration code that is causing this problem. Unfortunately, the issue is intermittent, which makes it difficult to track down. Sometimes I've been able to fix it by reverting to launch, and sometimes by restarting KSP itself.

[woodywood245]

Avery lines you are talking about are there.

However, after the line ***External Function Registration Suceeded there is this text(in red): [Exception]: NullReferenceException: Object reference not set to an instance of an object

There is this red text after the "***External Function Registration Succeeded" for every line involving the gravioly.

I downloaded the plugin yesterday(4 december,if we don't live in the same time zone) so I think I have the latest version, and I use the version 0.9 version of KOS.

Let me know if you need more informations!

Ok, I think I figured out how this happens. In short, and without getting too technical, it has to do with the order that you put parts on. If you put kOS on first, then your sensors, everything is fine. If you do it in the opposite order (sensors, then kOS), your sensors will not be available in kOS.

I might be able to create a workaround in Sensor Reporter, I'm not sure.

[goldenpeach]

It make sense:I put the gravioly to "test" the plugin(or rather to test my capability to use it:)) so I placed it first.

Then,when I saw it wasn't working, I put the other sensor to see if they would have the same problem!

Thank for the help!

[Camacha]

I noticed a problem where the Gravioli Detector would sometimes not work. The solution would be to return to the VAB, delete the parts and attach a new one. It might very well be the same problem.

It happend on vehicles that worked fine before, but I am not too sure whether I might have edited in between.

I believe it is the measured Isp. The number that comes out is the same as the one in the engine's context menu.

Great! Although I really do not like to query things that could not be measured in real life, this could come in handy.

Although it's probably be a but rude to ask for something like this just after a release, might it be possible to add measured engine thrust to Sensor Reporter? That is something that could actually be measured in real life - through sensors in the engine mount or engine - and it could be very useful for things like detecting flameouts or use in any equasion that needs thrust.

[goldenpeach]

I did that and it worked!

Now, I will make a program to find the gravitation constant of KSP(I know I can find it by using a function of the plugins but I want to find it by myself(and code it)).

Thank you for the help!

[John FX]

This seems like a very useful mod for getting real figures, like the gravity of the body you are on. I only downloaded KOS a couple of days ago and I am trying to do an automated Mun mission. Got into a circular orbit, now I just need to locate the mun and burn at the right time...

[woodywood245]

I did that and it worked!

Now, I will make a program to find the gravitation constant of KSP(I know I can find it by using a function of the plugins but I want to find it by myself(and code it)).

Thank you for the help!

No problem. I'm working on a 1.4.1 or 1.5 release (I'm not exactly sure how much I'm going to put into it yet) and I've coded a fix into Sensor Reporter that hopefully will make it so that it won't matter what order you place them in. I still have to test it though.