Could somebody tag up that western ray route for me?

I've got in mind a big project for later this evening...

- Mike

Zoom and overlay of the 'E corridor route' through the Victoria Crater debris apron using the various UMSF terrain models:
Click to view attachment


Higher resolution files can be downloaded here:
E corridor route zoom HiRise image 25% resolution TIFF (13.9 Mb): http://www.speedyshare.com/897403843.html
E corridor route zoom James Canvin 20081001 1435 FT terrain model 25% resolution TIFF (13.5 Mb): http://www.speedyshare.com/289868443.html
E corridor route zoom Mike Malaska 20081002 0057 differential shift 10E5S terrain model 12.5% resolution.tiff (3.5 Mb): http://www.speedyshare.com/368252144.html
E corridor route zoom Fran Ontanaya 20081001 0742 terrain model 12.5% resolution.tiff (3.4 Mb) : http://www.speedyshare.com/429750675.html
E corridor route zoom Bill Butler 20081006 1532 2dfft terrain model image overlay.tiff (8.5 Mb): http://www.speedyshare.com/634581802.html
E corridor route zoom Geert Sassen 20081003 0007 terrain model overlay.tiff (739 kb): http://www.speedyshare.com/547985714.html

-Mike

Good work!

The problem I see with this easterly route is that during the second half of your track you seem to cross some quite scary looking terrain while still proceeding east (southeast originally, then turning east). If I zoom in on the full HiRISE images for this part of your track, the terrain looks very nasty and there doesn't seem to be much of a clear road proceeding east, you need to run straight against the ripples which will be bad.

The route I outlined earlier crosses the worst terrain on a southerly track, it doesn't win you much terrain on an easterly direction though... One of the big worries is off course how long we can still proceed on 6 wheels, so I have the feeling we need to cross the 'bad' terrain as fast as possible, no matter in which direction, and get on a bit more even terrain where we might possibly be able to continue with 5 wheels, even if this means driving a longer route...

However, I'm not a rover-driver, there might be other options etc, also we don't know what the new HiRISE images will tell us on the terrain further on...

So, how far could Oppy drive in one sol? (dawn to dusk, commands downlinked the previous sol, results uplinked the next sol)

Here is ~500 meters, all green in one of James Canvin's analysis.

Click to view attachment

Here is the historical track of Oppy's route overlaid onto a green-blue-red differential shift terrain model of Backshell to Endurance Crater.
A crop of Phil Stooke's route map shown for comparison.

[EDIT 20081011 2328: corrected version in next post]

-Mike

