Update TransX development

[Enjo]

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

Let's recap your report. What you did was:
1) Running my dll and making a plan
2) Quitting the sim
3) Restarting the sim with the plan, seeing the display problems
4) Exchanging the dlls
5) Restarting the sim, fixing the problem
6) Reverting to my dll again
7) Still no problem

My question is: was the point 4) necessary? Did you try restarting the sim without exchanging the dlls?

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!!

I think I have an idea that would save me from a rewrite: I could write a dummy implementation of oapi::Sketchpad with empty method bodies, create an object of such implementation on stack inside the optimization function, and keep passing the dummy to the TransX's Update(skp) function like there's no tomorrow!

 

[Ripley]

Let's recap your report. What you did was:
1) Running my dll and making a plan
2) Quitting the sim
3) Restarting the sim with the plan, seeing the display problems
4) Exchanging the dlls
5) Restarting the sim, fixing the problem
6) Reverting to my dll again
7) Still no problem

My question is: was the point 4) necessary? Did you try restarting the sim without exchanging the dlls?...

No, you got it wrong.

I have both versions of TransX:
- the good old "graphicsfix_enterbutton" (which I renamed in TransX_Old.dll)
- the new ones by dgatsoulis (TransX.dll & TransX2.dll). Of these two dlls, the first one has now been overwritten by your latest one (still derived from dgatsoulis' work though).

The graphics glitch was with your latest dll.
After the glitch, and without exiting Orbiter, I tried the good ol'TransX doing the same sequence of clicks, and it was drawing well, as usual.
Then I quit, restarted Launchpad, and tried again the same plan with your new latest dll, and this time there were no drawing problems.


Since one of the new features introduced by dgatsoulis was rendering planets in new colors, maybe this glitch could relate to that part of code.

 

[dgatsoulis]

No, you got it wrong.

I have both versions of TransX:
- the good old "graphicsfix_enterbutton" (which I renamed in TransX_Old.dll)
- the new ones by dgatsoulis (TransX.dll & TransX2.dll). Of these two dlls, the first one has now been overwritten by your latest one (still derived from dgatsoulis' work though).

This may be the source of the problem.

You may have renamed the old dll to transx_old, but as far as Orbiter is concerned, the old one and mine are both the same TransX.

That's why the second instance of transX (the red one) has been compiled as a different mfd. Not just the name of the dll, but also the way TransX writes and saves the plans in the scenario.

Since one of the new features introduced by dgatsoulis was rendering planets in new colors, maybe this glitch could relate to that part of code.

I changed the color of the orbits (blue, which is also the color of the atmospheres), not the planets themselves (light gray). Even if there was something wrong with that change (though I don't see how :shrug you should still be able to see the circle of the planet in stage 1.

Anyway, just to make sure, please activate the 2013.11.28 version (my own from O-H) and test again, without having any other TransX modules in the plugin directory.

Just transx.dll, transx2.dll and activate both of them in the modules tab.
(When you press SEL in one MFD you should see "TransX" and "TransX(2)")

This way we can test if the problem is from my version, and not send Enjo in a wild bug-chase.

Edit:
If the glitch does happen again, please write down the exact procedure to replicate the problem.

 

[Ripley]

I changed the color of the orbits (blue, which is also the color of the atmospheres), not the planets themselves (light gray). Even if there was something wrong with that change (though I don't see how :shrug you should still be able to see the circle of the planet in stage 1.

Yes, I should have written "orbits" and not "planets", anyway I didn't see any graphics at all.

In my old days I too was a programmer (though very lousy), and I can understand that if you only changed the hue of these orbits, this glitch has very probably nothing to do with this implementation.

...Anyway, just to make sure, please activate the 2013.11.28 version (my own from O-H) and test again, without having any other TransX modules in the plugin directory.

Just transx.dll, transx2.dll and activate both of them in the modules tab.
(When you press SEL in one MFD you should see "TransX" and "TransX(2)")

This way we can test if the problem is from my version, and not send Enjo in a wild bug-chase.

Wilco.

...If the glitch does happen again, please write down the exact procedure to replicate the problem.

Sure

 

[Enjo]

I couldn't sleep at night so I decided to give it a shot.

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.

It turned out not to be that tragic after all. The "task" was already done, but I wasn't calling the numerical routine often enough to let it converge. It needs at least 7 iterations. I used just 1, now I use 10.
So here it is. Precise and fast. Please do some functional testing and tell me what is missing in your opinion. I used to know TransX very well, but I got old :tiphat:

 

[Enjo]

Please do some functional testing and tell me what is missing in your opinion.

Or to be more specific:
1) During my tests of slingshots (Earth->Venus->Mercury), it turned out that the minimum would most probably be found when the Pe/PlanetRad is < 1.0. Would it be enough to designate such minimum and let the user decide (or notice) that it's erratic?
2) What about manouvre mode. Is it working OK?

 

[dgatsoulis]

Got the new version, but I won't have time to test it 'til tonight. (Damn you stomach, for needing food! You are making me have to work!)

I have written down two small changes that will be useful.

1. Total dV of the Eject Plan:

-File: planfunction.cpp
section = void majejectplan::wordupdate...
(line 542)

Before:

void majejectplan::wordupdate(Sketchpad *sketchpad,int width, int height, basefunction *base)
{
	if (ratioorbit>0)
	{
		int linespacing=height/24;
		int pos=15*linespacing;
		TextShow(sketchpad,"Pe/Pl Rad:",0,pos,ratioorbit);
	}
}

With Total dV

void majejectplan::wordupdate(Sketchpad *sketchpad,int width, int height, basefunction *base)
{
	int linespacing=height/24;
	int wspace=width/19;
        int wpos=9*wspace;
	double totaldv=length(ejectvector);
	if (ratioorbit>0) //Don't show if View: Sling Direct 
	{
           totaldv=0;
	   TextShow(sketchpad,"Pe/Pl Rad:",0,15*linespacing,ratioorbit);
	}
        if (totaldv>0.1)
	{
           TextShow(sketchpad,"Total DeltaV:",wpos,22.5*linespacing,totaldv); //bottom right, watch both glass cockpit AND panel view for correct placement.
	}
}

It will place the total dV of the eject plan on the lower right corner.
It produces a warning "converion of double to int".
Haven't had time to try it in an another way, but even with the warning, it seems to be working.

IMO there is no need to implement it also on the maneuver view, because you can already see the total dV in the Target View and you can make adjustments to prograde, pl.ch. and outward velocities.

2. Circ Delta:
It had always bothered me that on the Encounter View, upon arrival on a planet/moon, I had to set up a maneuver to check the dV of an orbital insertion. TransX provides only the Pe alt, Vel and Capture Delta. The addition of a "Circ. Delta:" line would be very useful.

-File:
-planfunction.cpp
section = void encounterplan::wordupdate
line 453: (first let's get all the lines slightly up, the previous placement didn't show the LAN if you were targeting a base on the encounter body)

Before:

int pos=18*linespacing;

After:

int pos=16*linespacing;

line 496:
Before:

TextShow(sketchpad,"Capture Delta:",0,pos,actualpevelocity-escvelocity);
		pos+=linespacing;

After:

TextShow(sketchpad,"Capture Delta:",0,pos,actualpevelocity-escvelocity);
		pos+=linespacing;
		TextShow(sketchpad,"Circ. Delta:",0,pos,actualpevelocity-(escvelocity/1.4142135623731));
		pos+=linespacing;

I didn't understand why dividing with sqrt(2) didn't work, so I divided with the number instead.

Anyway, it's just how I'd do it (a complete noob). Of course, I wouldn't leave the "Total DV" compiled with the warning.

I am pretty sure that you'll find much more elegant ways to implement those two small and useful additions.

Will begin testing of the new version tonight. If by any chance you can recompile with those changes, it would be great. The total dV in the Eject Plan View, is really useful.

:tiphat:

 

[Enjo]

Great changes there. However I'm afraid that if we work separately, we will not be able to work efficiently and will introduce bugs trying to integrate mutual changes manually. Could I ask you to setup an account on SF.net and work on a common repository with me? At least for the time when I'm working on it. If you need some help with TortoiseHG, it's not a problem from my side. You'll see how much fun it is.

 

[dgatsoulis]

Sure, I'll give it a try. The reason I haven't so far, is because I have never used it before, so I don't really know even where to begin.
I 'll sign up on the link and if something is not clear, google for instructions
If I get stuck somewhere, I'll ask you.

 

[Enjo]

Great. Thanks!

The reason I haven't so far, is because I have never used it before, so I don't really know even where to begin.

I figured it out. Just don't get struck by the amount of options that you get. You normally only need the following:
1) Synchronize (check what's new on the remote server)
2) Pull (get the changes to local space)
3) Update (try to merge the changes with your local changes)
4) Code your changes
5) Commit (store a local snapshot [version])
6) Commit (store a second local snapshot)
...
7) Before pushing data on remote server repeat 1)-3), try to compile and test if it still works
8) If OK, Push the data to the server

