[0.23] FTAS v1 - The Fox Terrain Avoidance System

[togfox]

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;
  

Edited February 15, 2014 by togfox

[astropapi1]

This thing is awesome.

Awesome!

AWESOME!

[Zephram Kerman]

I'm so excited to see the beginnings of AI in KSP!

Ours is a world where terrain may change dramatically from one version to the next, maps may have errors, and navigators may get distracted by shiny objects. So an autonomous lander can't rely on preprogrammed data. (Also, it's not very realistic for a remote-controlled probe sent several light-minutes away to be controlled by a human operator with a joystick.)

Besides, it's super-cool!

[Camacha]

It would be nice to have more advanced detection systems though. If you look at the MSL skycrane it has a good number of highly advanced propietary radar units just to get the thing down safely. I would love a kOS part that could do range finding the same way. Just imagine slapping a few of those on the right places of rovers and landers and how much easier that would make life Combined with damned robotics you could even do a scanning system. No more flying around in circles, just some proper detection. I can image having different types of sensors all having advantages and disadvantages, just like in real life.

Just to illustrate, the mount on the side with the silver discs is the skycrane's radar system, which enabled it to safely deliver Curiosity to the red planet. That thing is a work of beauty.

Edited February 16, 2014 by Camacha

[togfox]

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.

[rkman]

Mapsat scans an area. Size of the area depends on altitude of the craft.

Back in the days when mapsat was new i suggested that the data in a scanned patch can be used to determine slope and smoothness of the terrain.

[Camacha]

Personally I would much prefer direct measurements. I mean, picking a spot for a landing is done via maps, but when you get there, you are certainly going to look out the window. Whether that is in person or via radar equipment a la the MSL skycrane.

It would be really lovely to have a seperate part you could stick to your craft and that then could be called from kOS.

set altitudeinfront to sensor:laser(1)

Or something like that Using more can yield more accurate results, using less could make for simple and excellent solutions. You could even start scanning at altitude at lower resolutions to home in on a suitable patch of ground.

Edited February 17, 2014 by Camacha

[erendrake]

Personally I would much prefer direct measurements. I mean, picking a spot for a landing is done via maps, but when you get there, you are certainly going to look out the window Whether that is in person or via radar equipment a la the MSL skycrane.

It would be really lovely to have a seperate part you could stick to your craft and that then could be called from kOS.

set altitudeinfront to sensor:laser(1)

Or something like that Using more can yield more accurate results, using less could make for simple and excellent solutions. You could even start scanning at altitude at lower resolutions to home in on a suitable patch of ground.

I think its a great idea, if someone wants to make a model and texture for it i would be happy to add it to the backlog

@togfox This is really cool and im really excited when someone makes such an interesting project thank you for sharing!

[Dunbaratu]

If you want to do everything in kOS and avoid having mechjeb do part of the work for you, you can make a rover remain locked to a particular speed very easily with just one kOS lock expression:

Assuming the following settings:

set seekSpeed to 9.0.  // 9 meters per second in this example.
set gent to 2.0. // tweak this to decide how "gentle" to make the adjustments.  larger for more gentle, smaller for quicker reaction.

This one liner will keep you locked to seekSpeed:

lock wheelthrottle to ( seekSpeed - velocity:surface:mag ) / gent.

It makes the wheelthrottle become zero when coasting exactly at the desired speed, and makes it larger in the forward direction the farther below the desired speed you are, and larger in the reverse direction the farther above the desired speed you are.

It's crude and simple but for the most part good enough.

As far as the slope seeking algorithm. the hard thing about doing it in this technique is that you can end up going perpendicular to the slope of the terrain and therefore get a false "flat" reading. I've had this problem trying to land before using almost the same sort of algorithm. It's almost like I need to scan over the area first taking sample readings before coming back in a second pass to land.

[Camacha]

I think its a great idea, if someone wants to make a model and texture for it i would be happy to add it to the backlog

That sounds promising! Risking complicating things right away, I think a number of different sensors might be in order, such as a laser ranger, an (ultra)sonic distance sensor, a pressure sensor (direct contact) and maybe a radar ranger. Each could have specific up and downsides such as accuracy, beam shape and width, range versus accuracy, working conditions (i.e. sound does not travel in a vacuum), stuff like that. Or they could simply be found further up in the tech tree, but I think the real life differences between the lot will provide plenty of inspiration.

I feel that when this is done correctly, it could be an incredibly powerful package when combined with kOS and Infernal Robotics. It would make true robotics feasible. Instead of rovers driving around blindly, we could give them true and proper hazard detection capabilities. It might even make for an interesting educational package

Unfortunately I am only capable of doing Solidworks/CAD models, which is not really useful for KSP. I am planning to expand into Blender, but due to time constraints imposed by my graduation period, it will be a while before that really starts going somewhere. On the other hand, I feel the models should be small and simple, as they are a means and not an end.