(Gee, wouldn't it be interesting to compare predicted terrain with past navcam views?)

CORRECTED version of Oppy's historical route overlaid onto a green-blue-red differential shift terrain model of Backshell to Endurance Crater.
A crop of Phil Stooke's map shown for comparison: (http://www.planetary.org/image/oppo-stooke-map.jpg)
Click to view attachment

-Mike

Oppy's route overlaid onto a green-blue-red differential shift terrain model of Endurance Crater to Vostok Crater.
A crop of Phil Stooke's route map is shown for comparison. (http://www.planetary.org/image/oppo-stooke-map.jpg)
Click to view attachment

-Mike

Oppy's route overlaid onto a green-blue-red differential shift terrain model of Vostok to Erebus Highway.
A crop of Phil Stooke's route map is shown for comparison. (http://www.planetary.org/image/oppo-stooke-map.jpg)
Click to view attachment

-Mike

Oppy's route overlaid onto a green-blue-red differential shift terrain model of Erebus to Etched Terrain.
A mosaic of two of Phil Stooke's route maps are shown for comparison.
Both of Phil Stooke's maps are available at: http://www.planetary.org/blog/article/00000611/
Click to view attachment

-Mike

[BTW: While digging through the Opportunity Route Map thread, I found this "blast from the past" ]

Oppy's route overlaid onto a green-blue-red differential shift terrain model of Etched Terrain to Beagle Crater.
Phil Stooke's Sol 909 route map is shown for comparison.
(available here: http://www.unmannedspaceflight.com/index.p...st&p=64443)
Click to view attachment

-Mike

Oppy's route overlaid onto a green-blue-red differential shift terrain model of Etched Terrain to Beagle Crater.
A mosaic of Eduardo Tesheiner's Sol 931 and Sol 1202 route maps are shown for comparison.
(Sol 931 route map; Sol 1202 route map)
Click to view attachment

-Mike

Previously traversed examples of Green terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that would normally cross the N-S dunes crests.
Click to view attachment Click to view attachmentClick to view attachment

"Parking lot"

-Mike

Previously traversed examples of Aqua terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that traverse the N-S dune crests.
Click to view attachmentClick to view attachment

"Parking lot with ripples."

-Mike

Another example of an Aqua terrain. This time Oppy traversed the dunes in a perpendicular direction (with little problem).
Click to view attachment


-Mike

Thanks Mike,

tremendous job you did, but it sure helps s lot to get a perspective of what we can expect looking at the terrain on the HiRISE images!

I guess all together we have produced enough data with this analysis for a book !

Regards,

Geert.

I think you still need to make some predictions. There are now ample examples of terrain where rovers had no problems as well as terrain where they did have problems. That should be enough to define an algorithm to estimate risk for any particular drive direction. One could do that by hand, or one could train a neural net to do it. (Or perhaps an SVM might work better, if you can settle for answers like "Yes, drive this way" and "No, don't go that way.")

Anyway, given an algorithm that gives hazard ratings to different directions, it should be a simple dynamic programming problem to pick an optimal path from any given starting point. Or has someone tried this already?

--Greg

a book

Maybe not. BUT - a science paper, yes.

Doug

This one in particular is very heartening indeed!

I'm working on that more or less, but it is not as easy as it sounds

Presently I'm able to produce "optimal" routes given a certain starting point and a destination, more or less by letting the software analyze all possible routes and then selecting the most promising one. Selecting factor is then the standard deviation in brightness of all pixels on the selected route, assuming a higher stdev value will indicate a rougher route. The route shown in my earlier message is an example of such a computer calculated route.

Problem is that there is far more to it then just the stdev value, and making the software smart enough to recognize the various traps takes a lot of work and to get a more reliable answer you will need a lot more data (preferably some accurate method to measure heights of ripples and type of surface material), I doubt whether you can ever extract that from only the HiRISE imagery.

Presently I'm working on a method to incorporate the various other analyze-methods into this route-selection, however problem with this is that many values are 'multi-directional' and what I need is a directional-value. In other words, they show you 'this position is good/moderate/bad' but what I need is a value that indicates 'driving in this direction from this position is good/moderate/bad', there are many examples of situations in which you can easily drive in one direction but get problems if you drive into an other direction.

Most of all however what I need is simply time to work on these types of algorithms, and presently I simply don't have enough free spare time

You need a function that given a position and a direction, returns a value. For any given position, you call the function for all directions and choose the best one. That function is going to be calling itself recursively, until you get to the position that neighbors your destination, at which point the function is going to return happily (zero), or until it hits a red spot, at which point it returns unhappily(1). Good routes would have low values-- all green equals zero. Between green and red is a floating-point value, but you needn't assign it linearly. How you determine what value to return is the fun part of experimenting, because the weighting given to green vs. blue vs step size is going to cause big differences in whether it goes out of its way to stay green versus plowing straight through blue. (ploughing strait threw blew-- gotta love engrish)

So, you give it a starting point, a destination point, a step size, a function of assigning floating-point values to colors, a field of play and you get one most-optimal route. You then vary the step size and value function and use your eyeballs to choose the ones that look like they have the best tradeoff between distance and being conservative.

I'm pretty sure that's dynamic programming, but I'm a bit hazy on the details. Prof. Cormen wouldn't be proud, but that class was eight years ago. (Edit: Ah yeah, reading wikipedia makes it clearer that dynamic programming would build a solution set to avoid recursion calculating the same information a gagillion times. So if the lazy try seems to lock your system up, I guess you start building a data structure, and have the function also return from points that are already in the data structure.)

I think we're getting there.

I'm shooting for a way to evaluate and compare proposed routes whether generated by algorithm (like Geert's) or by eyeball (Alan's, and the E Corridor Route).

I think that by looking at terrain models from Oppy's past drives that a scoring function can be developed based on how difficult it was to drive on a particular color terrain at a given heading (cross dune or in the half-pipe). This might actually be able to make a time estimation of how long it will take to do a particular route based on selected historical values.

So a short red route might end up taking the same amount of time as a long green route.
(Taxicab geometry problem with freeways included.)

-Mike

Previously traversed examples of Blue terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that traverse the N-S dune crests.

Click to view attachmentClick to view attachment

"Bigger Ripples"

-Mike

Previously traversed examples of Violet terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that traverse the N-S dune crests.
Click to view attachmentClick to view attachment

"Dunes"

-Mike

Previously traversed examples of Red terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that traverse the N-S dune crests.
Click to view attachmentClick to view attachment

"Big Scary Dunes" (Don't do it!)

-Mike

[EDIT (20081014 0000): image on Sol 875 wasn't correct. (But very, very similar to image of Sol 842)]

Previously traversed examples of Green terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that predominantly run the troughs of the N-S dune crests (half-pipe direction)
Click to view attachmentClick to view attachment

"Parking lot"

-Mike

Previously traversed examples of Aqua terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that predominantly run the troughs of the N-S dune crests (half-pipe direction)

Also shown is a view perpendicular to the drive direction.
Click to view attachmentClick to view attachment

Note how Oppy straddles a dune crest during the the Sol 384 drive.

"Parking lot with small ripples (can half-pipe or rail)"

-Mike

I'm beginning to make sense of this process through the extraordinary efforts posted here...
Astounding...
Thank you.

Interesting problem.
If I had time I'd love to try and implement this. At first look here would be my suggestion for an algorithm.



With a grid of 5 pixels over the HIRISE image, recursion would be good. Using the grid makes it arbitrary to change the algorithm for more fine grained route planning. You could start with a large grid size to get the algorithm going.

Not sure what languages people are using here, if a collaborative effort was going to start it would be worth getting a sourceforge or google code thing setup. I'll be watching with interest!

Now, have a look to this very interesting paper "The Mars Exploration Rover Surface Mobility Flight Software: Driving Ambition" in section 5. Autonomous Driving:

"In Terrain Assessment (or Predictive Hazard Detection) mode, one or more stereo pairs of images are processed into a traversability or goodness map, ... If path selection is also enabled, candidate motion paths are projected into this map (see Figure 3), and a weighted evaluation of the constituent cells is assigned to each path. This results in a set of Obstacle path evaluations; low values indicate a less traversable path, high values indicate a more traversable path."

Similar algorithm as yours is already used by the rovers, obviously on a much smaller scale.

Wow, very interesting paper.

That's one way of solving this problem, and from a very quick look at the rover-software paper this looks like the method used by the rover also, it is often used in situations where you need to solve a more or less 'short term' situation, but it does not necessarily give the best route on a larger scale.

Imagine the following situation: from your present position you have in one direction a 'bad' ripple which will take a lot of time to cross, however after crossing this one and only bad spot you will have perfect flat driving ground all the way to your destination. In an other direction from your present position you have 'reasonable' terrain but it will stay 'moderate' to 'bad' all the way to your destination. If you use your algorithm, the rover will turn to the 'reasonable' terrain as being the best route to go, however it will then have to face unfavorable terrain for the rest of the trip. Even if it arrives, the final route won't be the fastest.

The method I am using is a different approach which often gives better results on the longer scale: basically I'm 'cloning' the rover and sending out (10 to 100) new rovers in all directions, then the terrain analysis determines how far they will proceed in their given direction during one sol (some will travel 100 meters, other maybe only 2 meters). Then at each new position, each rover is again cloned and from that position again new rovers are send in all possible directions, with the whole sequence repeating itself over and over again. Finally the software keeps tabs on which rovers arrive within a given distance (f.i. 10 meters) of the destination. Once a rover 'arrives' we can read back the route it has taken. The first to arrive has found the fastest route, etc. While traveling the rovers also keep track of the terrain, so each rover carries a record of the terrain traveled, and we can select on other options (so not only the fastest route, but also the smoothest route, etc, etc).

Using this trick, in the earlier situation the software will find the fastest route, as one of the many 'rovers' will cross the one and only bad ripple and then proceed quickly to its destination, arriving there first where after we can track back the route it has taken. Usually in situations where you have a bit longer distance to cover, this method returns better results then the method described by you (however, each has its uses, from the viewpoint of the 'autodrive' option of the rover the earlier method is the best as there is no way to 'try' all possible routes).

Click to view attachment

Above image is an example of this method, the yellow line indicates the 'direct' line from departure to destination position, the blue and green lines are computer generated routes using above method. Software tool for this can be installed for free from this link. It requires MS Windows XP/Vista with .Net 3.5SP1 environment and IE7+ (will automatically update). Software is written in VC#, if I can find the time (..) I will write the same in Java also for those with other OS's.


Problem offcourse with this method is that the number of 'rovers' which are 'underway' very quickly gets very big (as each rover is cloned again and again at each new position reached), however it is quite easy to build in some functions which will remove 'stuck' rovers or rovers in 'hopeless' positions so only a certain amount of rovers is allowed to continue on its way, keeping the calculation time within limits.

If I can find the time, I will try to write a bit of an explanation on the use of the software and the methods and algorithms used, however it is all still an 'ongoing project' and I'm still improving on it whenever I find the time.

Wow. You've a major headstart then seeing as you have already implemented a solution! The drive distance per sol is interesting also.

I was thinking about what I said earlier, I started to think about some tree searching algorithms.

One I think would be interesting to use is A*
http://en.wikipedia.org/wiki/A-star_algorithm

This uses a distance+cost approach to selecting a route. Our cost function is made up of the terrain's traversability (is that a word?).



Note: The nodes of course are the grid locations I referred to in my earlier post.

Note 2: Taking what Geert said about time taken to cover terrain, this seems like an important point. Geert, what did you use to estimate how long it would take to travel over a given terrain type? Function based on terrain type could be easily built into this search approach to change cost to couple terrain type and traverse time.

Wow! This is deadly

Hi Geert,

I see this is the Von Neumann Probe method! My experience of programming route-finding like this is that the ballooning number of potential-routes, which initially look quite frightening, are quickly cullable - and that breaking down long routes into a sequence of shorter steps (such as a MER would find with science stops at likely targets) eases the time spent on calculation.

Andy

Definitely, identifying a series of waypoints would break the problem up nicely.

That's where you play with the values assigned to "bad" "perfect flat" "moderate" "...to bad"

If your first ripple returns 0.8, followed by 100 x 0.001, you'd get 0.9 for the total route.
While for the alternative 0.1 for the first step, followed by 80 x 0.1, you'd get 8.1 for the total route. A little shorter, but longer time.

And reading your algorithm description, it seems equivalent:


You've got sendRover(direction, position)... your stop case is arriving at the destination, at which point you stop all the other recursive calls. You might not be doing this recursively, but that's really a matter of using the OS stack versus using your own data structure of routes.

And I by no means want to backseat drive you so much as to dictate your programming choices! I'm trying answer/discuss your query about making the chosen route weigh choices between circuitous-but-easy routes versus straight-but-gnarly in different ways.

So to sort of adapt what I was saying from the recursive algorithm to your problem of having your existing route-finding program: You already have, for each location, a value that corresponds to how long it takes to traverse. What you need to introduce are functions that modify those values, not new "intelligence" or new algorithmic magic. If you try a more exponential function, you will probably start to see routes that steer around obstacles that were previously traversed.

To try to demonstrate what I'm talking about... Given a linear function from your original map that assigns values of 0.0 to 1.0, you may choose a route of 0.3 0.3 0.5 0.4 0.1=1.6 versus an alternative of 0.3 0.3 0.4 0.4 0.4=1.8. With a different function with a goal of penalizing higher values more, like max(0, (value-.2)^2), that might become 0.01 0.01 0.09 0.04 0=.15 versus 0.01 0.01 0.04 0.04 0.04=.14. You are suddenly traversing completely different terrain.

So you might look at the chose route, and look at your data and conclude, "that went straight through an area it should have skirted... I need to give that area a higher value."

You also need could try different time-step sizes other then the "one sol" you currently define.

Terrain analysis is done by standard deviation, basically the software calculates the standard deviation in the brightness of all pixels along the driving vector (distance can be set by user), this standard deviation I use as a indication of terrain 'roughness' and thus as a method to estimate maximum possible driving speed in a certain direction.

Click to view attachment

Above is the 'general options' dialog of the software, it allows the user to define certain colors to a certain stdev value, this is where the red/blue/green fields originate from (basically you can set any color for any value of stdev). I define the terrain as 'very rough', 'rough', 'moderate', 'smooth', and 'very smooth' with each of them a maximum value for stdev, all can be set by the user so you can experiment which value's will give the best terrain picture. Apart from this the resolution of the resulting analysis can be set, as well as the sampling rate and the spacing between the sampling points. Basically I try to make the whole calculation as flexible as possible, with as much as possible all settings configurable by the user, so you can 'play' with the thing to find the best settings.

Click to view attachment

The second dialog defines the route-finding options. Here you can define the distance in meters per sol that the rover can travel in each type of terrain, thus the values for 'very rough' to 'very smooth' terrain you defined earlier are now translated into maximum distances traveled per sol. Once again I leave it up to the user to set these values, so for instance if we lose one wheel, values can be changed correspondingly and the software will still function. Other values which can be set define the maximum number of cycles the software will calculate, the number of 'rovers' which start from each new position, and the maximum number of rovers allowed to continue each cycle. Once again, it's all up to the user, allowing more 'rovers' to search for a route and/or more processing cycles will result in higher accuracy but longer calculation time (on my very average laptop, the most labour-intensive calculations can take up to 15 minutes with average settings). Finally, it is important to correctly set the scale of the image (meters per pixel) in this dialog.

Click to view attachment

After loading an image (unfortunately the software can not yet handle jp2 images, so you need to convert to jpg/tif/png etc first) and setting above value's you can manually enter waypoints by checking the green cross button and clicking on the image, each time you click a new waypoint is entered and a yellow line is displayed connecting your waypoints and defining your manual route. The number of waypoints is unlimited. You 'close' the route by pressing the red cross button, where after the route is analyzed and total distance, average and maximum stdev value, and estimated travel duration are displayed. By clicking on the 'autodrive' button (highlighted in above screendump) you start the computer-calculation. Presently the software will ignore all manual waypoints apart from the first and last waypoint, so it will calculate the fastest and smoothest route between departure and destination. This route will then also be shown on the image, and distance etc will be displayed. There are a lot more possible tools and calculations, but this is the very basic of the thing.

Once again, it is still far from perfect, whenever I find the time I continue work on this but my time is very limited so quite often I have to trade functionality of the software against available coding-time... Don't expect a fully functional professional piece of software for this isn't it, it's a temperamental piece of software written primarily to get results, I don't have the time at hand to make it 'fool-prove' and 'flashy' On starting up, the software will automatically check for the latest version, and download updates if and when available.

For anyone interested: a free download and installation is via this link You will need to load the url in IE7+ for the installation to work.

Fully agree with you, I don't intend to simply enter Victoria as departure point and Endeavour as destination, not only would this require tremendous files (you will need something like 1 mtr / pixel resolution to get reasonable results) and likewise very long calculations, but it would simply be an unrealistic approach as the true route will also be dictated by science-targets enroute.

Presently I'm working on following items:

1) allowing intermediate waypoints between departure and destination (basically: "find the best route from A to D which passes positions B and C"), this is quite simple and requires only minor changes to the software routines (the 'manual' route can already include an unlimited number of waypoints).

2) allowing other methods of terrain analysis. One method to implement this is simply offering the option to 'switch off' the stdev calculation and let the 'grade' of the terrain (from 'very rough' to 'very smooth') depend completely on either the pixel color or the pixel brightness at the present location. If I do this, the software would be able to run on a pre-processed image from any one of the other methods.

3) defining a geographical overlay of an image, which would allow waypoints and positions to be defined in latitude/longitude coordinates instead of pixel locations, this makes it easier to copy routes to different images/maps/etc.

But once again, my time is very limited so don't expect fast results

Nope, the calls do not stop when one or more 'rovers' arrive at the destination, it just continues for a user-defined number of programming cycles. What happens is that each rover which 'arrives' is dumped into a list and "stopped", and only after completing the set number of programming cycles all arrived rovers are questioned and their routes analyzed. This allows for selecting routes on other criteria then 'fastest route' alone. You might wish to set values to maximum or average terrain encountered, etc, etc, so the first rover which arrives might not have traveled along the desired route. Each software rover keeps track of various factors (average stdev value, maximum stdev value, etc) and these can be questioned afterward.



Fully agree with you. What I have been trying to do is keep as much as possible all these choices to the software user itself, so almost any variable in the whole calculation can be changed by the user. And indeed, changing these variables often completely changes the route which is calculated, trick is in finding the 'correct' values...

With regards to your location-value, note that in fact each vector has a certain 'weight', this is also my problem in incorporating other analyze-methods into the software. In one position you might run in to big problems on a westerly course while running in a southerly course will be okay, so you can't say "this position is okay", you need to say "this position is okay for a southerly course".

The red/blue/green maps are wonderful and extremely important for getting an overview of the terrain but they don't work on the scale of route-finding as they are non directional. In my opinion we should take the following steps:

1) Manually define a number of waypoints and a 'general' route from the various earlier produced colored analysis.
2) Use the various route-finding methods to create a route from one waypoint to the next along the route found under option 1 (Note this is not only software calculations but can just as well include manual analysis of terrain!).
3) Analyze the defined route using various options (total length, estimated duration, terrain encountered, etc).