Generally it's advised to (most important first):
1) Not Push (ideally also not Commit) code that doesn't compile, it's however OK if some features don't work, especially the new ones still in development
2) Make commits and pushes as small as possible (transactional) - one feature / improvement = one commit
3) Work on fewest possible files in the same time, not to provoke unnecessary file 'conflicts' with other devs. The files usually get merged automatically but sometimes not, and you have to do it manually with WinMerge (aided by TortoiseHG)

 

[jedidia]

There's really only one feature I would really, really love (and need) in TransX, and it's the one thing I can't do myself because of my shortcomings in math:

Burntime and fuel consumption integration into the trajectory (i.e. variable acceleration over time), so the plans are accurate for long burntimes. It would make realistic interplanetary vessels with thrusts in the centi- to mili-G range a lot easier to fly...

 

[dgatsoulis]

Started testing with 4 direct journeys from Earth to Mercury, Venus and Mars and Jupiter.

The Auto-Min setting seems to be working ok, No crazy values on the variables. Mercury took longer that the others, due to its highly elliptical and inclined orbit.
As anticipitated, it was faster when the date was near a launch window and even faster when the arrival on the target planet coincided with the line of nodes.

The fact that the setting is optional and you don't have to use it if you don't want to is great, since TransX veterans may want to use their own way of doing things. I think new users will find it useful though.

