[kOS 13.1] Rover Driver Pre-Release #5 (8/6/14)

[Drew Kerman]

Real-time output display

Pre-release download

(8/6/14)

What Rover Driver Does

Rover Driver is intended to alleviate the process of getting your rover to where it needs to go. No one wants to sit at their computer for hours with their finger mashed on the W key as their little rover tools along at 6m/s with 100km left to go until they reach the next biome. Nor do they want to place an object on the key, walk away and come back later to find their rover at the bottom of a crater, or couldn't make it up a hill and rolled back down in peices. Rover Driver will ensure that, with proper route planning and drive parameters, you can initiate the program, walk away, and come back later to find your rover ready to perform its next science mission.

What Rover Driver Doesn't

Rover Driver doesn't completely remove the need for manual driving of the rover. If you are using Rover Science, or looking to perform any science available on the rover, that has to be done by the user. The use-case for Rover Driver at this time is that you've collected all the science you can from the biome you are in, and now you have to trek to the next biome, or the next Rover Science point. Rover Driver will get you there and then you can use manual control to drive around that immediate area and do the science. Rover Driver will also be essential for anyone playing with signal delay enabled in RemoteTech2, although at this time it cannot take command inputs (i.e. drive forward, 15m, at 4m/s).

Required Mods

Obviously, Rover Driver requires kOS to be installed. In addition to that, Rover Science must be installed so that your rover can be equipped with the Rover Brain part that will give the rover a horizontal command perspective needed for proper program control. Before Rover Driver should be initiated, you must "Control From Here" on the Rover Brain part.

F.A.Q.

Q: This isn't a stand-alone mod? Why?

A: Mainly because I'm too lazy to setup a C# dev environment when one already exists for me within the game. Also, because it's way more fun IMO doing it this way as opposed to "normal" programming I've done way too much of already.

Q: But I don't know anything about kOS!

A: Thankfully, you don't really need to. The numbers you need to tweak are well-exposed and documented, and using kOS within the game is very simple - just check the beginning of the video above

Q: Can it be used for any vehicle?

A: Any vehicle with wheels, that has a kOS computer module to hold the scripts.

Q: Can it be used for kerbed vehicles?

A: Yes! While primarily designed for remote-operated vehicles if you have a bunch of kerbals in a rover to send from, say one settlement on Duna to another, you can pile em in and turn on Rover Driver to get them there.

Q: Does this drive rovers when they are not loaded?

A: Unfortunately no, you have to have the rover loaded as the active vessel in order to start the program. Once the program is running you can switch to another craft but the rover must remain within physics range (2.5km in the stock game) if the kOS script is to function.

Q: Why can't I copy your programs over to my rover from the archive?

A: Probably because you don't have enough disk space to hold them. I've not really played with any sort of balance to the disk space in my kOS processing units. I generally just edit the diskSpace property of the kOSProcessor module for whatever part I have attached to my craft. Sorry if you have any personal rules in your playthrough that limit your kOS storage and the program doesn't fit. "Research" more space?

Q: Can I make the Rover Brain into a kOS processing unit?

A: Sure, I do. Just use this ModuleManager config:

MODULE
{
name = kOSProcessor
diskSpace = 50000
}

// extra usage for the kOS processor
@MODULE[ModuleCommand]
{
@RESOURCE[ElectricCharge]
{
@rate = 0.05
}
}
}

