I have worked like a madman again, slowly getting somewhere...
http://orbiter-forum.com/showthread.php ... post152537
Working Title: 'Orbital Sling Shots and Newton for dummies'
Ok, time to resurrect the thread again and post some updates and source. I worked out a considerable amount of flaws and unfortunately also added a few new ones.
The source is still full of stupid ways to do things and littered with debug prinf's and old code, most variables are defined globally and using pointers slowly works better but still gives me headaches from time to time, well basically I just started c++ a little bit more than a year ago and never really read much about it, that is clearly reflected in my code.
But enough pessimism, it can only get better if you know about the flaws, it's a lot more going on now.
Not really sure where to start, well maybe with the new kepler solver which I got from Fundamentals of astrodynamics and applications by David Vallado which again comes with the Companion code for Fundamentals of Astrodyanmics and Applications which is available in fortran, c++, pascal and matlab. So far I only use the kepler function, but the whole source is full of useful stuff from orbital plane changes to what not else, I'm certain it will provide me with heap loads of more usefull stuff, once its needed and understood. The Kepler function takes as input the satellites relative position vector from the central body and its velocity vector (orbital state vectors), the Gravitational constant times the mass of the body, a time in seconds to propagate the orbit and calculates the resulting new state vectors... Which comes in very handy since now I can step the timescale right up/down to any value without loosing to much precision. Stepping the timescale can be done by pressing .(dot) and ,(comma) on the keyboard. The algo I used and wrote myself before, did work, it did subscribe to kepler and newtons laws, but it really lacked realism and basically worked by adding all g-pull vectors of all planets to the velocity vector of the satellite, which is just wrong unfortunately. Now I have a defined Sphere of Influence around every body and if I'm not within this or that sphere of influence I'm in the SOI of the sun, which is an approximation known as "patched conic approximation" and there's really nothing wrong with it.
Another thing I really got figured is an understanding of what the keplerian elements actually geometrically mean, after nearly a year
but well, I can now generate ellipses and rotate them until they match the orbital plane (incliation and longitude of ascending node) and then locally rotate on that plane around Y until the argument of periapsis matches. Since these values change over time, I can now update them. As a result all orbit ellipses now always match the actual path of the planets around the sun.
Also new is a relatively low precision but working lunar positioning algo, which I found on the net, it's written by Keith Burnett and based on the lesser known Meeus Ch45 series, which themselve are truncations of the more popular ELP-2000 series. They take into account orbital pertubations of our moon due to the other planets influence on it, something I really didnt know, but that is complex stuff and not an easy task to predict the position of our moon. Well it's included now, for our (earth) moon only and it allows you to pretty exactly find the current lunar phase, and I checked with a calendar, it works pretty well.
Also, finally I managed to reset the coordinate system in a good way, earlier I always reset in a way that would put the closest planet in the origin of the coordinate system, now, wherever I am the camera is in the origin, all positions are stored as doubles and bye bye to the precision problems I used to fight with. I can now smoothly orbit Pluto.
Another new thing is the render order. Now I first render the background with a huge far clipping plane, then reset the zBuffer and render the closest planet with an optimized far clipping plane, which allows me to go right down to less than 100 km close to the surface, maybe even lower without Z-buffer problems, also, no more flickering (Ok, a little) when I'm to far.
Also new is a projection mode which you can enter by pressing 'P' on the keyboard. This is still unfinished buggy and ugly, I'm really not a big fan of the GUI in irrlicht. Also it's still heavily under development because I'm only using it to mess with my lambert solver for interplanetary transfers, trying to efficiently fly to mars for the last few months now. The lambert problem can be described as
In a classical Hohmann transfer, the transfer angle is exactly 180°, and the transfer orbit (ellipse) is exactly tangential to departure and arrival orbit, which means that the transfer ellipse can be rotated around the semi-major axis and still hits the the desired arrival and departure points. You can try that in any 3d app, by making 2 concentric circles, make a third one and scale it until it is an ellipse that touches both the inner and outer circle, you can now rotate this ellipse around its longer side and verify it will always touch at both departure and arrival position. However the Hohmann transfer is not really easy to get right in the case the orbits are not perfectly circular and coplanar, which is why I chose to use the lambert solver, and to repeat myself, that fails in the case of a transfer angle close to 180° and it cant be rotated since the transfer ellipse is not perfectly tangential to the arrival planets orbit, so I'm still struggeling with the interplanetary transfers, let alone I still have to think about departure parking orbits and arrival injections.
Alltogether anyway, lightyears ahead from my previous versions and slowly slowly trying to clean up the code. I already started a new class called satellite which I plan to instantiate a couple of thousand times for all comets and asteroids around the sun and all artificial satellites around earth, which will provide me with some very decent screenshots. Obtaining that data, is easy actually and quite fun. Open a command window and type:and at the prompt type:
A < 30.; IN < 90.; EC < 1.; OM < 360.; W < 360.; MA < 360.;
which will list you all small bodies and their orbital elemets within a range of 30 AU's that have an elliptical orbit.
The source is still full of stupid ways to do things and littered with debug prinf's and old code, most variables are defined globally and using pointers slowly works better but still gives me headaches from time to time, well basically I just started c++ a little bit more than a year ago and never really read much about it, that is clearly reflected in my code.
But enough pessimism, it can only get better if you know about the flaws, it's a lot more going on now.
Not really sure where to start, well maybe with the new kepler solver which I got from Fundamentals of astrodynamics and applications by David Vallado which again comes with the Companion code for Fundamentals of Astrodyanmics and Applications which is available in fortran, c++, pascal and matlab. So far I only use the kepler function, but the whole source is full of useful stuff from orbital plane changes to what not else, I'm certain it will provide me with heap loads of more usefull stuff, once its needed and understood. The Kepler function takes as input the satellites relative position vector from the central body and its velocity vector (orbital state vectors), the Gravitational constant times the mass of the body, a time in seconds to propagate the orbit and calculates the resulting new state vectors... Which comes in very handy since now I can step the timescale right up/down to any value without loosing to much precision. Stepping the timescale can be done by pressing .(dot) and ,(comma) on the keyboard. The algo I used and wrote myself before, did work, it did subscribe to kepler and newtons laws, but it really lacked realism and basically worked by adding all g-pull vectors of all planets to the velocity vector of the satellite, which is just wrong unfortunately. Now I have a defined Sphere of Influence around every body and if I'm not within this or that sphere of influence I'm in the SOI of the sun, which is an approximation known as "patched conic approximation" and there's really nothing wrong with it.
Another thing I really got figured is an understanding of what the keplerian elements actually geometrically mean, after nearly a year
but well, I can now generate ellipses and rotate them until they match the orbital plane (incliation and longitude of ascending node) and then locally rotate on that plane around Y until the argument of periapsis matches. Since these values change over time, I can now update them. As a result all orbit ellipses now always match the actual path of the planets around the sun.Also new is a relatively low precision but working lunar positioning algo, which I found on the net, it's written by Keith Burnett and based on the lesser known Meeus Ch45 series, which themselve are truncations of the more popular ELP-2000 series. They take into account orbital pertubations of our moon due to the other planets influence on it, something I really didnt know, but that is complex stuff and not an easy task to predict the position of our moon. Well it's included now, for our (earth) moon only and it allows you to pretty exactly find the current lunar phase, and I checked with a calendar, it works pretty well.
Also, finally I managed to reset the coordinate system in a good way, earlier I always reset in a way that would put the closest planet in the origin of the coordinate system, now, wherever I am the camera is in the origin, all positions are stored as doubles and bye bye to the precision problems I used to fight with. I can now smoothly orbit Pluto.
Another new thing is the render order. Now I first render the background with a huge far clipping plane, then reset the zBuffer and render the closest planet with an optimized far clipping plane, which allows me to go right down to less than 100 km close to the surface, maybe even lower without Z-buffer problems, also, no more flickering (Ok, a little) when I'm to far.
Also new is a projection mode which you can enter by pressing 'P' on the keyboard. This is still unfinished buggy and ugly, I'm really not a big fan of the GUI in irrlicht. Also it's still heavily under development because I'm only using it to mess with my lambert solver for interplanetary transfers, trying to efficiently fly to mars for the last few months now. The lambert problem can be described as
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
In a classical Hohmann transfer, the transfer angle is exactly 180°, and the transfer orbit (ellipse) is exactly tangential to departure and arrival orbit, which means that the transfer ellipse can be rotated around the semi-major axis and still hits the the desired arrival and departure points. You can try that in any 3d app, by making 2 concentric circles, make a third one and scale it until it is an ellipse that touches both the inner and outer circle, you can now rotate this ellipse around its longer side and verify it will always touch at both departure and arrival position. However the Hohmann transfer is not really easy to get right in the case the orbits are not perfectly circular and coplanar, which is why I chose to use the lambert solver, and to repeat myself, that fails in the case of a transfer angle close to 180° and it cant be rotated since the transfer ellipse is not perfectly tangential to the arrival planets orbit, so I'm still struggeling with the interplanetary transfers, let alone I still have to think about departure parking orbits and arrival injections.
Alltogether anyway, lightyears ahead from my previous versions and slowly slowly trying to clean up the code. I already started a new class called satellite which I plan to instantiate a couple of thousand times for all comets and asteroids around the sun and all artificial satellites around earth, which will provide me with some very decent screenshots. Obtaining that data, is easy actually and quite fun. Open a command window and type:
Code: Select all
telnet horizons.jpl.nasa.gov 6775A < 30.; IN < 90.; EC < 1.; OM < 360.; W < 360.; MA < 360.;
which will list you all small bodies and their orbital elemets within a range of 30 AU's that have an elliptical orbit.
I wrote to Dario Izzo from the European Space Agency:
and he replied:Hi Dario,
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 dario.izzo@esa.int", 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
Tobias Houfek
seriously considering...Tobias,
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.....
D.
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
Hi,
latest source and binaries (Mac OS Version is untouched for ages unfortunately)
http://tobi.houfek.de/irrSolarSystem.zip
KEYS:
F1 Satellite view
F2 External View
Shift-Cursor Down Zoom Out
Shift-Cursor Up Zoom In
Cursor Up/Down Pitch
Cursor Left/Right Yaw
1 - 9 Jump to planet MVEMJSUNP
F3 Star Cam /RA-DEC configure in main.cpp
M MoonView
F Show Field Lines (earth)
0(zero) update Field Lines
.(dot) Increase Timescale/Factor
,(comma) Decrease Timescale/Factor
T Toggle Trail absolute/relative
P Projection Mode (handle with care)
I Show sphere of influence
W-A-S-D Thrust Up/Left/Down/Right from View Direction
Q-E Bank Satellite
left MouseButton accelerate in View Direction
right MouseButton deccelerate in View Direction
Shift-left MB accelerate tangential to Orbit
Shift-right MB deccelerate tangential to Orbit
Mouse Cursor Rotate camera (camera is weird)
enjoy !
latest source and binaries (Mac OS Version is untouched for ages unfortunately)
http://tobi.houfek.de/irrSolarSystem.zip
KEYS:
F1 Satellite view
F2 External View
Shift-Cursor Down Zoom Out
Shift-Cursor Up Zoom In
Cursor Up/Down Pitch
Cursor Left/Right Yaw
1 - 9 Jump to planet MVEMJSUNP
F3 Star Cam /RA-DEC configure in main.cpp
M MoonView
F Show Field Lines (earth)
0(zero) update Field Lines
.(dot) Increase Timescale/Factor
,(comma) Decrease Timescale/Factor
T Toggle Trail absolute/relative
P Projection Mode (handle with care)
I Show sphere of influence
W-A-S-D Thrust Up/Left/Down/Right from View Direction
Q-E Bank Satellite
left MouseButton accelerate in View Direction
right MouseButton deccelerate in View Direction
Shift-left MB accelerate tangential to Orbit
Shift-right MB deccelerate tangential to Orbit
Mouse Cursor Rotate camera (camera is weird)
enjoy !
I've been quite busy updating my project, so I put together a video with admittedly little bit cheesy music.
Hope you like it.
http://www.youtube.com/watch?v=rw5Fsi4LO4Y
Hope you like it.
http://www.youtube.com/watch?v=rw5Fsi4LO4Y
-
Radikalizm
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
Re: Working Title: 'Orbital Sling Shots and Newton for dummi
Is there a makefile for this project? I am having trouble compiling the demo, and your release in the bin folder is linked to irrlicht somewhere in your home directory (linux).
Re: Working Title: 'Orbital Sling Shots and Newton for dummi
This project seems pretty cool and I'd like to check it out. I did eventually find a makefile in irrSolarSystem/Debug, and after running make clean it is producing a lot of warnings all related to macOsX
Here is the error it stops at:
I am trying to compile this in linux. Could somebody with more knowledge help me compile this rather large project? It seems like a very cool idea, and I would like to see if I can I can write code to land on the planets and replicate the shaders at sponeil.net for the atmosphere from space and land.
Here is the error it stops at:
Code: Select all
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
compilation terminated.
make: *** [macOsX/f2c/src/sysdep.o] Error 1Re: Working Title: 'Orbital Sling Shots and Newton for dummies'
New Binary Version... Read the README... anyone interested to contribute, please do !
https://drive.google.com/file/d/1IPuD4W ... sp=sharing
https://drive.google.com/file/d/1IPuD4W ... sp=sharing
back in the days...