Personally I would really not mind to do some of the work on this, but if I am honest there are other matters that are more pressing at the moment.

[Dunbaratu]

Personally I would much prefer direct measurements. I mean, picking a spot for a landing is done via maps, but when you get there, you are certainly going to look out the window. Whether that is in person or via radar equipment a la the MSL skycrane.

It would be really lovely to have a seperate part you could stick to your craft and that then could be called from kOS.

set altitudeinfront to sensor:laser(1)

Or something like that Using more can yield more accurate results, using less could make for simple and excellent solutions. You could even start scanning at altitude at lower resolutions to home in on a suitable patch of ground.

Ideally it would just return the distance to the terrain in whatever direction the sensor is mounted in, whatever that may happen to be. If you mount the sensor pointing out the bottom of the craft, then it tells you the distance in the direction the bottom of your craft is pointing. If you mount the sensor pointing out the side, then it tells you the distance in that direction. That way you could mount several sensors like in the image you posted, slightly angled off from each other by a few degrees, using the "SHIFT" key when building the craft to mount them aimed in slightly different rotations from each other.

Actually it if measured in whatever direction it's pointed at the moment, I could get a lot done with just one sensor mounted on the craft. I could just rotate the craft a bit to get different measurements.

[Camacha]

Ideally it would just return the distance to the terrain in whatever direction the sensor is mounted in, whatever that may happen to be.

What you are describing is exactly what I mean It would also challenge the user to be more of an engineer, thinking about angles, placement and whatnot, instead of just blindly adding *a sensor* to the craft.

[Dunbaratu]

Unfortunately I am only capable of doing Solidworks/CAD models, which is not really useful for KSP. I am planning to expand into Blender, but due to time constraints imposed by my graduation period, it will be a while before that really starts going somewhere. On the other hand, I feel the models should be small and simple, as they are a means and not an end.

I wonder if it would be possible to start with a sort of crude dummy placeholder for the art and mesh - like just a plain one color rectangular prism with a color dot on one end to help see which end is the "business end" of it - to get started on the code until a better set of artwork can be created by someone later.

[Camacha]

I wonder if it would be possible to start with a sort of crude dummy placeholder for the art and mesh - like just a plain one color rectangular prism with a color dot on one end to help see which end is the "business end" of it - to get started on the code until a better set of artwork can be created by someone later.

To be honest, I think the whole process of getting a model to show up properly in KSP is more of a hassle to find out and get working than to make a half decent model. Of course, the model does not need much; just one of those rectangular prisms with slanted sides and a pointy bit on one end for a laser should be enough.

Thinking about it, I figure that the easiest route is probably to create something like a duplicate thermometer, if necessary reskinning the bit to look a bit more appropiate. That should take very little time and has pretty much all one could need set up. I might take a stab at that if I have a few hours to kill

[erendrake]

I have created a new ticket in github for adding the features we have been talking about. We dont have to just hijack this thread

https://github.com/erendrake/KOS/issues/40

Lets make this an awesome feature

togfox I would love to get your input as to what tools you would like to have.

[togfox]

Posted a comment on github.

[togfox]

Just saying after a 12 month break from KSP in general (just downloaded 0.90) I'm going to ressurect this project and see if kOS can do this a little bit smarter than before.

I'm not aiming for a perfect solution - that would be nice - but something that is better than what we have now is the goal. Success through tiny steps. Look forward to your technical and mathematical expertise!

For those needing a refresher, this article I wrote 12 months ago:

http://forum.kerbalspaceprogram.com/entries/1210-The-Fox-Terrain-Avoidance-System-%28FTAS%29

Thinking about the greatest weakness of the FTAS is the one-dimension view it takes. It can only measure one axis at a time. A craft travelling left to right may detect no slope, or a zero gradient and land, not knowing that it's on the side of an enormous mountain but because it was travelling perpendicular to the direction of the side slope the gradient appeared to be minimal.

I think the answer is in a more sophisticated database where multiple points form a network of gradiants and the whole network together provides a clearer picture of the terrain around it. For example, measuring the altitude at point A and then point B gives the slope between A and B (obviously). Another measure at Point C can not only be compared with the previous point B, but alos the first point A. Greater degrees of movement across the z and x axis (left/right, forward/back) between measurements will provide a view of a wider space, but with less granularity. For this reason, a craft on descent should maximise movement across the z and x whilst at a high altitude to assist with pinpointing the general location of a suitable plateau. As the craft decends towards a general flat, movements should be smaller and more refined. Movements should be smaller and deliberate and closer together as the craft approaches a radar altitude of 0.

I'm not sure how sophisticated kOS can be with storing a lot of data points. What are the options? Arrays, variables, stored in files? I'll have to see.

Edited January 22, 2015 by togfox