Proximity Sensor For Switching Action Groups

[Azimech]

Want to go down in modding history as the one who brought a whole new dimension of gameplay into KSP? Then think about

The Proximity Sensor

With a proximity sensor you can do at least the following:

• Automatically open and close doors - great for cinematics!
  
  
• Switch lights on and off - again, great for cinematics! Imagine slowly drifting into this gigantic space station ... and the lights switch on down that corridor, one set at a time. Or even disco lights!
  
  
• Play a sound - or even build an instrument that plays a tune!
  
  
• Automatically Fire missiles & detonate mines
  
  
• Build yourself a dynamic pressure sensor: a plate connected to a spring. If the plate is moved backwards enough due to high dynamic pressure, some engines could be switched off until pressure drops enough and the engines switch on again.
  
  
• Build a crude mechanical computer
  
  
• Create a magneto - the thing that produces a spark at the right time, in the right cylinder, in an old fashioned piston engine.
  
  
• Security doors - they open for some but not for others! Great for multiplayer! You've got a ship in orbit and you don't want it commandeered by a different player? Lock the doors and take the right transmitter with ya!
  
  
• Many more things ... post your ideas!
  
  

Ideally such a system would have the following: One part is the sensor, which would have an ID to be set by the user. The other part is a transmitter. They can have a single ID or multiple ID's, to be set by the user.

The sensors would have options to

• Activate when coming into range, set between 1 cm and 2.5km
  
  
• De-activate when out of range, set between 1 cm and 2.5km
  
  
• Option to activate not the first but the second time, then reset
  
  
• Option not to deactivate when transmitter goes out of range
  
  
• Set to activate on a single transmitter ID, a group, a range or set to ignore a range
  
  
• Able to interface with action group managers.
  
  

This is an example of needing it badly but not knowing it until it's there.

Who would love to build it? And post what you would do with such a switch, the more ideas, the greater the chance someone will code it!

Edited February 24, 2015 by Azimech

[hab136]

This sounds like it would fit right in with Smart Parts (which already has a radio).

[Azimech]

There are some similarities, true. Then again, there are similarities with BD Armory as well. Maybe some code from either is usable.

[Azimech]

A friend of mine came up with another use: he wants to use it on his walking robots. This means: able to automate walking without kOS scripts.

[GusTurbo]

Great idea. I would love to see something like this. If I had the ability, I would do it myself.

[Yukon0009]

Welp, nice idea but I suck at modding- hell, just persistence file editing/CFG changes is annoying.

[Azimech]

Oh I can help with config files, if you need help, just yell :-)

[sarbian]

Welp, nice idea but I suck at modding- hell, just persistence file editing/CFG changes is annoying.

uh ? How are you doing it ? KSP handle most of the work once you use the proper tools. Post in the Dev help section if you have trouble

[Majorjim!]

Hey man, this is a great idea! I can think of a million applications for this but I have no idea how to write code for this..

Try sending a PM to some well known modders, they may be able to help you.

MJ

[Yukon0009]

uh ? How are you doing it ? KSP handle most of the work once you use the proper tools. Post in the Dev help section if you have trouble

I don't mod, but thanks anyways.

[katateochi]

This could be a really cool concept. I like it!

So is the idea (as I'm understanding it) to have two parts and have the trigger based of the distance between the parts? I could see uses for that, particularly as you've said in cinematic filming. But could it work with just a single part? Could the sensor part also work like a laser trip beam so that it could be triggered by the presence of any part, or the ground, or perhaps a hapless Kerbal walking into some horrific automated trap system!?

The two part idea is really nice for ship-ship interaction. having things like docking port covers open automatically as a ship approaches (and as you say having it so that only ships with the right ID on their transmitter would trigger that).

But I'd also really like ship-terrain interaction. for things like automatically lowering landing gears when approaching the ground, or sounding a proximity alert sound (I'm thinking of some extra aids to automate things when doing an IVA landing).

And if ship-terrain interaction was possible, ship-kerbal interaction would also be very cool (and not just for building Kerbal traps!). For cinematic things like a Kerbal walking along and having doors open automatically or having lights come on.

Anyway I think this is a great idea with some interesting potential to harm kerbals for interesting automation. Unfortunately I have no experience with writing mods for KSP (something I want to remedy).

[Stone Blue]