After step 3, try to think of a different route and repeat steps 1 to 3, until there are various routes, then finally compare all routes found.

Although I enjoy discussing all the software-issues of route-finding, we should not forget to take step 1 first ! As yet there is not much discussion on the 'general route' and I think that should come first before we start to discuss how to get from one waypoint to the next!

Also we need a better method to 'analyze routes', a set of criteria by which we can compare the various route-options, and finally we need some sort of coordinate-system by which we can describe routes ('turn left after the third crater' is a bit vague..). If we all work on the same HiRISE images and on the same scale we could simply use pixel-locations (X,Y) but I think it would be better if we could somehow relate them the 'real' latitude/longitude coordinates or some other type of 'universal' locator-descriptions. Any comment is more then welcome!

All in all I think there is still lots and lots of work to be done, and we must be careful not to get lost along the way...

I hear ya', Geert, and fully agree. Of course, a lot of that work is waiting on the arrival of the HiRISE images (when are they due in again?). Then human eyes are going to have to pore over them at maximum resolution looking for those "waypoints" of scientific interest. I'm willing to do my share, but someone with the smarts and 'heavy iron' is first going to have to convert and subdivide the massive image files into a mosaic of readily handleable jpegs, or whatever, that we can load into Photoshop Elements (sorry! ), and cruise around putting gold, silver or bronze stars on top of large cobbles, clusters of cobbles, fractured bedrock with exposed edges, craters with exposed bedrock, etc. (I'm assuming even Tesh can't spot festoons from orbit )
Lacking other clues at the outset, the most logical order of search would start with grid sections along the SE diagonal connecting Victoria with Endeavour (or that part of the Endeavour rim that is our ultimate destination). Then the searched diagonal would be expanded through adjoining sections to the NE and SW of the diagonal, until an adequate SE corridor to encompass the journey had been searched. That will complete your step 1, and then the area drivability map can be overlaid to cull out points of interest in impassable areas.

