Update TransX development

[Enjo]

I'm starting to do some improvements of TransX.

SourceForge project page:
http://sf.net/projects/enjomitchsorbit
Repository location:
http://sourceforge.net/p/enjomitchsorbit/codeHG/ci/default/tree/
To obtain the source code, you need TortoiseHG
Current dependencies of TransX (available in TransX's parent dir):
- EnjoLib ("lib" dir)

If you want to develop it together with me, please setup an account at SourceForge.net and send me a PM with your account name.

Implemented so far:
- An auto-min mode, hunting on the 3 planes for the minimum approach distance. For each press on auto-min (AMI), up/down on plane ch to get to a min, then repeat on outward, then repeat on prograde.

 

[sorindafabico]

O-F Staff note: Moved from TransX 2013.11.28 thread

Nice work Dgat! I love to see continuing work on these classic (and must-have) utilities.

Do you have a wish-list of things to add, given unlimited time to create things? Here's some of mine:

1. An auto-min mode, hunting on the 3 planes for the minimum approach distance. For each press on auto-min (AMI), up/down on plane ch to get to a min, then repeat on outward, then repeat on prograde.

2. A clean way to do resonant encounter slingshots (e.g. 1 1/2 orbits to reach Earth again).

3. Add moons into the two-body gravity calculation - e.g. to increase Earth-Moon trajectory accuracy.

4. An auto-center mode for maneuver thrusting (manual thrust, auto rotation).

I'd also suggest something like IMFD's Map program.

I would do it if already had the know-how, but I need to learn somt things before.

 

[Enjo]

I have really no idea when I will be able to continue working on TransX, so any takers are more than welcome.

I know how to do #4, because I have the same code in Launch MFD. I was thinking about drawing the vector on HUD, but this would add unnecessary dependency. I've also done a quick research on #1 and if I find some time this weekend, I could start writing it. Realistically though, I will first have to spend time on setting up the build environment, because currently I don't even have a working Windows box.

 

[aldarion]

#1
We need to remember that min value is not always the best way to find solution in TransX.
Overshooting is one of the main techniques I use in TransX.

 

[Enjo]

Sure. The idea is to remove the tediousness of manual tuning, but without removing the option of tuning.

 

[ADSWNJ]

Sure. The idea is to remove the tediousness of manual tuning, but without removing the option of tuning.

Exactly ... just optimize the process of manually finding the best solution, without making it auto-magical.

 

[Enjo]

Auto min

Attached is the first try of (unconstrained) minimization, available as an special adjustment variable type (before Reset). Because it's unconstrained, sometimes the Min function finds solutions that are far from sane, especially when it comes to Prograde vel. Please give it a go and tell me what you think.

 

[dgatsoulis]

I tested only a simple 3 stage Earth→Mars journey with today's date and I have to say that it's pretty freaking awesome! Great job Enjo! :thumbup:

As far as the outward and plane change go, I didn't notice any problems. Sure, there is some back and forth between the variables , but it was as fast (if not faster) as setting up a plan with the previous way.
Besides, I am pretty fast with TransX, so I can definitely see how this adjustment setting will help.

I did not notice any problems with the unconstrained prograde. If anything, it was undershooting until I started adding the other 2 variables with "Min". Perhaps it was because of the date (close to a Mars window).

One thing that will help a lot, is the addition of a line that shows the total dV of the Eject plan: sqrt(pro²+pl.ch²+out²).
This was on my to do list, as an easy and fast way to compare plans.
Now with the "Auto-min" setting (I think the name is fitting), showing the total dV becomes necessary.

Will do more testing tomorrow.


P.S. the size went from 317 to 1264 kb?

 

[Enjo]

Thanks for testig late in the night!

I did not notice any problems with the unconstrained prograde. If anything, it was undershooting until I started adding the other 2 variables with "Min". Perhaps it was because of the date (close to a Mars window).

In my Venus plan it was overshooting, by finding a second minimum with a non-hohmann transfer. But I think I know how to mitigate this: by setting 0 as the starting point for the optimum search, and not the current value. However I'll disable the Auto-min for the date variable, because this may screw up somebody's plan.

One thing that will help a lot, is the addition of a line that shows the total dV of the Eject plan: sqrt(pro²+pl.ch²+out²).

Great Idea.
I also have another one - we could have a gobal setting - minimize all - which would automatically minimize all three velocities upon any change of the date. Technically it's very easy to do.
Notice How we slowly converge to IMFD's functionality, but with TransX's plan flexibility.

P.S. the size went from 317 to 1264 kb?

That's because of the library that I use - "dlib". A very pro numerical lib with a permissive license (Boost). And it's easy to compile. However it's quite heavy with all the features that it has, while in this project I use just a tiny subset of them.

 

[Linguofreak]

Thanks for testig late in the night!



In my Venus plan it was overshooting, by finding a second minimum with a non-hohmann transfer. But I think I know how to mitigate this: by setting 0 as the starting point for the optimum search, and not the current value. However I'll disable the Auto-min for the date variable, because this may screw up somebody's plan.

Was this the November 2013 launch window?

Do note that due to inclination and eccentricity effects, the min-DV trajectory for the November 2013 Venus Hohmann window is not exactly a classical Hohmann. It goes through more than half an orbit before meeting Venus.

Great Idea.
I also have another one - we could have a gobal setting - minimize all - which would automatically minimize all three velocities upon any change of the date. Technically it's very easy to do.
Notice How we slowly converge to IMFD's functionality, but with TransX's plan flexibility.

This would make slingshots into resonant trajectories and such a whole ton easier to set up.

 

[Ripley]

I tried a simple Earth->Venus (on MJD 51906.916667 - December 2000).
With the "previous" TransX (enterbutton_graphicsfix) I got a Cl. App. of 604M, while with this new dll it went down all the way to something like 30M :thumbup:
then upon another click of Prograde (on "Min"), it jumped to a crazy + value, screwing everything up.

Anyway


Another thing: since now we have the new largest adjustment setting "Rough", I think variables should start on that setting instead of "Course".

 

[dgatsoulis]

Another thing: since now we have the new largest adjustment setting "Rough", I think variables should start on that setting instead of "Course".

I tried that when I was testing the new version, but I decided to leave it starting on "Coarse" for two reasons:

1. The "Rough" setting is mostly useful for 1 variable, the date. You use it very seldom for the other 3 variables.

2. TransX has been around for many years and most people (including me) have developed a certain "habit" for the way they setup their plans.
I wanted the new settings to add to that, without changing those habits.

Anyway, it's just a minor thing. I guess in the end, it's a matter of getting used to it.

---------- Post added at 12:34 ---------- Previous post was at 12:04 ----------

But I think I know how to mitigate this: by setting 0 as the starting point for the optimum search, and not the current value. However I'll disable the Auto-min for the date variable, because this may screw up somebody's plan.

Yeah, I tried an Earth→Mercury plan and in the beginning the prograde was all over the place. It wasn't difficult to adjust it first and then use auto-min, but some way of constraining the values is needed.

Totally agree on disabling it for the date.

I also have another one - we could have a gobal setting - minimize all - which would automatically minimize all three velocities upon any change of the date. Technically it's very easy to do.

So, in the Eject plan view, that would be an additional variable -not an adjustment setting- that says "Auto-min DV" with "Yes" and "No" as the adjustment settings to choose from.
If it is set to "Yes", TransX will auto-set the Pro, Pl.ch. and Out, to find a minimum dV solution for that particular date of departure.

How will that work, without the user also setting a date of arrival?
(Which would be exactly as IMFD works).

Notice How we slowly converge to IMFD's functionality, but with TransX's plan flexibility.

:thumbup:

 

[Enjo]

Was this the November 2013 launch window?

Nope. It wasn't. But as I can see, it's a common problem.

Yeah, I tried an Earth→Mercury plan and in the beginning the prograde was all over the place. It wasn't difficult to adjust it first and then use auto-min, but some way of constraining the values is needed.

It's easy to calculate a perfect Hohmann transfer orbit. I think that if the resulting prograde vel is greater than, say 20% of the Hohmann transfer orbit dv, then the optimization task should be considered a failure and cancelled.

So, in the Eject plan view, that would be an additional variable -not an adjustment setting- that says "Auto-min DV" with "Yes" and "No" as the adjustment settings to choose from.
If it is set to "Yes", TransX will auto-set the Pro, Pl.ch. and Out, to find a minimum dV solution for that particular date of departure.

That's how I imagine it.

How will that work, without the user also setting a date of arrival?
(Which would be exactly as IMFD works).

By simply automating the process of switching between variables and minimizing them. It will not be done iteratively (for int i = 0; i < 3; i++), but on the mathematical level - ie. making the calculation function not 1 variable dependent, but all 3 in the same time. The solver will automatically find the direction or fastest change (gradient), and proceed to look for the minimum there in one iteration.
Have a look at this method, where you see a minimization of 2 variables (we have 3): http://en.wikipedia.org/wiki/File:Nelder_Mead2.gif
By iterating over the variables by hand and performing 1-var only minimization, you effectively limit the picture in one dimension, having no chance to perceive higher dimensions (and I ain't talkin' New Age! :lol, therefore you can't find the high dimension gradient and have to repeat the task, also increasing the number of iterations.

and Re: prograde vel going haywire - the gif I posted also shows our situation nicely: imagine that the depressions are the possible minima of the 2D function, which in our case are lowest Cl. App. values - it's not obvious which one of these minima the algorithm will find. Of course, we know that it would be enough if the algorithm minimized the total DV in the same time, but I don't have that much control over it. Other than that, nobody said that the algorithm / library can't be changed. I'll try to design the optimizer in such way that it will be possible easily.

 

[Enjo]

Constraints

OK, I've added Hohmann-orbit-dv-based constraint to the prograde velocity, like I've described. It doesn't jump that dramatically anymore, however still due to TransX instabilities, sometimes the plan may change, if it is not firmly set (if it's like a perfect Hohmann transfer). It doesn't serve beer, but by simply switching between ProgradeVel and PlaneVel with Auto-Min, you can quickly find an optimal solution.

The idea with all variables optimising has unfortunately failed, because the design of TransX is obscure and nothing is what it seems to be. Therefore my assumptions where to hook my own code to reach my goal, have all failed. The MFD needs a redesign. Maybe later...

Please test the constrained automatic variable selection nevertheless. For now only for the ejection plan. The same in slingshots leads to CTD.

(PS. the file size is reduced. I probably sent a debug version by accident before)

 

[Ripley]

I tried that when I was testing the new version, but I decided to leave it starting on "Coarse" for two reasons:

1. The "Rough" setting is mostly useful for 1 variable, the date. You use it very seldom for the other 3 variables.

2. TransX has been around for many years and most people (including me) have developed a certain "habit" for the way they setup their plans.
I wanted the new settings to add to that, without changing those habits.

Anyway, it's just a minor thing. I guess in the end, it's a matter of getting used to it.

Ok, I understand your points. Perfectly fine.

...The MFD needs a redesign. Maybe later...

Ok, it's a deal!
:thumbup:

 

[ADSWNJ]

Your new TransX is looking very pretty. Just getting used to Left-Shift-. and Left-Shift-= to toggle between planes and incrementing on the Auto-Min. Super-efficient.

p.s. New Glideslope 2.3 almost ready. I have a graphical base/runway display mode now (plus all 4th Rock's stock base upgrade bases added).

 

[Ripley]

Well, I'm not a veteran TransX user, but I never saw this glitch until yesterday.

Orbiter just started, 2 TransX MFDs opened, started to find a plan to Venus (while on ground), and planets circumferences were not drawn at all. Everything was responding as usual (labels, variables, etc.) but with no graphics displayed.

I tried the "other" TransX (the standard graphicsfix_enterbutton version) and it was working perfectly.
I quit Orbiter, restarted it, and this time the new TransX was correctly displaying its orbits.

 

[Enjo]

And have you tried just restarting with the new .dll?

A small status update:
I think I slashed the dlib optimizers for good now. After debugging their doings, it became clear to me that most of the times these algorithms were clueless, jumping between starting point, lower and upper bound... Therefore I've designed my own algorithm, based on Bisection method (binary search), and have been using it with more success. Unfortunately that's just one part of the story. The other is, that TransX isn't a perfect "simulator". Variables that you are normally able to minimize visually, are not happy to be minimized automatically, by calling the TransX' "simulation", because the optimization algorithm doesn't get the correct feedback form TransX. The reason is that TransX seemingly expects its graphical Update method to be called, which helps the variables to converge. The task would be to separate the graphical part of the Update from the numerical one, and using the numerical only to update the simulation in my optimizer. My time is running out for this week, so I'll now slowly step back to the shadow, and silently perform my code cleanup tasks and some functionality testing, like the mentioned CTD in slingshot angle minimization.

 

[Ripley]

And have you tried just restarting with the new .dll?...

It's just what I did.
By "...and this time the new TransX was correctly displaying its orbits...", I meant your latest dll.

 

[ADSWNJ]

The task would be to separate the graphical part of the Update from the numerical one, and using the numerical only to update the simulation in my optimizer. My time is running out for this week, so I'll now slowly step back to the shadow, and silently perform my code cleanup tasks and some functionality testing, like the mentioned CTD in slingshot angle minimization.

I know exactly what you mean. I spent some time looking at that code to see how easy the solution would be. Apart from the lack of comments, there's not a clean separation between calculation and display update.

So ... you start with a simple goal, and end up rewriting 50%+ of the code!

Best wishes - we are all there in sprit!!