[1.3] kOS Scriptable Autopilot System v1.1.3.0

[tomek.piotrowski]

17 minutes ago, leviathan01 said:

is ship to ship communication a planned feature that we can look forward to in the (hopefully) near future?

It is done and ready. It's waiting for the next major release.

[dewin]

So, I'm in the process of writing a code minifier/installer for kOS scripts... in KerbalScript.  When run against itself, the current build reduces the file size by 40% at maximum settings (and it doesn't yet alter variable/function names or do other abuses).  It's probably wholly unnecessary on anything but the first kOS module, but meh.

(It also helps grab everything a particular script needs in the transfer process, though I'm still working that out.)

TL:DR: This is really long.  Oops.

Discoveries:

Compiled code size is partially based on line count.  The minify step that reduces a file to a single line of code yields significant filesize savings.  This actually caused me headaches before I discovered it, since I was comparing file sizes as a quick check to ensure the minifier didn't accidentally alter how kOS interprets things.  (kOS devs: could the KSM representation be smaller with a single bit indicating "this opcode starts the next line" and a virtual "seek" instruction for cases where more than one line is being jumped?  Or there could be the notion of a separate debugging symbols with no line information in the KSM file, but that's probably overkill)

In any case where a period's purpose is ambiguous, kOS prefers the option that consumes the most input.  'print 1.print 2.' works as expected.  'print 1.2.3.4.' is valid code that prints 1.2 and has a '3.4.' instruction that is effectively a noop.  This applies in other contexts as well, e.g. "42foo" parses as two separate "words" before it is rejected as invalid syntax.

'e' is an operator, not a number format.  '1 e 2', 1e 2' and '1e2' are valid.  '1 e2' looks for something named e2 because it's a valid variable name.  '1 e+2' works because variable names can't contain symbols.

kOS doesn't support non-ASCII variable names; anything outside of 0-9 a-z and underscore is not handled by the parser at all.  I'm thankful for this because I can't ask if something is a letter within KS, so I see if it's contained within "abcde...".  Non-English speakers are probably less thankful.

The colon (as does the deprecated '#') follows the same whitespace semantics as operators: 'ship : orbit' is legal.

Annoyances/Requests/Pie in the Sky Wishlist:

(With emphasis on "Pie in the Sky")

Compilation/parsing time: On my (reasonably old, but handles KSP at max settings) machine, there's a fairly lengthy ~5 second delay before the install script even starts.  The script itself is only 20k ish (with lots of comments), so that is a bit surprising.  I can live with it, but that's there.

Exceptions: It'd be nice to have some limited exception handling.  Tokenizing a KS file within kOS is expensive, so I temporarily change config:IPU during execution and revert it back to the previous value after.  There's also some temporary file use (e.g. compiling to the archive and copying the complied file rather than requiring the target to have enough space for both source and result).  If my code aborts for any reason, the revert never happens and temporary files are never cleaned up.

Other processors: If there was a way for one processor to run code on another, I could work around IPU limitations -- idea being that I could have a literal build bot with multiple kOS cores sitting near the launchpad.  I could probably rig together a signalling mechanism involving changing ship control states on one core and waiting for them in another, but that's about as ridiculous as writing a code minifier in KS .

IPU: Being able to exceed 2000 IPU while on the launchpad would be useful -- maybe a "IPU Multiplier" setting.  This is assuming that this is actually my limiting factor in speed.

File I/O: This gets its own list.

- There is no built-in way to copy a file to a destination under a new name; it requires reading and rewriting the file in KS.  There's also no way to specify both source and destination volumes (meaning a SWITCH TO is required if not doing it within KS).  Volume:Copy could fix one or both of those issues.

- There is no way to compile to a volume other than the source, or compile from a string rather than file contents (which would allow a way around the first problem)

- If you want to overwrite a file that may or may not exist, you need to test for its existence or delete it first. Bug: DELETE fails if the file doesn't exist, vol:delete does not.

- There's no way to check modification times of a file, or get real world time (extension to kuniverse?).  If there was, my script could use make-like semantics of keeping its output for files that haven't changed since the last run

Strings:

- WTB regular expressions.