I also tested backwards compatibility with scenarios from previous versions of TransX and everything seems to be ok.

Or to be more specific:
1) During my tests of slingshots (Earth->Venus->Mercury), it turned out that the minimum would most probably be found when the Pe/PlanetRad is < 1.0. Would it be enough to designate such minimum and let the user decide (or notice) that it's erratic?

I think that's enough. The < 1 Pe/Pl ratio is normal for that slingshot. Arriving from Earth to Venus with a hohmann transfer gives you an encounter velocity of ~3.8 km/s
To go to Mercury from Venus you need something between 4.1 km/s (arrival at apoapsis) and 7.8 km/s (arrival at periapsis). So we are looking at a minimum dV deficit of 0.3 km/s. and a maximum of 4 km/s. (without taking into account the plane change).
That deficit means a Pe/Pl ratio < 1

In practise, you need at least 2 passes from Venus and one DSM.

2) What about manouvre mode. Is it working OK?

It doesn't appear to be working there. I setup an Earth-Moon maneuver with 2 scenarios. One with the spacecraft coplanar to the Moon and a second one for an off plane transfer. The hohmann dV says 0 and the Auto-Min setting doesn't work for the Prograde. Oddly enough, it jumps to an odd value when set to Outward or Pl.Change.

(IMO the auto-min setting is enough for the Eject plan and doesn't need to implemented on the maneuver too.)


Suggested addition (other than the total DV and Circ Delta):
Now that we have the hohmann transfer dv displayed on the Eject plan, it would be great if we could also show to the user some helpful info about finding the launch window date. Here is how I imagine it to work:

Knowing the semi major axes of the planets means that you also know the transfer orbit half period, which is equal to the transfer time. From that you can find what the angle between the planets must be, in order to be in a correct launch window.

Example (Earth-Venus)
Earth: Dist = 1AU, Sid. Period = 365.25 days
Venus: Dist = 0.72 AU, Sid. Period = 224.7 days

SMa is of transfer orbit = (0.72 + 1)/ 2 = 0.86 AU.
Transfer period = 0.86^1.5 = 0.7975 years
Transfer time = 0.7975/2 = 0.39875 = 145.6 days
Venus will cover 145.6/224.7 = 64.8% of its orbit = 233.3°
180-233.3° = -53.3° (negative angle means the target needs to be behind)
So Earth needs to be ahead of Venus 53.3° degrees at the time of transfer.

Example (Earth-Mars):

Earth: Dist = 1AU, Sid. Period = 365.25 days
Mars: Dist = 1.52 AU, Sid. Period = 686.97 days

SMa of transfer orbit = (1+1.52)/2 = 1.26 AU
Transfer period = 1.26^1.5 = 1.414 years.
Transfer time = 1.414/2 = 0.707 years = 258.2 days
Mars will cover 258.2/686.97 = 37.6% of its orbit = 135.3°
Angle: 180°-135.3° = 44.7° (positive means the target needs to be ahead)
So Mars needs to be 180°-135.3° = 44.7° ahead from Earth at the time of the transfer.

If we want to take this a step further, we can connect the Date variable to the angle and show the angle for the date selected from the user on the Eject plan.

It doesn't seem like a difficult feature to add. The angle between the planets can be easily found with a 2D simplification (not that it's difficult to use all 3 spatial coordinates, just unnecessary). I am not so sure as to how to connect the date and re-calculate the angle, but I don't think it's too difficult.

