check

Here you go. Nothing fancy.

Works pretty well. Much less likely to flip the rover over, I found. The trade off is your stopping distance is increased.

The script can be used for any rover, I suppose. It does have a couple of lines in there that checks if the solar panels are catching the sun and if not, it turns on the headlights The version of the script I have saved now says I had the nominal speed set to about 14 m/s (this was a couple of months ago) but I think with this run I set it lower--maybe 8-10 m/s? kOS really lags the game after running it continuously for more than 15-20 minutes so the drive was actually slower and more laggy. Code: clearscreen. Print "Duna Pole to Pole by check". set waypoint1 to latlng(-41,-10). set waypoint2 to latlng(-35,-18). set waypoint3 to latlng(-28.5,-24.3). set waypoint4 to latlng(-28.3,-30.2). set waypoint5 to latlng(-19,-42). set waypoint6 to latlng(-7.8,-35.9). set waypoint7 to latlng(1,-19). set waypoint8 to latlng(4.6,-13.8). set waypoint9 to latlng(8,-5.5). set waypoint10 to latlng(17,17). set waypoint11 to latlng(31,37). set waypoint12 to latlng(47.5,44.8). set nextwaypoint to waypoint1. set w to 1. until w = 13 { lock wheelthrottle to -0.2. wait 3. lock wheelsteering to nextwaypoint. lock wheelthrottle to 0.1. wait 5. lock wheelthrottle to 0.5. until nextwaypoint:distance < 50 { print "Waypoint "+w+ " "+nextwaypoint distance at (3,3). if inlight = "True" {lights off.}. if inlight = "False" {lights on.}. set x to up - facing. set attitude to sqrt((x:pitch)^2+(x:yaw)^2). if attitude > 2 {unlock wheelsteering.}. if surfacespeed > 14 {lock wheelthrottle to 0.1.}. if surfacespeed < 14 {lock wheelthrottle to 0.5.}. if surfacespeed > 18 {lock wheelthrottle to -0.1.}. if attitude < 2 {lock wheelsteering to nextwaypoint.}. }. set w to w +1. if w = 2 {set nextwaypoint to waypoint2.}. if w = 3 {set nextwaypoint to waypoint3.}. if w = 4 {set nextwaypoint to waypoint4.}. if w = 5 {set nextwaypoint to waypoint5.}. if w = 6 {set nextwaypoint to waypoint6.}. if w = 7 {set nextwaypoint to waypoint7.}. if w = 8 {set nextwaypoint to waypoint8.}. if w = 9 {set nextwaypoint to waypoint9.}. if w = 10 {set nextwaypoint to waypoint10.}. if w = 11 {set nextwaypoint to waypoint11.}. if w = 12 {set nextwaypoint to waypoint12.}. }. lock wheelthrottle to -0.1. wait until surfacespeed < 3. brakes on. unlock all. It only made it past waypoint 1.