When docking, (especially manually), I always have to close solar panels, heat radiators, antennas, etc, before getting too close to another ship...My manual docking is sometimes laughable, and MechJeb sometimes likes to freak out and screw up docking...Too many times I have broken off antennas and solar panels with close calls...Also, having lights and docking bays/ports turn on and open would be handy as well...

[esinohio]

When docking, (especially manually), I always have to close solar panels, heat radiators, antennas, etc, before getting too close to another ship...My manual docking is sometimes laughable, and MechJeb sometimes likes to freak out and screw up docking...Too many times I have broken off antennas and solar panels with close calls...Also, having lights and docking bays/ports turn on and open would be handy as well...

I really liked your last idea there! Of course I can just switch to the other craft and turn everything on... but having it auto turn on via proximity would keep the stream of play a bit better. Help keep the illusion alive I think.

[Azimech]

It's not a two-part solution, the idea is to have a receiver that looks at a whole range of transmitter ID's. Could even have the following format:

ID 1 to 5: when in range activate action group 1 (further notation: #1-5 > +AG1)

ID 6: when going out of range, deactivate action group 9 (#6 < -AG9)

Now the rest:

#8 < -AG9, >-AG0

#9 < =AG9, >-AG1 >+AG3

#10-15 ignore

#16 ignore unless #8 is in range, >-AG1 if #9 is out of range

etc.

Not only that, it would be fun to have the ability to set certain transmitters to work as receivers as well!

This way you can ...

Automate a whole range of machines, even build a guidance system.

And have a bunch of robots doing a dance.

[Mad Rocket Scientist]

I hereby show my support for this idea.

[agent_0004]

I think i could get this done with Unity's Ray System. Pretty much the same way BD Armory works, The tricky part for me would be the Kerbal Integration. It might take me a bit to figure out all the different options inside kerbal i.e.(What to look for, how far away. That kinda thing) other than some bumps this should be a pretty smooth ride. PM me if you want me to help.

EDIT: Forgot to mention, this method should not require any parts or planets to be modified. just the prox sensor.

Edited April 24, 2015 by agent_0004
Derp moment

[z26]

This sounds nice, I think the lazor mod already has support to send a ray and mesure how far it gets before colliding. Maybe reverse engineer that? Integrating this with smartparts would be better than making this a standalone mod.

[Azimech]

I think i could get this done with Unity's Ray System. Pretty much the same way BD Armory works, The tricky part for me would be the Kerbal Integration. It might take me a bit to figure out all the different options inside kerbal i.e.(What to look for, how far away. That kinda thing) other than some bumps this should be a pretty smooth ride. PM me if you want me to help.

EDIT: Forgot to mention, this method should not require any parts or planets to be modified. just the prox sensor.

Excellent! I'll start drawing a schematic on my white board soon.

- - - Updated - - -

This sounds nice, I think the lazor mod already has support to send a ray and mesure how far it gets before colliding. Maybe reverse engineer that? Integrating this with smartparts would be better than making this a standalone mod.

As far as we know, development of Smart Parts has halted. I did suggest it to them but got no response and the topic is lying on it's back.

[agent_0004]

I could make the part scripts compatible with Smart Parts if you can find an up to date version of it. before it was compiled

- - - Updated - - -

I can start working on the code for the part when you finish the model.

[Whizzkid]

I like this idea!

[Diazo]

As it looks like I'll probably taking over Smart Parts at this point, I'm interested in looking at seeing the possibilities of this.

The biggest hurdle is that action groups are one-shot and proximity is an on-going status. I would look at the altimeter part for how to handle that probably.

The other thing is "Kerbal Integration" is mentioned earlier, using Smart Parts would not allow a Kerbal on EVA to trigger this as you would need a two Parts to create a distance between them.

The other-other thing is how to handle multiple sensors. It would probably be limited to only using the closest sensor. (On that channel of course so you can control which sensors activate each other.)

Thoughts?

D.

[Firov]

The biggest hurdle is that action groups are one-shot and proximity is an on-going status. I would look at the altimeter part for how to handle that probably.

The other-other thing is how to handle multiple sensors. It would probably be limited to only using the closest sensor. (On that channel of course so you can control which sensors activate each other.)

For those who haven't noticed yet, this feature has been added as part of the latest SmartParts, starting in v1.6.0. It's still a bit experimental, but feel free to give it a try and post any feedback. It works with multiple channels out to 2000 meters, and allows triggering actions on approach, departure, or either. Like the altimeter smart part, it's also able to reset/rearm itself.

In reference to Diazo's post above, this was definitely an interesting challenge to create. In the end, it turned into a bit of a hybrid of the altimeter and radio smart parts. Much like the radio, each proximity smart part registers itself to a globally accessible list, which allows easy detection by other proximity alarm parts without having to iterate through all local vessel part lists, which would add potentially crippling overhead for larger vessels (ie space stations). I also use this list to determine the channel the remote proxmity part is operating on. With this info, it's a relatively simple matter to iterate through the list and find the closest proximity sensor that's on the same channel as the local part, as well as it's distance and velocity relative to the local vessel (important for altimeter/trigger logic below).

From there, I wanted it to be able to trigger actions on approach, departure, or either, while also allowing the trigger to automatically reset. That last bit is the tricky part because, as Diazo pointed out, proximity to something, be it the ground or another ship, is a constant status. With the part having the ability to reset itself, you could potentially fire the action constantly when the distance conditions are met.

Ideally, you could fire at exactly the specified distance, but in practice, that's not possible due to floating point errors as well as the fact that KSP only calculates physics at a specific time interval, .02 seconds per frame, in my case. So you would almost certainly never actually hit the exact distance the part is looking for. The solution is to calculate a sliding window that scales based on the relative velocity between the ship and the target (ground or other ship) as well as the current KSP physics calculation time. The faster your ship moves, the larger the sliding window has to be in order to ensure that the action is triggered.

This window is then used in conjunction with the user configured target distance to establish the endpoints of the window. If the sensor detects that it's inside of this window, it triggers the action. The next physics frame, it recalculates the window, and upon discovering that it is now outside of the window, resets the smart part so it can be triggered again when it re-enters the calculated window, assuming that auto-reset is enabled. Fortunately, I'd already worked through all of this with my altimeter smart part (after much frustration), so I was able to just copy that logic for the proximity detector with a very minor rework.

[Qigon]

For those who haven't noticed yet, this feature has been added as part of the latest SmartParts, starting in v1.6.0. It's still a bit experimental, but feel free to give it a try and post any feedback. It works with multiple channels out to 2000 meters, and allows triggering actions on approach, departure, or either. Like the altimeter smart part, it's also able to reset/rearm itself.

In reference to Diazo's post above, this was definitely an interesting challenge to create. In the end, it turned into a bit of a hybrid of the altimeter and radio smart parts. Much like the radio, each proximity smart part registers itself to a globally accessible list, which allows easy detection by other proximity alarm parts without having to iterate through all local vessel part lists, which would add potentially crippling overhead for larger vessels (ie space stations). I also use this list to determine the channel the remote proxmity part is operating on. With this info, it's a relatively simple matter to iterate through the list and find the closest proximity sensor that's on the same channel as the local part, as well as it's distance and velocity relative to the local vessel (important for altimeter/trigger logic below).

From there, I wanted it to be able to trigger actions on approach, departure, or either, while also allowing the trigger to automatically reset. That last bit is the tricky part because, as Diazo pointed out, proximity to something, be it the ground or another ship, is a constant status. With the part having the ability to reset itself, you could potentially fire the action constantly when the distance conditions are met.

Ideally, you could fire at exactly the specified distance, but in practice, that's not possible due to floating point errors as well as the fact that KSP only calculates physics at a specific time interval, .02 seconds per frame, in my case. So you would almost certainly never actually hit the exact distance the part is looking for. The solution is to calculate a sliding window that scales based on the relative velocity between the ship and the target (ground or other ship) as well as the current KSP physics calculation time. The faster your ship moves, the larger the sliding window has to be in order to ensure that the action is triggered.

This window is then used in conjunction with the user configured target distance to establish the endpoints of the window. If the sensor detects that it's inside of this window, it triggers the action. The next physics frame, it recalculates the window, and upon discovering that it is now outside of the window, resets the smart part so it can be triggered again when it re-enters the calculated window, assuming that auto-reset is enabled. Fortunately, I'd already worked through all of this with my altimeter smart part (after much frustration), so I was able to just copy that logic for the proximity detector with a very minor rework.

Very cool!

Is there a chance to use that to trigger kis explosives? For... reasons....