As a "safety" feature, (custom solar systems , high R.Inc between departure and arrival planets, etc), the feature could be turned off after a predefined maximum R.Inc value.

 

[Enjo]

I like the ideas of course. However I'm a fan of visual verification, and of not showing the user too many variables. Angle difference would be OK then I think. Also, the Hohmann velocity is just a help for me while developing. The user can verify himself visually whether the planned trajectory exceeds the target orbit too much, without having to know the current Hohmann vel, and his planned Prograde vel.

I'd also like to add to it a dashed grey line of the line of nodes (where Ch.Plane = 0), so that you can visually verify how much off your Ch.Plane velocity is, without seeing its exact value.

On top of that, once I finish my multidimensional optimisation algorithm, I expect both velocities (Prograde & Plane) to be optimised simultaneously while modifying the Ej.Date (I'll leave the Outward, because modifying it costs too much energy). Then, you'd automatically see if the proposed solution makes sense by visually verifying how much off both the velocities are, without needing to have the Hohmann DV and the Total DV displayed. Do you think it's a better idea or would you rather sticking to displaying the variables, or both?

 

[dgatsoulis]

I like the ideas of course. However I'm a fan of visual verification, and of not showing the user too many variables.

Completely agree. It is easy to get carried away (as I obviously have) with too many variables and indicators on the screen. After all you do have a visual representation on screen already and the ability to quickly sweep through other dates with the "Rough" adjustment setting.

I'd also like to add to it a dashed grey line of the line of nodes (where Ch.Plane = 0), so that you can visually see how much off your Ch.Plane velocity is, without seeing its exact value.

Great idea. Other than the eject plan, it is useful for slingshots too.
It is good to know where the orbits of target1 and target2 intersect. With the previous versions, I had to switch the plan from Slingshot to Eject and add a bit of prograde, just to see the line of nodes. Then I had to switch back to a slingshot plan.
Having the line of nodes between the MIN and TGT bodies displayed as a fixed dashed line would be a very nice visual addition.

On top of that, once I finish my multidimensional optimisation algorithm, I expect both velocities (Prograde & Plane) to be optimised simultaneously while modifying the Ej.Date (I'll leave the Outward, because modifying it costs too much energy). Then, you'd automatically see if the proposed solution makes sense by visually verifying how much off the both velocities are, without having the Hohmann DV and Total DV displayed. Do you think it's a better idea or would you rather sticking to displaying the variables, or both?

I don't mind not having the hohmann dV, after all it is just a suggested value, but I do think the total DV is something that was missing from TransX.

 

[Enjo]

I don't mind not having the hohmann dV, after all it is just a suggested value, but I do think the total DV is something that was missing from TransX.

Then I have the following idea:
The total DV's color would dynamically range from green, through yellow, to red, depending on where the DV is in the range of <HohmannDV, 2*HohmannDV>. Sounds good?

 

[dgatsoulis]

Wouldn't that be a lot more work than simply adding a couple of lines of code
that say "totaldv=length(ejectvector)"?

What about rendezvous with targets that are on highly elliptical and/or inclined orbits (like Mercury or Halley's comet)?
For such targets, it doesn't make much sense to use the hohmann dv as a comparison.

 

[ADSWNJ]

Then I have the following idea:
The total DV's color would dynamically range from green, through yellow, to red, depending on where the DV is in the range of <HohmannDV, 2*HohmannDV>. Sounds good?

Do this for the date as well then? Green when within 1 degree of optimal launch, Yellow within 5 degrees, etc.

Personally, I like more data on the screen, so I would have the HohmannDV and the Delta Angle (Current-Optimal).

 

[Enjo]

Wouldn't that be a lot more work than simply adding a couple of lines of code
that say "totaldv=length(ejectvector)"?

For me it's not a problem to code such things.

What about rendezvous with targets that are on highly elliptical and/or inclined orbits (like Mercury or Halley's comet)?
For such targets, it doesn't make much sense to use the hohmann dv as a comparison.

Then I can ask the same question about my optimisers: they need their bounds. What if the target needs to be approached with more than, say 50% of Hohmann dV (upper bound of optimisers)? Then you could say that this is a special case and you can live without the optimisers. But I could say exactly the same about coloring the total dV in red for Halley's comet: it's a special case, so you know that you can ignore the red color. Or we could ask another, more general question: Can we find the upper bound more objectively?
BTW., is Mercury really so inclined? How much PlaneVel do you need in relation to RetrogradeVel?

Anyway, this is just a proposal. A cherry atop a portion of cream, and I will code any of these features only after I finish my optimisers and am satisfied with the result user-wise, and design-wise (code cleanness), and that only if my wife doesn't kill me before that happens! :lol:

 

[dgatsoulis]

Or we could ask another, more general question: Can we find the upper bound more objectively?

A hohmann transfer is for coplanar circular orbits of different altitudes. When those orbits stray too far from the coplanar (R.Inc < 2°) or circular (ecc < 0.1) definitions, the hohmann transfer orbit doesn't really apply. Sure you can try to find a minimum dV solution, it's just not a hohmann one.

BTW., is Mercury really so inclined? How much PlaneVel do you need in relation to RetrogradeVel?

7° relative to the ecliptic and an eccentricity of 0.2056. (Most inclined and eccentric of all the planets).

I don't have the exact values right now, but just calculating a 7° plane change when moving at 30 km/s is 2*30*sin(7/2) = 3.66 km/s
The retro dv is roughly 6.2 km/s for an arrival at apoapsis (high Enc Vel.) and ~9.1 km/s for an arrival at periapsis (low Enc vel.)

Anyway, this is just a proposal. A cherry atop a portion of cream, and I will code any of these features only after I finish my optimisers and am satisfied with the result user-wise, and design-wise (code cleanness),

Of course, this is your show man.
The suggestions I have made on this thread are just that, suggestions. It is completely up to you whether you decide to implement any of them to your code. The task you have undertaken is already a major one, and will improve TransX a lot.

That and the auto-orient feature if possible.

...and that only if my wife doesn't kill me before that happens! :lol:

Will begin a "Please don't kill Enjo" spam campaign to EnjosWife immediatelly! (On second thought, that might get you killed even sooner! :lol

 

[Enjo]

I got the slingshot angles optimisation to work. That was hard... Next stop - multidimensional optimisation.