I made the following video over a month ago, but just uploaded it now. It's a timelapse of a completely autonomous rover drive over Duna, guided only by a kOS script. The script accounds for the rovers speed and attitude so it doesnt make adjustments to heading when the rover is going too fast or is on uneven terrain, minimizing (but not completely eliminating) the risk of flipping over. Video Script: clearscreen. Print "Duna Pole to Pole by check". set waypoint1 to latlng(-41,-10). set waypoint2 to latlng(-35,-18). set waypoint3 to latlng(-28.5,-24.3). set waypoint4 to latlng(-28.3,-30.2). set waypoint5 to latlng(-19,-42). set waypoint6 to latlng(-7.8,-35.9). set waypoint7 to latlng(1,-19). set waypoint8 to latlng(4.6,-13.8). set waypoint9 to latlng(8,-5.5). set waypoint10 to latlng(17,17). set waypoint11 to latlng(31,37). set waypoint12 to latlng(47.5,44.8). set nextwaypoint to waypoint1. set w to 1. until w = 13 { lock wheelthrottle to -0.2. wait 3. lock wheelsteering to nextwaypoint. lock wheelthrottle to 0.1. wait 5. lock wheelthrottle to 0.5. until nextwaypoint:distance < 50 { print "Waypoint "+w+ " "+nextwaypoint distance at (3,3). if inlight = "True" {lights off.}. if inlight = "False" {lights on.}. set x to up - facing. set attitude to sqrt((x:pitch)^2+(x:yaw)^2). if attitude > 2 {unlock wheelsteering.}. if surfacespeed > 14 {lock wheelthrottle to 0.1.}. if surfacespeed < 14 {lock wheelthrottle to 0.5.}. if surfacespeed > 18 {lock wheelthrottle to -0.1.}. if attitude < 2 {lock wheelsteering to nextwaypoint.}. }. set w to w +1. if w = 2 {set nextwaypoint to waypoint2.}. if w = 3 {set nextwaypoint to waypoint3.}. if w = 4 {set nextwaypoint to waypoint4.}. if w = 5 {set nextwaypoint to waypoint5.}. if w = 6 {set nextwaypoint to waypoint6.}. if w = 7 {set nextwaypoint to waypoint7.}. if w = 8 {set nextwaypoint to waypoint8.}. if w = 9 {set nextwaypoint to waypoint9.}. if w = 10 {set nextwaypoint to waypoint10.}. if w = 11 {set nextwaypoint to waypoint11.}. if w = 12 {set nextwaypoint to waypoint12.}. }. lock wheelthrottle to -0.1. wait until surfacespeed < 3. brakes on. unlock all. Note: It didn't get much past waypoint 1. lol.

A couple of months ago, I wrote a script for the kOS mod which would autonomously guide a rover across Duna. It's a little more complicated than just setting a waypoint in the script and locking the wheels to that location. If you've used kOS with rovers you'll know that as soon as you hit an incline your rover will go mad and flip over if it's locked to a target. The script accounts for the rovers speed and attitude by unlocking the wheels over uneven ground and only making adjustments to heading when the speed is low. Anyway, here's the video! It takes place over 4 hours but the time has been sped up by a factor of 80.

Thanks for the reply. That's a shame.

Would SpaceX seriously consider non US citizens or permanent residents? I'm a Canadian citizen living in Canada but would love to work for SpaceX if they were to sponsor a work visa.

I have no idea how you would build a system that would be able to take and store pictures over the course of 5 billion years. Even if the system was 99.999999% reliable every year and you built a billion of them for redundancy, the odds of any one of them still functioning after 5 billion years is virtually zero.

I'm all for this. I was very into kOS until it was abandoned (or but on hold, or whatever)... It has so much potential. A couple of suggestions: Goto statements. The ability to plot points or lines or circles to make simple graphics. Ability to read attitude from the nav ball and not KSPs raw, native, crazy, unhelpful coordinate system.

Now that we have the ability to set a thrust limit on individual engines, ir'd be a good idea if we could assign a way to increase or decrease the thrust limiter using the action groups. IE, you control throttle settings with shift and ctrl as you normally would, but you could use the 1 and 2 keys to increase/decrease the max thrust on the engines that you assign to those action group keys. That is all.

Kaku annoys me. He's made sure that every news organization has him in their Rolodexes for any time they have a science story that they want someone to comment on. Often times it's to comment on a topic that he's not an expert in (geology, geophysics, climatology, biology etc.) and many times he makes ridiculous claims or errors. Even on the odd occasion when he's talking about an astronomy or astrophysics story, he'll make make some silly exaggeration or mistake. Nobody's perfect, I get that, but he likes to hype the hell out of stories to the point where seems like he's just making stuff up. I wish that when the news people needed a scientist's perspective on something, they would contact an expert in that particular field and not a media whore.

Not sure where the demand would come from... Perhaps some commercial entities would want to launch sizeable (Skylab size) 'space hotels' in one shot, with it?

