togfox

So after many weeks working on a Terrain Avoidance System, I have finally made a crude demonstration that it can work. Terrain Avoidance System I need to adjust it for a lander 'falling' from a high orbit, and then test it out on different bodies. I welcome all comments, encouragement, refined code, better algorithms or anything else that will help my unattended probes land on foreign and unexplored lands.

I suspect Romfarer's lasers has a means to do range-finding if one dived into the code, but that technology is beyond me, so for now, this crude means of terrain prediction will have to do until a clever duck comes along, or the game engine somehow changes.

So has kos reached the point where a fully automated mun mission can be coded nasa style? Can kos do gravity turns, circularisation burns, determine transfer points, burn for x seconds etc. I think the start and end parts of a mission like that is do able (go to orbit and land), but can kos determine burn points? Can it access the universe time so burn points can be preprogrammed?

The Fox Terrain Avoidance System v1 A script that uses the kOS onboard computer mod Disclaimer: This is an experimental script that uses the kOS mod. You must have the kOS mod installed for this script to work. This script is not a stand-alone part or plug-in. This script currently only works for ground based vehicles and is offered here for demonstration purposes and to foster discussion, collaboration and inspiration. This post has a lot of words because it is explaining what the script does and encourages discussion on how to make it better. The FTAS is a script that is loaded into the kOS part and runs within the kOS environment. Right now it only works on ground vehicles but it demonstrates that terrain avoidance for craft landing on the Mun or other body can exercise a level of ground avoidance reasonably reliably. This script demonstrates that a ground vehicle can be automatically controlled, without any intervention, to seek flat terrain and to stay on and within the vicinity of flat terrain - a crucial ability for any landing vessel that does not want to tip over! Here is where I talk about the theory of the FTAS system. In brief, the game engine does not allow any craft to evaluate the terrain in front of it, but the script constantly monitors the height of the terrain directly below it and the height of the terrain a few meters behind it. By doing this, the vessel constantly evaluates the changing nature of the terrain. If the terrain immediately below it is the same height as the terrain a few metres behind it, then there is a good chance the vessel is over flat terrain and a landing is acceptable. If the terrain varies by a large degree, the vessel is probably positioned over a steep slope and a change direction is required. If the vessel continues changing direction and continues scanning for flat terrain, it will eventually find an acceptably flat plateau to land on. In this demonstration, I have a rover running the FTAS on board with mechjeb keeping the rover at a constant 9 m/s. The rover has found a flat depression and no matter how many times it approaches the lip of the depression, it decides it should not leave the grasslands it is on, turns around, and returns to the centre of the depression. Youtube of my development version with random debug information on the screen: The green line shows the path the rover has taken. I had the screen capture running for a long time and there are a lot of green lines and the rover stays contained within the depression. If this were a lander looking for a landing spot, I'm very confident it would have stayed within the boundary of the depression during the descent and would have landed safely on the grasslands and not on the hills beside it. The algorithm is not perfect and not 100% efficient. Because it can't see in front or to the sides, it only knows the level of the terrain behind it. There is an assumption that the terrain in front of the craft is more or less the same as the terrain behind the craft. In most cases, this is true, but very irregular and sharp slope changes can confuse the script. Also, when a terrain change is needed, it doesn't know if it should turn left or right. It needs to guess and then take another terrain "probe". If the terrain is going up and not down, then its guessed wrong and turns around 180 degrees. For this reason, the script will always seek the lowest possible flat terrain. If there is a flat ledge halfway up a slope, the script will likely skip over that and continue to seek flat terrain at the foot of the mountain, sometimes right next to the mountain. The 'probe' only works in 2 dimensions - that is, one axis of travel. The craft can travel perfectly parallel along a very steep slope and it will think its on flat land. The reason why this doesn't matter much is for two reasons: a) it is very difficult and very unlikely for a craft to travel perfectly parallel for any amount of time. Thrust variance and natural ship wobble, drift means the direction of travel is constantly changing - even if by a little bit. in most cases, a change in gradient in one direction also means a change in gradient in all other directions, meaning, a lot can be concluded by measuring terrain in only one axis. I invite ideas, discussion, proposals and test scripts that can help address some of these deficiencies. Here are some (dark) screenshots showing the path the rover has taken: Screenshot #1 screenshot #2 Here are the scripts you can try out. Feel free to: - use these scripts privately any way you like; - repost modified/improved scripts crediting myself FTAS Rover v1.zip To use - open a kOS terminal and execute the following copy ftasrover from archive. run ftasrover. Ensure your ground vehicle is moving forward. Thanks to: Kevin Laity for creating the initial kOS plugin; erendrake for continuing the development of kOS; Steven Mading for being my most thoughtful critic and offering the most sound technical advice; Zephram Kerman for being my sounding board;