- WTB string escapes (instead of SET Q TO CHAR(34).

- Joining a very large list of strings is super slow for some reason, and KSP locks up for the duration.

Terminal:

- There is way to control the cursor besides AT.  There is also no way to get the current cursor context.

- It'd be nice to have a way to send terminal commands to the actual running program (since the terminal and RUN have separate states.). Right now the workaround is to write the desired command to a file and then run the file.

General language questions/comments:

- In terms of both kOS instructions and real overhead, how expensive is LOCK?  If I'm frequently referring to somelist[ix] where ix is changing, is something like 'LOCK cur To somelist[ix]' worth it to reduce typing/filesize?  (I'm guessing that it's a lightweight function, but how light?)

- Well-behaved libraries shouldn't pollute the global namespace.  When I had a group of functions that needed to share some state, I wrapped them in braces to create a local scope and assigned func@ to a global variable to turn them into global functions.  Declare global function would be nicer

- It'd be nice to be able to get a handle to a ON or WHEN construct that can be used to, among things, cancel it.  The current option is to have the event check for a global cancelled flag and not run/preserve if it is set.  I have some code that draws prograde/normal/radial vectors that could use this. (ON Time is an easy way to add code that runs every tick ad-hoc)

Edited May 16, 2016 by dewin

[hvacengi]

17 minutes ago, kcs123 said:

While we already speaking of MJ, it is integrated quite well in career too. You can't use some MJ modules (rover controls, docking for example) until you unlock it trough tech tree. It would not be too hard to do same with kOS.

I disagree with this.  In order to do the kind of career integration that MechJeb does, we would need to compartmentalize portions of kOS so that they A) can be disabled according to the tech tree and B) fail gracefully when you attempt to access a feature that is not yet available.  I don't think that would be an easy undertaking, and I think there would be limited utility for doing so.  We already comply with KSP's existing career limitations (like maneuver nodes).

There are already MM patches available to add kOS to all probes and capsules, however they have complications for balance (see my comments a few days ago in this thread regarding "StockPlugins").  Realism Overhaul adds the module to (I think) every control part (probe or pod).

We'll continue to discuss it internally as devs, but I wouldn't expect us to include kOS in all probe cores as a stock option any time soon.

[kcs123]

Take your time with this, I know that it won't be easy to properly fit such idea in stock game and keep gamebalance.
kOS mod itself for people who know how to use it is great balance breaker already. On the other hand, kOS brings a lot to this game, make people more interested to do some math, improve programming skills, introduction to robotics when combined with IR mod and so on. Liminting it too much might kill peoples interest to use kOS in the first place.

Blocking availability of some commands in kOS language, based on unlocked tech tree level is another idea for gamebalance purpose, but it can also bring more issues than it is worth to go in such aproach. That brings back idea to go with energy consumption based on tech level and storage space for kOS scripts. On higher tech level you can have more storage space and/or less energy consuption to keep gamebalance. Although, if you run scripts from archive drives you don't need storage space at all.

It all comes to personal preference, how someone want to customize KSP with mods, what kind of experience someone expect from this game. If someone want to use kOS integrated in  probe cores, he will do it, regardless if it is officialy suported or not from kOS dev team.

On the other hand, having it integrated with probes though, could make it easier in further development, less thing to worry about whenever SQUAD change something regarding part physic (mass/heating/drag etc.)

I just throwing ideas here, to recall it when time comes to discuss about it in development. I already appreciate what you have done with kOS so far, probably many other users too.

[dewin]

