which basically means that it accepts as input the position vector for departure, the position vector for arrival and a time of flight between those 2 points and calculates the velocity vectors for a transfer orbit between the 2 points. It works very well when the transfer angle is not to close to 180° or Pi, which is a basic flaw in the method and from my current understanding kind of normal. Well the most efficent way however would be a transfer angle of close to 180°, but the resulting orbit my lambert solver gives me is nearly 90° inclined to the eccliptic (an orbit passing over the poles of the sun) which does not at all use the energy the departure planet already has, because it's initial velocity vector is perpendicular to the velocity vector of the departure planet, of course for an efficient transfer the two vectors should be as closely alligned to the each other as possible.The geometrical problem to find all ellipses that go through the points P1 and and P2 and have a focus at the point F1
telnet horizons.jpl.nasa.gov 6775
writing you about this is a matter of last resort, I can only imagine how busy people like you must be, even more I hope you can spare the time to answer me briefly.
I am using your code for a small hobby project, with the working title "Orbital Sling Shots and Newton for dummies", that I've been coding for the past 14 months now, goal is to plan multi staged interplanetary flights and explain to the user some of the more easy underlying maths/physics. I am using a freeware 3d engine to plot trajectories and I'm working on a sensible GUI to do calculations and set velocities. For that reason I am using a lambert solver I found on the net which has a comment on top; "please report bugs to email@example.com", now, from my current understanding it is not a bug, it concerns the computed solutions when feeding it with a high transfer angle close to 180° or 1 PI.
The problem is that the computed velocity vector for transfers with theta close to 180°, have nothing in common with an efficient initial transfer burn and delta-V's rise far to high. In the earth to mars case for example the resulting orbit is nearly 90° inclined to the eccliptic, it basically proposes a transfer which nearly crosses the suns south pole. I thought it might be my flipped coordinate system at first, but I noticed the same thing happens with another lambert solver I tried and it wont subside no matter how much I try to flip the axis back to normal, which is another story. I also noticed that if the transfer angle theta is not that high, more like 150°, the solution looks just fine and the the transfer orbit is inclined just enough to arrive at right plane of the destination orbit, in other words it works fine. So basically my Question would be, is this a known problem and if so, is there a way to overcome it ?
I also read this:
"/We note here that even when the transfer angle is exactly equal to pi
the algorithm does solve the problem in the plane (it finds X), but it
is not able to evaluate the plane in which the orbit lies. A solution
to this would be to provide the direction of the plane containing the
transfer orbit from outside. This has not been implemented in this
routine since such a direction would depend on which application the
transfer is going to be used in./"
So this actually sounds as if there is a solution to the problem, so if you know of some source of obtaining an implementation which allows me to externally specify a plane for the transfer orbit, that would "fix" my problem, I'd be more than greatfull if you could tell me where.
Sincerely and heap loads of respect, keep up the good work
what you are refferring to is a known issue. Actually rather than an problem is a feature of the physics underlying the problem. The point is that for transers that are close to 180 degrees due to the different planet orbit planes, if the spacecraft does not start in the mutual node then the only plane containing the two position of the planets and the Sun is the one that you evaluate from the Lambert solution and the DV is high (can result in a polar orbit!!). That is why these types of transfers are usually done at the mutual node line!!!!
Also, since you are working on this interesting code by your own you should consider applying to our Google Summer of Code project ( see http://sourceforge.net/apps/mediawiki/p ... =Main_Page) and in particular the project Interplanetary trajectory 3D graphics...... I feel that the experience you have accumulated in the past 14 month in your 'hobby'project would allow you to succesfully make the project. Check the Google Summer of Code web pages ...http://socghop.appspot.com/, Applications start next week.....
Dario Izzo, Ph.D, MSc
European Space Agency,
Advanced Concepts Team (http://www.esa.int/act)
ESTEC, DG-PI, Keplerlaan 1 - 2201 AZ Noordwijk - The Netherlands
Tel: +31(0)71 565 3511 - Fax: +31(0)71 565 8018
Building file: ../macOsX/f2c/src/sysdep.c
Invoking: GCC C Compiler
gcc -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"macOsX/f2c/src/sysdep.d" -MT"macOsX/f2c/src/sysdep.d" -o "macOsX/f2c/src/sysdep.o" "../macOsX/f2c/src/sysdep.c"
../macOsX/f2c/src/sysdep.c: In function ‘rmtdir’:
../macOsX/f2c/src/sysdep.c:112:3: warning: implicit declaration of function ‘rmdir’
../macOsX/f2c/src/sysdep.c: At top level:
../macOsX/f2c/src/sysdep.c:118:21: fatal error: sysdep.hd: No such file or directory
make: *** [macOsX/f2c/src/sysdep.o] Error 1
Users browsing this forum: No registered users and 1 guest