So is there a random function now and how would I use it. Do you mean it is in the release or it is not? random(min, max) rnd() rand() Cheers n beers. Since its Friday, especially beers ...

Random ()? Thanks. Nice work.

Poker game? Slot machine? craps (dice) game? I'm exploring a pathfinding script and if my rover bumps up against a building, landed vessel or mun arch then it needs to reverse and then turn a random number of degrees left/right. Just like those battery toys you played with when you were knee high.

Next question - random numbers. Is there a genuine random number function and if not, can I make a substitute - like the div/mod of the first decimal point in "seconds" component of the universal time or some such? I've adopted that technique in other languages and that tends to be random enough.

Another suggestion - make it impossible to delete files from archive. Is there an in-game reason to want to delete from archive? Is that needed for run time script writing/running on the fly? (lucky I've got backups!!).

My bacteria stuff is geared for 0.22 and a lack of interest means it stayed there. Happy to update it if there is interest. I'm hoping a modeller can making a Viking like soil scoop that can collect bacteria samples that can return science.

How do I determine compass heading from eular notation?

The script you provided is for a launch - but I was after a landing. Fear not, I took the important bits and made a rather smooth landing script thanks to you. set newtwr to 1. until alt:radar < 5 { run calculateTWR (newtwr). if verticalspeed > -1 { set newtwr to newtwr - 0.010. } //if verticalspeed is too positive (going up) then reduce thrust. if verticalspeed < -2.5 { set newtwr to newtwr + 0.010. } //if vertical speed is too negative (dropping too fast) then increase thrust. if verticalspeed >= -1 and verticalspeed >= -2.5 { set newtwr to 1 }. //This line resets the thrust if it gets too extreme } And your unmodified calculateTWR.txt declare parameter desiredtwr. set g to 9.81. set t to ship:maxthrust. set w to ship:mass. set twr to t / (w * g ). //print "twr = " + twr. set thrustLevel to desiredtwr / twr. This sets a vertical speed between 1 and 2.5. I aim for a landing speed of 2.0 so this provides a little tolerance each side. Not super smooth and not as precise as MechJeb - but it fits my purposes. Thx.

so if I do this: set c to 310. // compass heading, i.e. 0=north,90=east,180=south,270=west. set p to 20. // pitch, i.e. -90=down,0=horizon,90=up. lock steering to heading c by p. Then my craft will turn as expected. However, if I follow with this: print heading. I get the value 0. I'm expecting 310 - and the navball in game says 310. What am I not getting?

Thanks for the tips on memory management. I am writing very complex code for something that has never been attempted (to my knowledge) and yes - my code could be refactored, but right now I'll reduce my comments and abbreviate all my variables to two letters so I fit within the style others are forcing upon me. (Just making a point. I really like this mod and I appreciate the efforts of the original developer and if erendrake didn't take this over I'd still be in the dark ages using 0.22. I'm now reduced from producing something awesome many people believe is not possible to poring through my code looking for byte savings. A config file setting or a kOS command "set memory to unlimited." will let those that like 'realism' do so while others who just want to code can also do so. Thanks. Love you all - especially erendrake - in a manly type way.)

I think I need to start learning kOS memory management. - how much memory is available; - how do I tell how much I've used; - how do I reduce memory usage (should I strip comments? Declare less variables?) - how do I convince the mod coder there should be a switch to remove this limitation.

No. Probably not correct syntax. I still get random behavior with files that are proven to be solid and find the best way to fix them is to restart a launch, which is not a problem if testing a script, or restart ksp. Still loving this mod though.

Moving on - can someone do this for me please: print arcsin(0.45). and confirm for me they get 26.743683950403, and then confirm for me the correct answer is 0.466765339. Cheers.

Stupid question I already know the answer to - if I use the formula in post #2 what unit will my answer be? If r is in meters then surely my answer is in meters? I'm using r = 600,000 + altitude above sea level. I'm drifting a very small amount (think of minor lateral movement when landing) and I'm getting values in the 10,000's. This would suggest my small wobble is moving me 10 km's. Here are some values for fun: lat 1: -0.059226971 lat 2: -0.075008348 long 1: -74.668487549 long 2: -74.658233643 altitude: 600286 This is hovering around KSP at 286m above sea level. And at this tiny speed I've found that 9 decimal places is absolutely necessary to get a meaningful result. (If you use excel, be sure to convert to radians before cos/sin)

Can anyone suggest the reasons for a file failing to copy from archive? I'm working on a long and complex script but I've broken it down into small files - mostly for my debugging sanity. myprog.txt copy filea from archive. copy fileb from archive. copy filec from archive. until { run filea. run fileb. run filec. etc }. For some inexplicable reason the program will work well for ages, and then all of a sudden throw an error saying that filex could not be loaded. I'm doing a LOT of editing - like - an edit every 60 seconds. I ctrl-c, edit a file in notepad, save - run program again - but that shoulddn't matter. I'll be editing filea and that will through a fatal error - so I // comment out the offending code, and then I get a message that filec couldn't load. I'm like "what? I didn't even touch file c". A lot of waffle there - but I'm finding errors sometimes get thrown unexpectedly against code that has always worked and not recently touched. Maybe a bug in kOS but its so random I'd never prove/disprove it. Right now I'm dealing with a file that can load by itself (filec), but as part of a larger script, it won't load - even if it use to. I'm on the launchpad with a full battery of energy. Cheers. edit: oh dear - just restarted ksp and that failed script is now working ...

Thanks guys - that formula is exactly what I was after. Rep for you!

If I have two points - specified by latitude and longitude, how can I determine the distance between those two points, assuming both points are at sea level? What is the maths to work that out? Will it be different depending on what body you are on? I'm interested in the Mun at the moment. If my rover is at point x (lat/long available) and my base is at point y (lat/long available), how do I work out the distance between those two points, assuming both points are at sea level (which they won't be, but a margin of error is acceptable). Thx.

Thanks Steven - I'll try to slot that into my scripts in the next few days and share the results soon after.

Does anyone have a descent "throttle" control script they care to share? I have a very crude one but it is too jerky and I end up going too fast, too slow, or the throttle is bouncing around like a pogo during landing. If anyone has one I can just 'plug in' that would save me writing a real throttle control that has far smoother control then my script can offer. Thx.

I can't see a toolbar. This is the first time I've used any mod that uses the tool bar. Is it possible my toolbar is permanently hidden? Might I have done something to make that go away? Never mind - found it - top left corner - hidden by my staging icons. Thx.

Can I just state here, because its not stated in the wiki, the readme or anywhere you'd expect, instructions for loading a script from 'disk'? Create a text file with a .txt extension into Kerbal Space Program\Plugins\PluginData\Archive so that you have a file here: Kerbal Space Program\Plugins\PluginData\Archive\vtol.txt Create that folder path if you need to. Open the terminal window in KSP (start a mission) and type this to run your script: copy vtol from archive. run vtol. Credits to reddit and thought it should exist here somewhere for assistance/reference.