That would have been much better, but still not optimal. The Shuttle, in the end, didn't need a 2000 km cross-range capability. And if it were used for station building soon after it entered service, it also wouldn't have needed the ability to return a 14 ton payload back to Earth (The Space Lab missions wouldn't have been necessary with a station).

Yeah, the major problem with the Space Shuttle was that it was much too capable for what it ended up being used for. It could have completed the vast majority of its missions if it was a smaller, leaner, cheaper and safer craft.

The processing lab definitely needs to be tweaked. I like that you can clean out experiments with it for reuse, and that there's a transmission bonus but, if I have to send kerbals for the lab to work anyway, then I'm just going to return the data with the kerbals, rather than taking the transmission loss (even with the bonus). Now, if we could get a data bonus to any stored data, whether we transmit it or physically return it, then it makes sense to bring the processing lab along. Otherwise, if you're sending a kerbals and plan on having them return, then the processing lab only makes sense if you'd be saving weight by cleaning out experiments with the lab, or sending a whole bunch of clean experiments.... 3.5 ton processing lab + 1 goo and 1 Science Jr vs x number of 0.15 ton goos or 0.2 ton Science Jrs.

Being able to see the current game date and time while the game is running would be useful if you're aiming for a specific launch window. Currently, the only way to see the current game date (year, day) is to exit to the tracking station and look at the date in the top left. This is problematic because if you're sitting on the launch pad and want to time warp to a certain day, you need to warp a bit, stop, exit to the tracking station, look at the date, go back to the game, warp a bit more, and repeat. There are some work-arounds but they're fairly clumsy. So anyway, I'm proposing that either in the main game UI, you can see the actual game date and time under the mission time and/or be able to see it somewhere when you're in map mode. That's it. Thanks.

Happens on Earth sometimes too. I've worked in the arctic doing low altitude airborne geophysical surveys and up there, flying at 1000ft looks almost identical as flying at 50 feet. Thank science for radar altimeters.

When (exact time and day) was this taken? What were the camera settings when you took this image? Is this image cropped? Is that's why it's so small? Which direction is north/east or 'up' ? Stretching the levels in the image, there is a spot near Jupiter (presumably) that's brighter than the image noise which MIGHT be a moon if you're super lucky, or a background star... or just image noise. Hard to tell, but if you answer the above questions then maybe we can make some more sense of it. Edit: also, could you please post the original, uncropped, image and confirm that the zoom is exactly 6x? If we know the field of view of the image and the exact time it was taken, it'll be fairly straight forward to overlay the image onto a screenshot of planetarium program and see if anything lines up. Edit2: missed the part where you said it was taken with an iPhone... yeah, that's very unlikely if not impossible that you'd be able to image a moon of Jupiter. Digital 'zoom' is not actually zoom. it's just stretching an image digitally and not adding to your ability to resolve anything.

It's a composite of several dozen images taken by a camera on the rover's robotic arm and cleverly stitched together and projected in a way that makes it look like a selfie.

I'm going to assume that the images that are being released through the Chinese news outlets aren't the actual, raw images/videos, but rather rescaled and compressed JPEGs. It doesn't seem like the Chinese have set up a website to release raw images as they get them like the Americans do for Curiosity or the MERs. I could be wrong though. With regards to why the Apollo 'video' and images look so good, it's because the video was recorded on 16mm film and the still images were also recorded on film. The resolution of film is REALLY good. The TV video from Apollo, on the other hand doesn't look nearly as good to the 16mm video. Comparison: vs

Ah. Cool, thanks.

So Kevin seems to have fallen off the face of the Earth.... what's the deal? Anyone know?

Of course, but even real life spacecraft use ballast.

I think having small (radially-attached battery-size) parts that are very heavy and that could be used for ballast would be helpful in some situations. Example: Often times when players want to attach a rover to their landing rocket, they'll attach one radially and use a fuel tank on the opposite side to balance it out. A ballast part could be used instead. Or it could be useful in adjusting the centre of mass on aircraft. Or for keeping the center of mass low on rovers (prevent tipping). When the aerodynamic model is revamped, ballast could be used for steering of lifting bodies. Ideally the ballast parts could be ejectable, but attaching them to decouplers would work too. Anyway, it's just a simple, super-dense part that could be useful to some people. Thoughts?

In case anyone missed the latest squadcast.... throttling engines independently confirmed for 0.23 I know that that's been requested feature for KOS players...