Hi, all
I want to let you guys know there is a naif0010.tls file due to a new leap second introduced for July 1 of this year. All of the SPICEy trajectory planners i can find at
www.orbithangar.com are still using naif0009.tls. (I want to install it in my thermostat, lol. I live in a no-DST time zone and the silly thing leaped an hour for daylight savings time. *punt*)
Also, particular to this trajectory planner, I am missing all the listings except for waypoint body whenever I make a flight plan, and the optimizer won't run (I put my original post on the thread for the version that doesn't have the MATLAB redist package.) I suspect they are related.
I'm off to bug the other big SPICE supporting trajectory planner thread now to point out his C++ redist dlls don't work...
Terry
---------- Post added at 08:26 PM ---------- Previous post was at 12:57 AM ----------
Now that I've got it working (apparently, it works best in XP/SP3 compatibility mode :huh
, the results are pretty much as good as I could have expected.
Let me tell just a little story to introduce my problem: Once upon a time, there was MarsDrive Consortium, and they want to get people to Mars. To help coordinate their efforts, they set up a mailing list here:
http://groups.yahoo.com/group/MarsDriveMission
Before I go any further off topic, if you get the jist of "Flyby Earth Return Vehicle" and are not interested in the story behind it, skip to the next :thumbup:
It tends to be most productive when the smartest two or three people are hissing at each other like cats but not taking it personally. Currently, the top three cats are Michael J. Bloxham, David B. Gooding, and... what was my name again?
A big problem we had on a previous version was that we needed to assemble a huge vehicle for returning the crew to Earth. Unlike Robert Zubrin (a long time ago, in a galaxy far, far away, he came up with the brilliant idea of making your own fuel on Mars for the return trip, forgetting that landing on Mars is literally pulling a miracle out of thin air to begin with. While his ERV is very elegant, landing directly on Mars and returning directly to Earth, it is also downright enormous and asks the impossible task of building a hydrogen tank both light enough for use in a planetary ascent vehicle and well insulated enough to store liquid hydrogen for something like a year.) We do not ask the impossible of our Destiny MAV, who has the following problems:
1. She needs to fit in the little Stampede Lander we're using. Failing that, her parts from different Stampede Landers must be easy to assemble.
2. As a result of the lander constraint, little other functionality is included with the Destiny first stage, which, until recently, was the only stage.
3. Hydrogen from Earth is shipped in separately.
4. The spacecraft provided for the crew is of limited functio- well... I guess I should just admit that there isn't one: the crew are basically seatbelted to the top of the booster and launched in their spacesuits. I'm oversimplifying it a bit, but that's the jist of it.
5. The launched crew then must rendezvous pretty fast with the ERV, and well...
Due to problems germain to the EDL system, aerocapture started looking
really bad
really fast, and the ERV is just too big to consider aerocapture. Aerocapture was ruled out for capturing the crew outbound element to Mars to wait out the potential global dust storm, and for a time, propulsive capture was used instead. This was also dropped, since if we couldn't provide the same benefit for the supplies, Destiny MAV, and other surface elements, providing it for the crew led to very little benefit. The ERV was a bigger problem. We were launching this little re-entry module with this somewhat larger, but still relatively small space habitat, and to push it out of Earth orbit, capture it into Mars orbit, and then launch it out of Mars orbit once the crew had ascended to it, it had a long string of space maneuver stages attached to it.
Michael's crazy idea: Let's make Destiny go a bit faster (we had kept the ERV in a relatively high orbit, so this idea didn't add a lot of difficulty to the ascent from Mars, relatively speaking) and catch a
flyby ERV as it went past Mars. To pull this off, we added a second stage to the Destiny MAV (more expensive than it looks because we have two Destiny vehicles just in case one crashes during her landing attempt.) This eliminated most of the maneuver stages, but the art of planning this ERV's trajectory is much harder to paint. So far, I have found two brushes. One is STK, which I can't use for a number of reasons. Can anyone guess what the other one is? :thumbup:
So, I've been running an analysis of:
1. It launches from Earth
2. It flies by Mars
3. It comes back to Earth
4. Earliest launch 2023 January 1
5. Latest return to Earth 2026 January 1
6. Weight 0.25 on Departure C3
7. Weight 5.00 on Flyby Delta-v (i.e.: it must be zero, or there's no point.)
8. Weight 1.00 on Arrival speed
So far, I haven't tried anything other than crossoverheuristic, but after watching its travails so far, I'm going to. For selection, I've used selectionuniform, selectionstochunif, and selectionroulette. Selectionroulette has given the best results.
At first, I ran it completely unconstrained, but there is a mission requirement that the return leg is 180 days for the crew, based on a perspective of supply mass, life support state-of-the-art and cosmic radiation exposure. I began applying this constraint more recently.
As a practical matter, the ERV must flyby Mars at an altitude of about 200km where the Destiny MAV can perform the rendezvous kick. I can't apply this constraint in TOT yet, but I'll try to coax out something, possibly by figuring out from the algorithm monitoring window, the behaviour showing when the Delta-v has reached zero and then stopping it manually. The results will suck, but it should be good enough (along with more typical solutions) as an initial proof of concept. I also need something flyable in Orbiter. Another constraint that I am not worried about is that the areocentric equatorial inclination of the ERV's flyby trajectory must be at least the latitude of Destiny's launch site. This could be more significant if we decide to land in Hellas Basin because of EDL problems.
(Note: If you're not otaku no Mars, Hellas Basin is a large area in the southern hemisphere averaging MOLA-8km, the lowest on Mars. Relative to Earth features, this basin makes the Dead Sea look like a backyard gully.)
On the TOT's behaviour.
If it acts like the genetic algorithms that have been generally marketed to prove Evolution (in which, I can usually get much further under the hood than with TOT), it starts out with a bunch of crazy garbage not even Jorde la Forge and Montgomery Scott could team up to fly, except for maybe one or two. These one or two then determine the overall direction of the evolution within a few generations.
TOT almost immediately (I know from stopping it manually) begins to follow an Earth resonant orbit with a distant flyby of Mars, and within a few generations, finds it to be inescapable, even if it is really poor (one was a retrograde two year orbit, with a minimum weight of just over 1000!)
For this reason, I selected a more random selection algorithm with the hopes of it being more likely to "jump" to a better solution. Something else that helps is using a really large population. 50s and 100s usually fail. The highest I've tried is 500 and I've still had it stabilize on a one year orbit with an outbound periapsis near Mercury, weight of about 65, and outbound C3 of about 210km/s2 (note, the real life record is New Horizons at about 100.) To prevent this, I put a constraint on the minimum trip time. I'm going to try some runs with it turned off, as it is not critical to our mission plan. What is critical is a feasible departure C3 (the usual two year orbit gives an outbound C3 of about 27km2/s2, which is a bit high), a survivable Earth arrival speed (the usual is about 12415m/s hitting the atmosphere), and a zero delta-v during the Mars flyby (it usually has about 1 mm/s, I think that's an effect of the algorithm.)
The crossover algorithm seems to affect the "homing" function, and I'd guess there's nothing much that can be done to help the stubborn Pacific Salmon spawning in the St. Lawrence River find the handier Columbia. I haven't fiddled around with vectors enough with textbook and paper to visualize what crossoverscattered would look like, but I'd expect that the fastest homing algorithms would be crossoverheuristic, crossoverintermediate, and crossoverarithmetic. Based on Arrowstar's suggestion, I think that what I call the "tangental" case of parents being nearly equal distance from the minimum is rather rare. In this case, crossoverheuristic would spit the child out on the line passing through the two parent points, on the side of the "mother". In this tangental case, the child would obviously be further away from the minimum than the mother, and possibly both parents. If this happened a lot, crossoverintermediate (which puts the child between the parents) would home much faster. I'll try crossoverarithmetic, because its behaviour is between the two. I don't have enough waypoints for crossoversinglepoint to be effective, and with just three waypoints, crossovertwopoint is useless (it essentially kicks daddy out of bed and you wind up with a bunch of cloned girls. Eventually, it would get unlucky enough to have nothing but cloned girls and the run would stop early; bigger populations would put that off.)
Other suggestions:
1. The ability to zoom in on the monitoring graph!! Usually in the first generation, there is a rediculous mutant with a cost in the hundreds of thousands, or millions, whom I call "the guy guarding the goat path" after Ephialtes in the Battle of Thermopylae (the hunchback in
300). This guy sizes the graph, and so the rest of the points (almost all of which are under a thousand) wind up flattened near the bottom, making it impossible to observe any pattern except by either taking notes of the numbers or running CamStudio to automate the same process. Another option would be to plot these points on a logarithmic scale.
2. The ability to grab a point and draw it on the main output window. If I have to pause the optimization to do this, I don't care. It would also be neat if I could "freeze" a population and later be able to load it up from the freezer and run it, to see what different solutions are possible from a partially optimized population (this might also be handy if the population were immature enough to select, say, 1.5, 2 or 3 year orbits, but the obvious death traps of retrograde and 1 year orbits have been ruled out already. Also, the ability to drop the population size in this case might speed up the final homing phase of the optimization.
3. The ability to set the fitness function tolerance to zero. This means it'll run until either I stop it on purpose or it hits the iteration limit. For safety, I'd set an alarm to detect if the user puts on both a zero fitness tolerance and an infinite number of iterations. Setting zero function tolerance, infinite iterations, and unchecking Monitor would lock the program, and the only way to kill it would be the Task Manager or the power switch.
4. Animation function similar to what
www.astrojava.com has. This would be the fastest way to tell if the population has evolved into a retrograde solution (even for a guy like me who can figure it out pretty fast from four figure C3s.)
5. The ability to view the output from within the ecliptic plane. This would allow me to see what the inclination of the orbit is.
I remember there being a B-plane plot or something like that. I thought it was in this tool (an earlier version of it?) but now I can't find it anywhere. It showed how the spacecraft could approach a planetary flyby and how much delta-v it would require to stick to the flight plan depending on where it decided to go. An example would be a gravitational flyby of Venus to go from Earth to Jupiter (such as depicted in the manual artwork.) Say for a particular plan, the departure windows didn't quite line up, and you needed to do a maneuver at Venus to make it to Jupiter. The optimal point would be at the minimum radius over the night side (could be the day side, but not for this example) and this would be drawn as blue. The worst would be on the day side minimum radius, and colored red. The plot of intermediate values was an adorable quasi-magnetic flower with the planet in the middle having pastel neutral colors over the poles. Does that ring a bell for anyone?
6. Just in case you missed it, can I set constraints for flyby or arrival radii, pretty please??? I remember that Mariners 2 and 4 had such constraints for radiometry, photometry, and occultation experiments even though they were not to proceed to other destinations beyond. Mariner 10, Pioneer 11, Voyager 1, and Voyager 2 also had such constraints for their flybies when they were heading to destinations beyond. Cassini also could not get too close to Jupiter lest she be fried by the planetary particle radiation belts. Those are just a few cases other than my own.
Thanks for the work done so far, and I hope you keep at it!!
Terry
