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).
There's a much easier way to do this, though. The trick is, you figure the route backwards from the destination. For each position on your map, you end up with a minimum cost route to the destination. During computation, you have to keep a list of "boundary" points (starting with just the destination point) each time you iterate through this list, the boundary expands. When it reaches the start point, you're done. A boundary point has a known minimum-cost path to the destination, but it has neighboring points for which this hasn't been computed yet.
The rule to expand a boundary point, X, is, first, find each of its neighbors (even the neighbors that already have costs -- this is very important) and compute the cost from that neighbor (call it Y) to X. Add the known cost from X to the destination, and see if this estimate of the cost from Y to the desination is better than the cost that Y already has. If it is, store that cost in Y. If there's already a better route from Y to the destination, don't bother. If Y had no cost in it at all (that is, this is the first time we've added a cost to Y) or if you improved the cost, add Y to the end of the boundary list. Finally, when we've processed all the neighbors of X, delete X from the boundary list.
It may be safer to store the new boundary in a separate structure from the old one, just because you must be very sure that you don't start using any new boundary point until ALL of the old ones have been fully processed. Another point is that the program ends not when the start point BECOMES a boundary point, but when it ceases to be one. (That is when it becomes an interior point.) For something like the rover, that's a fine detail, though.
This is called dynamic programming, and it is far and away the best way to handle a problem of this type. I can't see any reason anyone would consider using a different algorithm, unless the memory constraints are very, very tight.
--Greg