It's all good, though I can't guess how long it will take. Still, I'm already wildly impressed with the rate of progress of you and your fellow 'pattern-analysis gurus'.
It is a Grand Odyssey, and I can almost feel the Spirit of Our Exalted Steersman, Paolo, smiling down on us in approval.

Here is a grayscale differential shift 10E5S terrain model that might be useful for route-algorithm development.

This terrain model is for the region S of Victoria. There is no terrain overlay. The pixel brightness is based solely on predicted "drivability". (Black = good; white = bad). Rock pavement is zeroed out and considered like "parking lot", but the dunes on the pavement are incorporated into the model .
Click to view attachment

The edge artifacts have been removed and background set to black (so's not to mess up any algorithms and make a "bright wall")

Here are links to larger versions at 12.5% resolution:
As a TIFF file (10 Mb): http://www.speedyshare.com/792752906.html
As a JPEG (4 Mb): http://www.speedyshare.com/262238303.html

Enjoy!

-Mike

Previously traversed examples of Blue terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that predominantly run the troughs of the N-S dune crests (half-pipe direction)
This is blue terrain in the half-pipe in dunes.
Click to view attachmentClick to view attachment

Also shown is a view perpendicular to the drive direction.

Sol 412 was a record drive in Blue Terrain. Post-Purgatory drives in Blue terrain were much more conservative: Sol 627 is a better example.

-Mike

Previously traversed examples of Blue terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that predominantly run the troughs of the N-S dune crests (half-pipe direction)
This is Blue terrain in the half-pipe on rock pavement.
Click to view attachmentClick to view attachment

Also shown is a view perpendicular to the drive direction.

(Note rut depth in foreground of Sol 781)

-Mike

Previously traversed examples of Violet terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that predominantly run the troughs of the N-S dune crests (half-pipe direction)
This is Violet terrain in the half-pipe in dunes.
Click to view attachmentClick to view attachment

Also shown is a view perpendicular to the drive direction.

-Mike

Previously traversed examples of Violet terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that predominantly run the troughs of the N-S dune crests (half-pipe direction)
This is Violet terrain in the half-pipe on rock pavement.
Click to view attachmentClick to view attachment

Also shown is a view perpendicular to the drive direction.

-Mike

Previously traversed examples of Red terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that predominantly run the troughs of the N-S dune crests (half-pipe direction)
This is Red terrain in the half-pipe in the dunes.
Click to view attachmentClick to view attachment

A view perpendicular to the drive direction is shown.

-Mike

Previously traversed example of Red terrain in the green-blue-red color scheme of the differential shift terrain model.
These are drive headings that predominantly run the troughs of the N-S dune crests (half-pipe direction)
This is Red terrain in the half-pipe on rock pavement.
Click to view attachment

A view perpendicular to the drive direction is shown.

-Mike

Montage of comparison Navcam views for each terrain type:
Traversing dune direction:
Click to view attachment

Half-pipe direction in dunes:
Click to view attachment

Half-pipe on rock pavement:
Click to view attachment

-Mike

Taking the data from the selected* indicated drives, here is a list of distances achieved for the drives shown in the historical navcam images in the above posts:
Click to view attachment

(*I tried to use selected data that was representative of each terrain type. Drives were selected that consistently covered the same terrain type throughout the drive, drives that had distances reported, drives tracks that could be confirmed by navcam images, and drives that seemed "typically long" for that terrain type. Bias is my own.)

My estimates for amount that could be consistently covered per day for each terrain type. (In most cases, this is half the amount covered in the example drives above):
Click to view attachment
[EDIT 20081017 0904 EDT: Revised estimates see below post]

Scoring functions for each terrain type based on estimated drive speeds. This is the amount of time (in drive*days) that will be required to cover a 50 m distance.
Click to view attachment
[EDIT 20081017 00904 EDT: Revised scoring function see below post]

I'll be using these scoring function values to compare and evaluate routes.
By multiplying the number of each terrain type/drive direction with the scoring function, it should be possible to estimate the total time required to complete a given route. Low score will be the faster, more efficient route.

-Mike

Wonderful job Mike, this will allow us to compare routes and get estimates of driving-times, etc!

So, can I pre-order your book about this research?
Really, a printed copy of all these pages is just what we need next to the computer when studying the HiRISE images.

Although my free time is very limited I have been quite busy these days (or nights, more often) with what amounted to a major re-write of the software toolkit, as mentioned earlier I have been busy to relate all image-data to latitude/longitude coordinate data. All previous analyzes and routes were pixel-related, but as they often are in a different scale, different projection, and/or at a different crop they are hard to compare. By converting all data (pixels) to latitude/longitude coordinates I can now basically compare any analyzes with any other analyzes no matter the scale etc and I can 'stitch' together images, combine them, etc, etc. It's a hell of a job but first results are now starting to look hopeful, as soon as I got more I'll post it.

Based on some suggestions and to help simplify things, here are revised drive estimate as well as a revised scoring function:

Revised estimated drive distance per terrain type/heading (m/day):
Click to view attachment

Scoring function (days/50 m box):
Click to view attachment

(Thank you to all who PM'd me!)

-Mike