@PART[roverBrain] {

Q: Why does my rover drive around erratically and not towards the waypoint?

A: You probably forgot to "control from here" on the Rover Brain part

Q: Why doe my rover keep flipping no matter what parameters I give it unless it goes reeeaaally slow?

A: It's probably not designed very well. Make sure your center of mass is as low to the ground and towards the center of the rover as possible. Also keep in mind that real-life rovers, like those on Mars, take years to travel even a few dozen kilometers. Sometimes you just have to go slow.

Known Issues

• You'll notice sometimes the log window seems to "roll down" when it updates. This is due to a workaround to keep values in the window from flickering instead
  
• The game will pause for a second or two when switching over to the MonitorDrive program
  
• Due to an issue with the current version of kOS, the rover may occasionally fail to acquire the next waypoint, and a call to ResumeDrive must be used to continue
  

The Waypoint System

Rover Driver navigates using waypoints. By default, these are aptly called "waypoints" but since you might have routes planned for different rovers (even though only one can be driven at once, they might all exist in your save file together), what you call these waypoints can be set in the program. Regardless, at this time the waypoints must be VESSEL objects. I personally prefer to use flags, which I then re-label as Debris within the persistence.sfs file. Yes, at this time there will be manual persistence.sfs editing. Place the waypoints by using the lat and lon fields in the VESSEL structure. You can get the location of your waypoint either from a SCANSat map you created in the game, or from a source like KSP Maps. Setting the alt to 0 will cause the flag to pop up onto the terrain when it's loaded. I would suggest switching to each waypoint to load the flags to the proper terrain height prior to roving.

Why objects instead of internally-defined geo-position coordinates? My main argument is the fact that you can see what you're heading for when your craft targets an object in the distance. I like seeing exactly where my next waypoint is off in the distance. You can also see the waypoints from map view.

numWaypoints

This is how many waypoints your rover will be traversing on this drive. It can be less than the number of waypoints you have placed, but know that the rover will only navigate up to this number of waypoints.

currentWaypoint

This number should always just be 1, as that would normally be the first waypoint on your drive. If you're currently at waypoint3, then you should be using the ResumeDrive program. However if a system crash or data corruption occurs in your rover causing it to lose all data from a previous drive, you should set this number to the waypoint you want to re-start the drive towards.

waypointName

By default waypoints are called "waypoints". But if you're planning multiple routes through the same area, to avoid confusion you can call markers on one route "MunTraverseA" and another "MunTraverseB". The actual names of the VESSEL objects would be "MunTraverseA1", "MunTraverseA2", etc. Keep in mind long waypoint names could cause log messages to be cut off in the output window.

travelDirection

If you want to head backwards from your current waypoint, change this number to -1. If you are using ResumeDrive, then use the command window to set travelDirection to -1.

autoReturn

When this is true, the rover will reverse course and return to the first waypoint after it reaches the last rather than stopping and ending the program.

waypointHold

When this is true, the rover will stop at each waypoint instead of automatically beginning the traverse to the next one. This is useful if you are using Rover Driver to drive for you while you are at the computer. When stopped, you can perform any science or other tasks required at the waypoint. Unlocking the brakes will cue the rover to continue the drive. Currently, this setting affects all waypoints.

Feel free to copy and paste this as many times as needed into your persistence.sfs file. Change the name, lat and lon fields as needed.

{
pid = 322e64edaf164f09a4dc4e9f4b01dd25
name = waypoint1
type = Debris
sit = LANDED
landed = True
landedAt =
splashed = False
met = 21563375.7475225
lct = 4042.81846679418
root = 0
lat = -0.3296
lon = -74.8828
alt = 65.1069490535883
hgt = 0
nrm = -0.0931586,0.9956501,-0.001621197
rot = 0.05831609,-0.6722429,0.7155037,-0.180951
CoM = 0,0,0
stg = 0
prst = False
ref = 0
cPch = 0
cHdg = 0
cMod = 0
ORBIT
{
SMA = NaN
ECC = 1
INC = NaN
LPE = 61.2225702955125
LAN = 336.127114346321
MNA = -8.40714670366795
EPH = 21568922.0859556
REF = 1
}
PART
{
name = flag
uid = 906603193
mid = 629482578
parent = 0
position = 0,0,0
rotation = 0,0,0,1
mirror = 1,1,1
istg = 0
dstg = 0
sqor = -1
sidx = -1
attm = 0
srfN = None, -1
mass = 0.01
temp = 1.353625E-09
expt = 0.5
state = 0
connected = True
attached = True
flag = Squad/Flags/default
rTrf = flag (waypoint1)
EVENTS
{
}
ACTIONS
{
}
MODULE
{
name = FlagSite
isEnabled = True
placedBy = Rover Driver
PlaqueText = Waypoint flag
state = Placed
EVENTS
{
TakeDown
{
active = True
guiActive = False
guiIcon = Take Down
guiName = Take Down
category = Take Down
guiActiveUnfocused = True
unfocusedRange = 2
externalToEVAOnly = True
}
PickUp
{
active = False
guiActive = False
guiIcon = Pick Up
guiName = Pick Up
category = Pick Up
guiActiveUnfocused = True
unfocusedRange = 2
externalToEVAOnly = True
}
ReadPlaque
{
active = True
guiActive = False
guiIcon = Read Plaque
guiName = Read Plaque
category = Read Plaque
guiActiveUnfocused = True
unfocusedRange = 2
externalToEVAOnly = True
}
}
ACTIONS
{
}
}
MODULE
{
name = FlagDecal
isEnabled = True
flagDisplayed = True
EVENTS
{
ToggleFlag
{
active = True
guiActive = False
guiActiveEditor = True
guiIcon = ToggleFlag
guiName = ToggleFlag
category = ToggleFlag
guiActiveUnfocused = False
unfocusedRange = 2
externalToEVAOnly = True
}
}
ACTIONS
{
}
}
MODULE
{
name = ModuleAeroReentry
isEnabled = True
adjustCollider = 0
crashTolerance = 8
damage = 0
dead = False
EVENTS
{
RepairDamage
{
active = True
guiActive = False
guiIcon = No Damage
guiName = No Damage
category = No Damage
guiActiveUnfocused = True
unfocusedRange = 4
externalToEVAOnly = True
}
}
ACTIONS
{
}
}
}
ACTIONGROUPS
{
Stage = False, 0
Gear = True, 0
Light = False, 0
RCS = False, 0
SAS = False, 0
Brakes = False, 0
Abort = False, 0
Custom01 = False, 0
Custom02 = False, 0
Custom03 = False, 0
Custom04 = False, 0
Custom05 = False, 0
Custom06 = False, 0
Custom07 = False, 0
Custom08 = False, 0
Custom09 = False, 0
Custom10 = False, 0
}
DISCOVERY
{
state = -1
lastObservedTime = 0
lifetime = Infinity
refTime = Infinity
size = 2
}
FLIGHTPLAN
{
}
CTRLSTATE
{
pitch = 0
yaw = 0
roll = 0
trimPitch = 0
trimYaw = 0
trimRoll = 0
mainThrottle = 0
}
}

        VESSEL

The "Obstacle Avoidance System"

I originally coded some routines that, when the rover detected it wasn't making it up a slope it would back down, turn a set amount of degrees off the target bearing, rove in that direction a set amount of meters, and then turn back towards the target to try again. If it failed multiple times it would return back to the first position it failed and try the other direction. After that it woud switch to standby mode and await further orders. This was removed because it was getting too complicated to code and routes should be properly planned to avoid any huge mountains. In the event that terrain was unkonwn during planning and the rover does hit a slope that is defined as too steep, it now simply backs down to level ground and goes into standby (program ends, brakes on). Using this system properly requires setting up your drive parameters in the right manner, explained more in the next section.

Rover Driving Characteristics

There's a lot more to driving a rover than simply telling it to go forward at full throttle. Doing this on high-gravity worlds like Kerbin is mostly okay, but on Mun? You hit a small ridge at top speed and you are flying. Therefore, there are many variables you can tweak so that Rover Driver handles your rover properly when on level ground, traveling up a slope or driving down a slope, as well as approaching waypoints. Understand that every rover you construct will have its own unique handling characteristics based on where you place the wheels, how high it is off the ground, how many wheels it has, etc. You should run all your rovers through some courses around KSC and the nearby grasslands to properly tweak these settings to ensure your rover doesn't end up a pile of junk on the surface of another planet.

overSpeedDownSlopeBrakeTime

This mouthful controls how much the rover brakes when heading down a slope that is deemed too steep to travel at normal speed (set by levelSlopeAngle). It can be whole seconds or fractions of a second. Keep in mind the longer you brake while traveling downhill the more chance you have of flipping your rover.

slopeAbortDelayLength

Because of how the rover can slow down a lot when traveling down a slope, if it comes up against a slope steeper than upSlopeAngle right at or close to that moment, there's a chance the rover won't have enough time to switch to a higher throttle setting and speed up past slopeAbortSpeed, at which point the drive will be aborted. It's likely however that the rover could have made it up the slope had it been traveling faster. This setting gives it a certain amount of seconds with which to attempt to travel up the slope faster than slopeAbortSpeed before allowing the drive to be aborted.

extremeSlopeAngle

This defines the angle at which you rover would rapidly pick up speed - dangerously so. This allows the rover to know when it should take advantage of some extraBrakeTime to ensure that the brakes are applied long enough to slow it down well below overSpeedDownSlope and keep its velocity in check as it drives down a slope. Currently this variabe applies only to downslopes but to keep things open for possible future upslope use it is set as a positive number only.

extraBrakeTime

The number of seconds that will be tacked on to your brakeTime while traveling down an extremeSlopeAngle. It's okay if it slows the rover completely down to 0, but prefereably would be tuned to slow the rover down to around half overSpeedDownSlope.

slopeAbortSpeed

Once the rover's speed in m/s drops below this number while it is traveling up a slope greater than upSlopeAngle, the drive abort routine will kick in. The rover will either park itself on the hill and end the program, or it will back down until it reaches a levelSlopeAngle, then park and end the program.

groundHeight

This tells the program how many meters above the ground your rover sits. Any readings higher than this will cause the program to recognize that your wheels have left the ground. You can see your rover's height above ground by setting this number to 0 and running the program. The "Height over ground" reading in the real-time output display will give you this number. So if the display is telling you 0.5m, then you should set your groundHeight variable to something like 0.6. The reason is that as your rover moves the suspension will cause minor changes in height and thus false air readings. So leave a bit of wiggle room by monitoring this number as your rover drives to see how much it changes.

cruiseSpeedBrakeTime

How long you should apply the brakes will depend on how heavy your rover is. For larger rovers, hitting the brakes for 1 second probably won't change your speed much. As with everything else, testing is needed to see what value works for your rover. This can be in whole or fractions of seconds (2.5, for example) and is only applied while your rover is traveling over a slope within levelSlopeAngle.

upSlopeAngle

As your rover heads up a slope, it will slow down. If it hits a steep enough slope it could stop completely and abort the drive. Rover Driver will use upSlopeAngle to determine when more throttle should be applied to keep the rover going. Important!! Consider that while an upslope can end on a level plain (a plateu) it can also end with a sudden downslope on the other side (a peak). So when you tell your rover to go faster up a hill, possibly as fast as it would normally travel over level ground, keep in mind that topping a peak at speed can have dire consequences as your rover can catch air (big air on low-gravity worlds) and possibly not end up back on its wheels. Therefore when determining the upSlopeAngle in testing it's recommended that this angle and upSlopeSpeed result in a surface speed that is around half what your cruiseSpeed produces. Also Important!! Don't forget that this variable is tied directly into the drive abort system and that if you tweak things to where your rover will be going slower than slopeAbortSpeed before it reaches a slope greater than upSlopeAngle, the drive abort system will fail to function.

cruiseSpeed

This is the throttle setting (0-1) at which you feel the rover can safely move over level terrain, as defined by levelSlopeAngle. Ideally, this value wouldn't cause your rover to go faster than overSpeedCruise on a level slope to avoid using the brakes often.

upSlopeSpeed

This is the throttle setting (0-1) mentioned earlier in conjunction with upSlopeAngle. Setting this to 1 is an easy solution that could cause some dire consequences, so make sure you test this value carefully and are crawling up steep slopes, not speeding up them.

overSpeedCruise

When traveling over level ground after a small hill your rover can accelerate to a speed that would not be safe if it needed to make a course change or brake hard or hit a small bump in the terrain. Again, testing will show what speeds your rover can handle. When Rover Driver detects your rover traveling faster than this speed (in m/s) it will apply the brakes as specified earlier with cruiseSpeedBrakeTime.

overSpeedDownSlope

When the rover detects it has pitched down below levelSlopeAngle it will cut the throttle and reduce speed to this setting (in m/s) and maintain it with braking events as long as overSpeedDownSlopeBrakeTime. The main reason you want to travel slower down a slope is bottoming out your rover if the slope returns to flat and level suddenly. Anything close to the ground attached under your rover could be destroyed against the terrain if the shocks can't absorb all the downforce.

underSpeed

If the throttle was cut due to leaving level ground, then when the rover returns to a positive slope the throttle will be reset to cruise speed. But if this happens when the rover is traveling near overSpeedCruise, another braking event or two will likely be triggered. To avoid this, when returning to positive slope Rover Driver will not re-apply the throttle until the rover speed has dropped below this value minus overSpeedCruise. So a rover that can't go faster than 10m/s with an underSpeed of 2 will not re-apply throttle until speed drops below 8m/s.

approachDistance

The distance in meters tells us how far from the waypoint we should begin to slow down in preparation to stop or turn to the next waypoint. You don't want your rover changing directions at speed. This value will be tweaked in conjunction with the next one below.

approachSpeedReverse

When you hit approachDistance from the target, a negative throttle value will be applied to start gradually slowing the rover down. The slower your cruise speed, the lower this number should be. Similarly, the farther away you start to slow down from the waypoint the less reverse throttle you will need. There's also the fact that your waypoint may be on a slope, but Rover Driver has a way to handle that so this number should assume you are on level ground. If you get these numbers wrong and the rover slows too much and stops short of stopDistance, Rover Driver will nudge it forward to close the gap.

stopDistance

The distance in meters from which you should apply the brakes to bring the rover to a stop near the waypoint, or begin your journey to the next waypoint if there is one. You can run over flags, it's okay.

levelSlopeAngle

This defines the range in which cruiseSpeed is an acceptable throttle setting. A value of 2 means slope from -2 to +2. In regards to downslope speed control, you don't want to be driving at cruiseSpeed down a slope that could cause you to bottom out as described earlier. In terms of upslope speed control, you don't want the increased throttle to remain in effect too close to 0 slope where acceleration will be greatest and possibly not fully controllable by the length of cruiseSpeedBrakeTime.

slopeApproachMultiplierUp

A throttle setting that is multiplied onto the current slope angle to get the rover to its destination in the event that it comes to a stop short of the waypoint. So a value of 0.15 will yield a throttle of 0.3 on a 2 degree slope. This is also applied when the rover first comes within range of the target to tweak approachSpeedReverse depending on slope. In other words if you have an approachSpeedReverse of -0.5 but are climbing towards the target on a 4 degree slope, then the multiplier can reduce the amount of reverse throttle as the slope will help slow you down.

slopeApproachMultiplierDown

Similar in every way to the previous setting, just applied to downslopes. As usual, testing will tell you roundabouts what value works best for your rover.

driveMonitorWaitTime

When the BeginDrive or ResumeDrive programs are run, they wait several seconds (originally hardcoded to 5) before calling the MonitorDrive program. This was done initially just so the slope readings could normalize before being used to dictate the rover's behavior. However it was found on some ResumeDrive calls that the rover would fail to get up to speed when restarting on unlevel ground and trigger a slope abort. If your rover is slow to accelerate, you can increase the time the program waits until it begins to monitor the rover's behavior.

autoWarp

Despite the amazing fact that your rover is getting to where it needs to go on its own, it will still take time to get there. The best you can do to make this faster is apply 2x physical time warp. Anything faster will dump too many physics calculations to make Rover Driver function with assured control. Also, since the rover is maneuvering mostly at waypoints, it's best to do that at 1x physical warp. With autoWarp enabled (default) Rover Driver will automatically increase to 2x warp while driving and reduce to 1x warp on waypoint approach, jumping back to 2x warp if it needs to resume driving to the next waypoint.

abortReverse

When your rover is traveling up a slope greater than upSlopeAngle and its speed drops below slopeAbortSpeed, the drive abort system will kick in. When abortReverse is enabled (default), the rover will back down the slope until it reaches levelSlopeAngle, then apply the brakes and end the program. If you disable this feature, then the rover will simply park itself on the slope and end the program. It could potentially slide down a ways, but you would hope the brakes would make this a slow and safe process. You would hope.

Stat Tracking and Data Logging

Rover Driver keeps track of numerous aspects of your drive to help you see what the rover was up to while you were away. You'll get a nice display of all these stats when you reach the end of your drive. If your drive is aborted for some reason, you can still see the stats by running the FinishDrive program. The real-time output display will show the most recent log messages but you can call edit roverlog. to see the complete list of logged data after the program has terminated. Of the stat/log variables defined in the BeginDrive program, there are only a few that should be modified.

speedCheckInterval

This is the number of seconds after which the program will poll the surfaceSpeed to see how fast you are traveling. This will go into a list of speeds from which an average speed can be calculated. The longer the drive, the larger this number can be. At the same time, the larger this number the longer it will take for your ETA to display a fairly accurate time. Also, as soon as you hit approachDistance your speed will not be logged until after you have regained momentum on your way to your next waypoint.

resumeTravelTime

This is the number of seconds to wait until speed logging is resumed after leaving a waypoint. Just like how logging is disabled on approach, this is so your average is not messed up by slower speeds that don't represent your normal travel. However long it takes your rover to get back up to cruise speed once it departs a waypoint is a good setting for this number, maybe a little less since after this time expires the program will still have to wait however long speedCheckInterval is.

avgSpeedETASample

The maximum amount of recently-logged speeds that will be averaged out and applied to the ETA calculation shown on the real-time output window. The larger the number the more accurate your ETA will be, but remember that this means more iteration to pull all the speed checks out of the list for averaging on each program loop so it shouldn't be too large to avoid performance issues.

detailLogging

Setting this to false will remove a lot of logging that deals with how the rover is reacting to the current slope angle it is experiencing. Keeping this on makes it a lot easier to see what the rover is doing as opposed to watching the Rover Variables in the ouput window, which tell you the same thing just not as plainly. But to vastly reduce the size of your log file this can be disabled.

Change Log

8/6/14 - Pre-Release #5
- Added abortDrive flag to the output screen
- ResumeDrive no longer reprints the day to the log if the drive is resumed the same day
- Physical warp is now triggered regardless of how slow the rover is moving when autoWarp is used

7/29/14 - Pre-Release #4
- Fixed downslope detection on slope abort from triggering and possibly causing problems when the rover backs down
- FinishDrive now redraws the whole screen for when used after program is aborted by error or user
- Removed the deprecated brakeOverUse variable
- Fixed how approach speed multipliers were being applied - was subtracting from a negative number to decrease it towards 0 instead of adding
- The amount of time until the monitor program kicks in is now settable. Mainly to allow rover to get up to speed to avoid slope aborts when restarting on unlevel terrain
- Wasn't using the currentBrakeTime environment variable properly in cases of extremeSlopeAngle to modify the braking length
- Added highest/lowest altitude drive stats
- Reset some environment variables in ResumeDrive to avoid restarting in weird states
- Removed flickering from real-time output window at the very slight expense of update frequency
- Redid the Rover Variables section of the real-time output window to make it possible to see the behavior of the rover on various slope angles without needing a ton of log spam

7/28/14 - Pre-Release #3
- Initial Github commit and start of change tracking

Edited August 6, 2014 by Gaiiden

[Pondafarr]

I've been following your progress with this, can't wait to try it out!

[Drew Kerman]

You can try it out right now, which is why I posted the code.

Or were you saying that you just don't have time to try it out at the moment but would like to soon? Either way, let me know what you think! I won't be able to do more work on it for at least a day or two as other things in the game require my attention for now.

[Pondafarr]

I got the preliminary code the other day from the KoS thread, now I have updated it with your release version. Still pending building a rover to USE this code. Been real busy with my own SSTO script.

Be aware, I'm likely to steal (er, borrow) bits of code I think i can modify to my needs (path-finding and such). My SSTO is almost done, and my code (mostly) works, just needs a bit of tailoring and finding ways around craft-specific portions. Test with one SSTO, fix problems...test another SSTO, fix problems..rinse and repeat until batshit crazy or its done! Easy!

[Drew Kerman]

whatever, the code is licensed under the WTFPL

Changed to the Unlicense as that is what is supported by Github

Edited July 30, 2014 by Gaiiden

[Drew Kerman]

Alright, events in my game finally let me drive and test some more and things are looking good. The drive abort system that caused my rover to crash and burn last time now works, I tested it against a 19 degree slope and the rover made it back down to level ground in one piece this time.

Pretty much the only thing keeping me from releasing this is I still get string reference errors when selecting a new target, despite several attempts at pausing the program to the next tick to ensure that the target structure is filled out properly. It only happens now and again, which is even more annoying It's a confirmed issue over on the kOS github so hopefully they will get to it soon. For now, as before, anyone who wants to check it out can do so. I prettied up the post more towards what I will want for the release thread. Contemplating a video.

I'm still not using 0.24 yet so this has only been tested under the last v12 release. Although I will likely install a vanilla 0.24 just for v13 since it has the new PHYSWARP ability, as my autoWarp function sometimes sets 2x timewarp before the rover starts traveling fast enough to automatically enable physical warp and instead just gives you the "cannot warp while moving over land" message on the screen.

Edited July 22, 2014 by Gaiiden

[Drew Kerman]

Boom chaka laka

unfortunately, as you can tell by the distance readout in the output window, this wasn't a seamless drive. I also managed to bottom out the rover and destroy a battery attached underneath. And I flipped it up onto its nose once, and there were lots of bugs in the code - but they all got solved along the way! I'm pretty confident my next drive could be done all in one shot.

I figured out why the target bug was still giving me problems, and that issue is resolved even if the underlying problem is still there.

Next I'm going to see if I can operate the latest kOS release under 23.5 because barring any major bugs I discover on my next drive there's just one little thing bugging me in that sometimes when starting the drive the rover doesn't get up to speed fast enough for the kOS script to kick it into physical warp. With the latest kOS I can specifically tell it to jump to physical warp not normal warp.

I have the project hosted on GitHub now in advance of the v1.0 release over in the showcase forum.

Let's see anything else? Oh yea. Sleep.

[Drew Kerman]

Nuther drive, more bugs squished, more features added. OP updated with new release.

Two things are still keeping this from v1.0 and a Showcase thread:

- The targeting bug. I thought I had this worked around, but it reared its ugly little head on yesterday's drive. But I also changed some code that could have brought it back. I've reverted some stuff and we'll see if I can get a smooth transition to waypoints on the next drive.

- Physics warp. Supposedly a new feature of kOS 0.13 is being able to define the type of warp to set. This is needed because when first starting out, if people have the driveMonitorWaitTime set too short, the rover might not be going fast enough for a call to set warp to automatically kick it into physics warp. The docs have not yet been updated to show how to use this new setting, and I'm still operating under KSP 0.23.5 and despite having kOS 0.13.1 installed the console pops up telling me it's running 0.12.2

Edit: duh, I've realized of course 13.x would incorporate features developed in the pre-releases, so I can actually call the new warp mode under 12.2 - if I can find out how...

Edited July 31, 2014 by Gaiiden

[antgeth]

wow, this may be the kOS killer app i have been waiting for! i will have to try this out.

[Drew Kerman]

wow, this may be the kOS killer app i have been waiting for! i will have to try this out.

Please let me know what you think.

PR5 is released, I finally found out from the kOS devs how to use the new WARPMODE setting so now the problem of time warp not kicking in because the rover is moving too slowly has been solved. The warp mode use still has a bug that will need to be fixed - it won't affect users currently but I might end up having to modify a line of code. That, and the fact that the targeting bug is still an issue, means no v1 release yet still. But other than not acquiring the next waypoint every now and then, the program is "feature complete" in terms of what I want in v1.

[Drew Kerman]

Haven't found any reason to work further on this. I won't need any new features really until I have to drive around on someplace like Duna. This is ready for v1 release as soon as kOS updates with a fix for the one bug that still persists with targeting and interrupts the drive. Still looking for any feedback if anyone has had a chance to try it out.

[fathed]

psst...

packrat changes incoming

http://i.imgur.com/eDF9sUw.png

I just reinstalled kOS to check out your script, and then I see this over in the packrat thread... but it doesn't look like you mess around with those mods. Either way, still going to check out your script, as I was attempting to write one of these myself, but was getting completely confused by the seemingly random heading numbers.

[BrutalRIP]

i know im necro posting but does this work with the latest kOS

:0.0: i see dead people lol

[FreeThinker]

except for the way you have to enter your waypoints, this is a realy cool mod. I realy suggest you find a way to summon those waypoints into the world using some userfiendly GUI.

[Drew Kerman]

except for the way you have to enter your waypoints, this is a realy cool mod. I realy suggest you find a way to summon those waypoints into the world using some userfiendly GUI.

That's not a priority but def a bucket list feature. I actually just now took a closer look at the Waypoint Manager mod thread and saw you can create custom ones. Won't be able to see if I can make it work with kOS (for nav not creation) till I get home at the end of the month tho

- - - Updated - - -

i know im necro posting but does this work with the latest kOS

:0.0: i see dead people lol

not tested it myself so why not let me know? AFAIK tho nothing in the recent kOS updates should have broken anything

[Drew Kerman]

Status report! I've decided to abstain from any serious KSP playing until v1.1 drops (and stabilizes in both release and mod support) so don't expect any work on this script until then. I'm eagerly awaiting a return to this though to add support for kOS' functions, direct part access and also integration with Waypoint Manager as a replacement for targeting flags placed along the route - will be much more user-friendly!!