Heh, to clarify, my original response about MM configs for stock probe cores was never intended to be a request for it to be a standard part of the mod -- more my thoughts on implementing it either myself (since I'd already given it some thought) or having someone else who's interested take a stab at it. 

My thoughts were more towards integrating it with probe cores based on their location in the tech tree vs. the currently parts, assuming the current parts follow Moore's law.  The only problem is that I don't think there is much in the way of tiny probe cores near the end of the tree -- so I'm not sure what the stock analog to KAL9000 would be.

It's worth noting that kOS already does have some features gated by the tech tree -- e.g. those that require sensors to be installed on your ship.  That said, I'm against any sort of hard restrictions based on tech tree progression.  The only two limitations I could imagine that would make sense (and perhaps be reasonable to implement) is having actual speed be part of the progression (e.g. having the earliest processor run at a brisk 10IPU) and memory limits (it doesn't matter as much if I'm limited to 5k disk if I can fit the entire contents of the archive in memory).

Actually, it'd be neat if all of the storage worked in terms of bytecode (Rather than COMPILE output) size, other than being less than intuitive.  This probably falls under the realm of gameplay over realism, and I'm fine with that.  (Though imagine EVAing to a satellite to perform a firmware upgrade and praying you don't brick it.).

[hvacengi]

10 hours ago, dewin said:

It's worth noting that kOS already does have some features gated by the tech tree -- e.g. those that require sensors to be installed on your ship.  That said, I'm against any sort of hard restrictions based on tech tree progression.  The only two limitations I could imagine that would make sense (and perhaps be reasonable to implement) is having actual speed be part of the progression (e.g. having the earliest processor run at a brisk 10IPU) and memory limits (it doesn't matter as much if I'm limited to 5k disk if I can fit the entire contents of the archive in memory).

We have discussed scaling IPU according to tech level, and this probably will come in time.  I actually already have an implementation that moves the IPU into the part cfg file, but we have to finish up a few other things first (like subdirectory support, and a true 3rd party api).  It may or may not make the next major release.  With the advent of the new Unity 5 UI stuff, we're also looking at a possible progression of terminal windows to go along with career progression.  Most of the differences there would be cosmetic (better fonts, cleaner display) but there may be a possibility of other advanced UI features.

Edited May 17, 2016 by hvacengi

[leocrumb]

Is the new (vessel:controlpart) included in this latest release?

[hvacengi]

18 minutes ago, leocrumb said:

Is the new (vessel:controlpart) included in this latest release?

No, it did not qualify as a bug or KSP 1.1.2 adaptation.

[hvacengi]

I can't respond to all of these comments, due to length.  We would be happy do discuss any of the items in greater detail on Github where we can track them better and prevent bloating this thread.  We also gladly accept pull requests, but we prefer you start the discussion before submitting a PR as there are times where we specifically don't want to include a feature, or where we may have an idea in the works about how to do it.

Spoiler

On 5/16/2016 at 4:42 PM, dewin said:

Compiled code size is partially based on line count. [... snip ...]

Compiled code is a very complicated beast, and I'm impressed that it hasn't crashed on you doing this.  There is an expectation of no more than 256 expressions on any given line, though what exactly qualifies as an expression I'm not sure of.

On 5/16/2016 at 4:42 PM, dewin said:

'e' is an operator, not a number format. [... snip ...]

Not entirely true.  While `e` accepts white space (like most separators in kOS) it will not accept a variable on either side of the `e`, the left must be a number and the right must be an integer.  Not only that, as an undocumented behavior there is no guarantee that it will always stay that way.

On 5/16/2016 at 4:42 PM, dewin said:

Compilation/parsing time [... snip ...]

Take this one up with Mono, the underlying framework.  Their Regex has awful performance.

On 5/16/2016 at 4:42 PM, dewin said:

Exceptions: It'd be nice to have some limited exception handling. [... snip ...]

Exceptions present an issue in kOS's "there is no null" paradigm.  We make our best effort to provide a way to detect cases where exceptions will be thrown.

On 5/16/2016 at 4:42 PM, dewin said:

Other processors: If there was a way for one processor to run code on another, I could work around IPU limitations [... snip ...]

IPU: Being able to exceed 2000 IPU [... snip ...]

IPU is complicated.  And I don't think that it will improve in the way you think it will.  All instructions are executed in order, and there is no parallel execution or threading.  If you're seeing a game pause, the only thing that increasing the IPU will do is decrease the number of KSP physics ticks that pass by during that freeze.  Increasing the IPU is very possible, most operations don't consume enough time to truly matter (I have clocked scalar and vector add operations both in the 0.03ms range).  But there are other operations (like string operations, or `positionat`) which consume substantially more time.  We have toyed with some kind of benchmarking system, but that breaks our focus on making sure scripts will run the same no matter what computer you run them on.  In addition, kOS runs an interpreted language (kerboscript), running on top of an abstracted Just In Time language (C#/CLI), which is executed using Mono (based on the .net framework):  It just isn't going to run very fast (certainly not for a while).  CPU and vessel communication is in the works, and would enable some level of what you want, but again it would not likely improve performance.

On 5/16/2016 at 4:42 PM, dewin said:

File I/O: This gets its own list. [... snip ...]

See github, this is already in the works.

On 5/16/2016 at 4:42 PM, dewin said:

Strings: [... snip ...]

Strings are expensive.  Regex is complicated to implement, a pain to write, and a nightmare to support.  Kerboscript is case insensitive by it's nature, and reconciling regex matches not working the same as other string operations would complicate issues.  Any time you work with a string, it's expensive, both in memory and execution time.

On 5/16/2016 at 4:42 PM, dewin said:

Terminal

User input and terminal revisions are on the horizon.  They are not at the forefront of the priority list however.

On 5/16/2016 at 4:42 PM, dewin said:

[... snip ...] Declare global function would be nicer [... snip ...]

- In terms of both kOS instructions and real overhead, how expensive is LOCK?  [... snip ...]

- It'd be nice to be able to get a handle to a ON or WHEN construct that can be used to, among things, cancel it.  [... snip ...]

Locks are not any more expensive than a function (in fact they have a nearly identical implementation in the underlying C#).  That being said, if you use a lock with an identifier once in a script file, that identifier will always refer to the function even if you unlock and start to refer to the identifier as a variable.  In that instance, the function defaults to "return the variable with the same identifier".  Referencing triggers is something we would like, but initial language decisions prevent us from being able to do anything about it without breaking existing scripts.  You can use scoping and lexicons to make a "poor man's" class/object definition.  In an upcoming release we will be including anonymous functions, which means you won't have to "pollute" the global namespace.  Just remember that it will still pollute the global code cache, as every unique function is compiled into opcodes, and the opcodes are not cleared until your program context finishes (a "run program" returning to the terminal, or a reboot for items declared in the terminal).

Thanks for the input, and again please feel free to stop by github if you want to discuss these more in depth.

[karamazovnew]

I seem to have a problem controlling the vessel with any FAR v0.15.6.5  related control surfaces. I'm trying to use LOCK STEERING TO HEADING(x,y) during the ascent. If I don't use any gimbaled engines, the winglets twitch on all axis very fast, while the craft remains pointing up and "stable". The vessel ignores any Heading commands, both from the script and the console. With gimbaled engines added, the craft behaves normally on yaw and pitch axis, except for the roll axis which again twitches wildly, but the craft is "stable" on that axis as well. After removing FAR, everything works normally. Oh and reaction wheels work fine in all cases. 

The following log appears in all cases, no errors. 

[LOG 11:13:09.577] kOS: FlightControlManager: ToggleFlyByWire: steering True
[LOG 11:13:09.577] kOS: FlightCtrlParam: Enabled: steering False => True
[LOG 11:13:09.578] kOS: FlightCtrlParam: toggle steering parameter

 

 

Edited May 19, 2016 by karamazovnew

[leocrumb]

On 5/17/2016 at 5:18 PM, hvacengi said:

No, it did not qualify as a bug or KSP 1.1.2 adaptation.

You mean there will never be a way to reference the controlled part in a script?

[hvacengi]

2 hours ago, leocrumb said:

You mean there will never be a way to reference the controlled part in a script?

No, I mean that it isn't listed on the changelog or included in the v0.20.1 release because that release was strictly a maintenance release to address a few bugs, mostly specific to KSP 1.1.x.  The pull request including the feature has been merged, and will be included in our next major release.

4 hours ago, karamazovnew said:

I seem to have a problem controlling the vessel with any FAR v0.15.6.5  related control surfaces. [... snip ...]

FAR changes the aerodynamic properties of the game, and we currently do not directly support FAR.  All of our steering calculations are based on KSP's new `ITorqueProvider` interface, so FAR would need to replace the control surface module with it's own module providing FAR specific torque calculations in order for kOS to accurately control with it.  If they already do this, we may need to look into the accuracy of those readings.

[karamazovnew]

11 hours ago, hvacengi said:

FAR changes the aerodynamic properties of the game, and we currently do not directly support FAR.  All of our steering calculations are based on KSP's new `ITorqueProvider` interface, so FAR would need to replace the control surface module with it's own module providing FAR specific torque calculations in order for kOS to accurately control with it.  If they already do this, we may need to look into the accuracy of those readings.

Hi there, here's Ferram's reply to me:

Quote

FARControllableSurface has implemented ITorqueProvider and GetPotentialTorque() since FAR v0.15.6.0, and I am now on v0.15.6.5 with no issues there

No idea what you guys are talking about, but hope this helps. Meanwhile, I've kept 2-3 rocket fins from getting FAR and they work great with KOS on their own. Happy camper waiting for a fix

EDIT: actually to help a bit, almost forgot to mention: while messing around with those fins, I turned one of them into a FAR wing with stock ModuleControlSurface. kOS worked with it (sort of). So I'm assuming that @dragCoeff = 0
@deflectionLiftCoeff = 0 which FAR puts somehow break KOS's ability to alter course, while still having them try to maintain stability. Hope that helps. 

Edited May 20, 2016 by karamazovnew

[kcs123]

FAR put @dragCoeff = 0  and @deflectionLiftCoeff = 0  for a reason - those are meaningless when you have FAR installed.
FAR use voxelization feature and calculate lift and drag on all parts at the same time. Very rude simplification of this is that FAR use all parts from craft and trough voxelization "change" it to looks like only one part. Then lift and drag is calculated on craft as a whole, not part by part as stock physic does.

Your custom MM config only breaks both - stock physics and FAR - neither will work properly.

I didn't get deep enough with kOS, but based on experience with both, it worked much better for me with custom PID (search for PID library trough kOS documentation) and use raw pilot input control instaed of lock steering command.

I wanted to create pilot assistance instead of full autopilot with kOS in previous version of KSP and kOS with trim controls.
Unfortunately due to bugs in kOS or KSP, raw input command does not work. @Steven Mading have raised issue on github about it, I forget to check current state of it. Probably there is bigger issues to solve first.

I'm still in phase of learning how everything is handled trough kOS, so I can't help you much, but there is video creted in previous releases where someone created nice autopilot with kOS and FAR, following terrain altitude pretty nice. Flying over mountains, hills and valleys. Nice video, btw.

So, it is possible to create kOS scripts that handle FAR crafts in friendly way, but you should know how to create stable crafts/rockets in the first place. Or have to know craft limitations, so you don't exceed control input over craft limits.

[ColKlonk]

This is a new one for me... My code is sitting at 2300 lines at the moment - could this be too long?

Or maybe I need more KOS disk space?

I haven't changed my rocket in any way from a previous working version. Meticulously re-organised the code (block copies) etc... - I'll check again though.

KSP1.05, RSS/RealismOverhaul, KOS19.3

Edited May 20, 2016 by ColKlonk

[hvacengi]

16 hours ago, karamazovnew said:

No idea what you guys are talking about, but hope this helps. Meanwhile, I've kept 2-3 rocket fins from getting FAR and they work great with KOS on their own. Happy camper waiting for a fix

I wouldn't count on a fix coming from our end any time soon.  We have never really supported relying on control surfaces for cooked steering anyways, and we only have decent stock support for it now because Squad provided it in the 1.1.x release.  I'll have to go look at @ferram4's code, and then run some debugging tests.  I don't use FAR myself, so I'm not really in a place to do any quick testing or analysis.  In theory so long as FAR is giving the "maximum potential torque at full control deflection" our system should just work.  But I know that FAR is a lot more complex of a calculation, so FAR's torque calc may very well not be the problem.  Variations in torque as the vessel changes it's orientation and speed are probably a bigger issue than stock calculations.  Since our steering code attempts to be "smart" and tune's the controller parameters based on constant available torque and moment of inertia, having a rapid changes in the torque parameter could invalidate our control loop model.  I would recommend submitting a kOS github issue, so that there's a chance for us to remember to come back and look at this in the future.

 I don't think I've seen any reports of major issues with the stock control surfaces.  In general people use raw controls for that kind of stuff anyways.  It could be that there is something wrong in our math that just hasn't shown itself in other testing.

Have you tried tuning the steering at all?

7 minutes ago, ColKlonk said:

This is a new one for me... My code is sitting at 2300 lines at the moment - could this be too long?

I doubt the issue is your code length, but without any context the error message doesn't really tell us anything.  Please provide a copy of the script, as well as the log file showing the error message.

Null references are most easily found by looking at the actual C# underlying stack trace, which is visible in the log.

Edited May 20, 2016 by hvacengi

[hvacengi]

The original post was edited while I was replying:

16 minutes ago, ColKlonk said:

KSP1.05, RSS/RealismOverhaul, KOS19.3

Depending on what the error is, it may have already been fixed in either a more recent version, or in the pending develop branch.  You can still post the information (it might still be an issue) but there is a good chance that we will ask you to upgrade and test again.

[ColKlonk]

This is during compilation phase.. before the program runs.

Everything worked fine before the current changes, and usually debugging is no problem

Where would you find the KOS error message log file ??

OK.. before I post the code, and waste your time.. let me go through it once more - thanks anyway.

Edited May 20, 2016 by ColKlonk

[hvacengi]

3 minutes ago, ColKlonk said:

This is during compilation phase.. before the program runs.

Everything worked fine before the current changes, and usually debugging in no problem

Where would you find the KOS error message log file ??

Even if the error is during compilation, it very well could be related to the content in the file.  I'd prefer that was made available, but there is a chance we can see what's going on from just the log file.

If things were working, then you refactored and rearranged your code, I would be highly suspect of a formatting issue or name conflict, something that is not run into often in scripts.

You can find instructions for the log files under "The Logs" in this post: 

 

[Dunbaratu]

45 minutes ago, ColKlonk said:

This is during compilation phase.. before the program runs.

Everything worked fine before the current changes, and usually debugging in no problem

Where would you find the KOS error message log file ??

OK.. before I post the code, and waste your time.. let me go through it once more - thanks anyway.

(How in the *%&*@#! do you break a quote section into parts to respond to individual lines of it in this awful what-you-see-is-all-you-get-to-have editor on the forum?  I've tried everything I could think of.)

(1) You say "everything worked fine before the current changes".  You're using the word current, but said you're on version 19.3 (I assume 0.19.3).  Current is 0.20.1, so can you provide the two version numbers you mean just to be clear?  Which version did it last work on, and which version did it stop working on?

(2) The log file we're looking for comes from Unity itself.  For some utterly ridiculous reason I don't understand, Unity decided that despite having the goal of a unified cross-platform development engine, they were going to make the location of this log file differ on every platform.  So the answer depends on what platform:

• Windows 32-bit: [install_dir]\KSP_Data\output_log.txt
• Windows 64-bit: [install_dir]\KSP_x64_Data\output_log.txt
• Mac OS X: ~/Library/Logs/Unity/Player.log
• Linux: ~/.config/unity3d/Squad/”Kerbal Space Program”/Player.log

Edited May 20, 2016 by Steven Mading

[Alchemist]

1 minute ago, Steven Mading said:

(How in the *%&*@#! do you break a quote section into parts to respond to individual lines of it in this awful what-you-see-is-all-you-get-to-have editor on the forum?  I've tried everything I could think of.)

Select part of the message. "Quote this" popup will appear. Click it and you'll get a partial quote inserted. (Better than quoting entire message several times and then editing those quotes).

Yeah, the more one's familiar with coding, the less he is content with WYSIWYG, at least when it's pretending to be smarter than it really is.

 

[hvacengi]

2 minutes ago, Alchemist said:

Yeah, the more one's familiar with coding, the less he is content with WYSIWYG, at least when it's pretending to be smarter than it really is.

I could live with WYSIWYG if there was an option to also modify the underlying code.  Unless the software uses a very random undocumented formatting engine, it seems like adding a "Edit raw" option wouldn't be so hard.

[Alchemist]

5 minutes ago, hvacengi said:

I could live with WYSIWYG if there was an option to also modify the underlying code

Exactly. Either ability to access raw code or ability to efficiently manipulate and fine tweak the objects in some other way. When it says "I'll put it like this and no other way" - it gets annoying.

[Jacke]

54 minutes ago, Steven Mading said:

(How in the *%&*@#! do you break a quote section into parts to respond to individual lines of it in this awful what-you-see-is-all-you-get-to-have editor on the forum?  I've tried everything I could think of.)

Another way to do this.  Click just after the last text you want to be before the break (the ')' above) and type "Enter" three times.  DON'T start typing text yet, or you will encounter the IPS4 (the forum software) backwards typing bug.

You should have 2 blank paragraphs between the now-broken quote.  Your cursor will be on the 2nd blank paragraph.  Click to move the cursor to the 1st blank paragraph and you should be able to enter your comment and do other editing without issue.  For example, I deleted the rest of the quote that was below the above quoted text.

I really, really hate IPS4.  That it doesn't have a proper raw mode is just one of its ills.

[MAFman]

Is it possible to make a kind of Curiosity-like autonav algorithm for rovers? If so, what would be used to measure terrain roughness/height and safety?