ON APRIL 28, 2013 01:27 AM Communication, sat's trajectory simulation.
Communication, packages of commands, re-design from standard modem communication
implementation, flush memory buffer to speed up data transfer, triple flush
memory with majority voting (protection from radiation damage). Visualization of
calculated trajectory in simulator to generate commands for (a) ground station
and (b) craft/cubesat. GPS satellites traject's simulation for proper
calculation of a craft/ground station positions.
ON APRIL 24, 2013 01:56 PM Simulation for ground station.
Last travisual.xml file includes trajectory of the moon in last 60 minutes (it shows polyline how moon rotates around earth) and also coordinates (trajectories) of (up to 10) satellites - on a server (http://50.64.123.13/SatCtrl/travisual.xml) tra.exe running now in loop and output updated travisual.xml - (click couple times on the http://50.67.199.141/SatCtrl/travisual.xml it is constantly updated - in processing of the file needs to handle a non-finished-write-to-the-file cases).
last changes was
s
- to manipulate (re-size/rotates/move) the earth-moon system
- to pickup latest travisual.xml with last positions.
Today i need to update real time position of the satellites (now it require to reload applets) and somehow to show azimuth + longitude for satellite when it will fly over ground station.
I also need (It is my main goal - after visualization to continue with ground station software) to have a "view" button on a surface of the sphere (earth) at ground station location, for that I need to show night sky with stars, or at least some longitude latitude mesh. I have no idea how to do this.
V., can you check how applet will work for you (http://www.adobri.com/SatCtrlR.aspx) - texture of a earth and the moon downloaded separately - I need to know the delay - when I tests behind a router it (the router) slows down download of the files and I do not get proper value of a download time - and from my another desktop java does not work - no clue how to make java working back on that computer.
I talked yesterday with Boris - he told that in his last project (some automation) he tried all SVG/GL, Java applets and Silverlight
Best was Silverlight - Microsoft was fastest to run, fast to get real time data and faster in development (C#).
- SVG/GL was slow by any compare, except rapid prototyping.
- java was ok, but tools to developed was really archaic, problem was with real-time.
And I tied yesterday Silverlight - to switch now it will push be back for at least one week to learn how to do lights and etc.
ON APRIL 20, 2013 11:46 PM Overview of mission control
Last week's changes
on -
http://www.adobri.com/SatCtrlR.aspx
ON MARCH 12, 2013 11:37 AM Software.
Finally software to be taking care – to get landing page of Craft/Cubesat Mission Control click on link “Craft's /CubeSat's Mission Control. Follow link below” from the page
http://www.adobri.com/ProjectGsC.aspx
Source code for mission control
https://github.com/alexdobrianski/SATCTRL
RL
Source code for main processor managing GPS, Camera, HD Camera, backup communication is
https://github.com/alexdobrianski/STM_HDC
Source code for 2.4Ghz communication on
https://github.com/alexdobrianski/STM_BT
That code (I hope) will changed a lot in next 2-3 weeks.
All sources code and 3D designs are on
https://github.com/alexdobrianski
Nov 21, 2011 RFM.
When you meet your physics teacher 30 years after the school, and old man told
that he dos not remember how did you study physics in his class, it mean only
one – needs to be careful with anything related to a physics. Specifically needs
to RFM old lectures – gravitational potential is a scalar value, to get force
from gravitational potential needs to get partial derivative. Particularly:
U (gravitational potential) = sum of Unk = fm/r (r0/r)**n Pnk(sinTetta)
[Cnk*cos(k*lambda) + Snk*sin(k*lambda). Where Tetta is a latitude and lambda is
longitude. Cnk/Snk is a constants from a model. fm= G*M, and r0 is equatorial
radius. Partial derivative is (page 90 from Akesenov’s lectures
http://vadimchazov.narod.ru/lepa_zov/lesat.pdf):
Then: Unk separates into 3 parts:
(part 1) Rn(1/r) = fm/r *(r0/r)**n
derivative =>
Rn(1/r)' = (n+1) * fm * r0**n * (1/r)**n = (n+1) * fm * (r0/r)**n)
on a page 12 is (it is kind of hard to write formulas in C code)
Pnk(sinTetta) = (1-sinTetta**2) ** (k/2) * dk (Pn(sinTetta))/ d(sinTetta)**k
=
cosTetta **k * dK(Pn(sinTetta))/ d(sinTtta)**k
now cosTetta**k separated from Pnk(sinTetta) to get clear part 2 and CosTetta**k will
end up at part 3.
(part 2) Znk(z/r) = dK(Pn(sinTetta)/ d(sinTetta)**k =
= Pnk’[n][k]
Derivative => Znk(z/r)' = Pnk’[n][k+1]
also in (part 2) for K == 0 is:
Zn0 = Pn(sinTetta)
Finally cosTetta goes to a last part:
(part 3) Qnk(x/r,y/r) = cosTetta**k * [Cnk*cos(k*lambda) + Snk * sin(k*lambda)]
= [Cnk*cosTetta**k * cos(k*lambda) +
Snk * cosTetta**k * sin(k*lambda)]
= [Cnk* Xk + Snk*Yk] and
Xk = (cosTetta)**k * cos(k*Lambda) Yk = (costetta)**k * sin(k*Lambda)
or recurcevly:
X0 =1, Y0 = 0
X1 = cosTeatta * Cos(Lambda) = x/r; Y1 = cosTetta * sin(Lambda) = y/r
X[k+1] = Xk * x/r - Yk* y/r Y[k+1] = Yk* x/r + Xk * y/r
D(Unk)/D(x) = d(Rn) / d(1/r) * D(1/r)/D(x)
* Znk * Qnk + Rn * d(Znk)/d(z/r) * D(z/r)/D(x) * Qnk + Rn *
Znk * [D(Qnk)/D(x/r) * D(x/r)/D(x) + D(Qnk)/D(y/r)*D(y/r)/D(x)]
D(Unk)/D(y) = d(Rn) / d(1/r) * D(1/r)/D(y)
* Znk * Qnk + Rn * d(Znk)/d(z/r) * D(z/r)/D(y) * Qnk + Rn *
Znk * [D(Qnk)/D(x/r) * D(x/r)/D(y) + D(Qnk)/D(y/r)*D(y/r)/D(y)]
D(Unk)/D(z) = d(Rn) / d(1/r) * D(1/r)/D(z)
* Znk * Qnk + Rn * d(Znk)/d(z/r) * D(z/r)/D(z) * Qnk + Rn *
Znk * [D(Qnk)/D(x/r) * D(x/r)/D(z) + D(Qnk)/D(y/r)*D(y/r)/D(z)]
All Rnk, Qnk and it’s derivatives calculates recursively, on page 91-92
presents formulas to get partial derivatives for D(1/r)/D(x) and etc. At the end
needs to move out of brackets for each partial derivative values fm * x/r**3, fm
* y/r**3, fm*z/r**3. And explanation of a stupidity of Alex Dobrianski shines up
– in a C code J2 constant really bigger 10 times for 75 degree(just coincident
normally it bigger 3 times), in Fx,Fy presents sin(co-latitude), in Fz presents
cos(latitude)**2 / sin(latitude), and error drops from 30km to 685m. Needs to
read (couple of times) manual (lectures) does not matter how many pages in it.
Nov 15, 2011
For trajectory simulation on low earth orbit was implemented 3 different groups
of functions in source code. At first (for Earth’s simulation as a dot mass)
kepler’s elements of a satellite (eccentricity, inclination, longitude of
ascending node, argument of perihelion, and mean anomaly) converted to position
and velocity, then plugged to a simulation. To confirm that conversion and
simulation is “OK” was ported (as a second group) source code from
http://www.projectpluto.com/source.htm (functions for keplers reverse conversion
from position and velocity to a keplers elements). After some sign adjustments
was confirmed that dot mass simulation is correct == after one orbit (or 1 day
flight) satellite’s Keplers elements has had an error lower then 1.E-10. Then
comes third group – old fortran source code from “SPACETRACK REPORT NO 3”
(http://www.amsat.org/amsat/ftp/docs/spacetrk.pdf ) function for SGP4 gives
(looks like) gives better precision than SGP. Then model was switched from dot
mass to a something better suitable like GEM-T3 or JGM3. Basically this model
deals with “flatness” of the earth (or differently saying orange like model of
earth, or “pear” shape-like earth model). All those models suppose to allow to
calculate value a gravitation potential assuming that earth is not a perfect
sphere. Recursive function Pn(cosTtetta) does not take much time to implement.
Was confirmed that coefficient J2=1082.6360229830E-6 has biggest impact. Because
in first lines of a report was stated: “The NORAD element sets are “mean" values
obtained by removing periodic variations in a particular way. In order to obtain
good predictions, these periodic variations must be reconstructed (by the
prediction model) in exactly the same way they were removed by NORAD.” This
statement was confirmed by analyzing source code – mean motion and semimajor
axis (eccentricity) was readjusted before use. Also by reverse conversion was
confirmed that period/mean-motion of the orbit is different from “mean” mean
motion (terminology of a report), and different from “mean motion”, and
difference btw all 3 values is 4 seconds each. To avoid such errors was decided
to use position and velocity from SPG4 model and compare that data with
corresponded values from a model with J2-J8 and Sxx + Cxx coefficients to
simulate gravity. Result was discouraging. Error was in 50km after one orbit.
Was made an attempt to minimize difference. It was found that best match (17km
in position and 8m in velocity) was when instead of cos(co-latitude) was used
cos(latitude) – which is a nonsense - it shows that earth has more flatness on
equator instead on a poles. Then it was manual attempt to match SPG4 data by
adjusting J2 coefficient (commented out code in function IteraSat in
http://www.adobri.com/misc/tra/tra.cpp) – was found that J2 was to be increased
in some moments 10 times. Was done attempted to adjust initial velocity and
position from SGP4 model to match result after one orbit simulation – this also
did not bring suitable match. To be continue. For sure bug in a model, but
without finding it will be totally impossible to do navigation to flight to the
moon.
May 2, 2011. Finally
was fixed bug in step “trajectory optimization type”== 6, Optimization of a
weight of a propellant. All steps are:
Apr 31, 2011. Main
engine results kainda wrong.
Apr 30, 2011. Steps for
a second engine done.
Apr 29, 2011. First
steps for first engine done.
Apr 28, 2011.
Implemented “calculate” types:
(0) Perigee to a center of Near Body
(1) Apogee to a center of Near Body
(3) target practice not far than distance earth-moon
(5) target practice to a point on a moon's surface
(6) orbit period around near body
(8) orbit period before engine firing
(9) first engine firing time
(10) second engine firing time
(11) third engine firing time (first try)
(12) abs (apogee - 3/4 of a earth-moon distance)
Implemented Trajectory Optimization Types:
1 - search for a minimum by adjusting time of firing
2 - search for a maximum by adjusting time of firing
4 - search for maximum by adjusting angle of firing
6 - search for minimum by adjusting weight of fuel
Apr 27, 2011. Was
redesigned optimization steps. Now steps separated from an Engine-Impulse object
into a individual sections. In “Optim” steps set values like "EngineToOptimize",
"TrajectoryOptimizationType", "NearBody", "Calculate",
“OptimizationInitialStep", "OptimizationDecCoef", "OptimizationStop",
"LastEngine". On each step will be “calculations” after/before “LastEngine”
firing, “calculations” based on celestial “NearBody”. “EngineToOptimize” will be
optimized by a "TrajectoryOptimizationType". Values in “optimization initial
step” ”decrement Coefficient” and “stop” can be different for the same engine.
Apr 25, 2011. May be it
will be useful for optimization's process to dump values in the same TRA.XML
format after passing some/all steps. Was added the dump function – when TRA.Exe
will finish steps it will dump the same xml file with updated values. XML is
good idea until you do not start to use it. Anyway, now it is possible to set
some initial TRA.XML then run TRA.EXE and receive new TRA.XML file. Was added
web service to distribute TRA.XML and collect them back. Such web service can be
useful for distributed calculations. But first needs to finish algorithms for
optimization trajectory and then think about parallel processing.
Apr 25, 2011. Added an
optimization step in a trajectory calculation to adjust an main engine's
impulse. Manually it was done by changing “PropCoeff” for the engine. Now it
increase/decrease total weight of propellant, total weight of an engine, and
individual values of a thrust at each point of a plot. And it does not work
properly.
Apr 23, 2011. Was
removed all code related optimization – it is garbage and it does not work
anyway.
Apr 22, 2011. Some
mistakes/bugs in a code. Manual or individual steps performs perfectly but all 6
optimization steps together gives random results – good indicator for non
initialized variable.
Apr 21, 2011. Second
engine – before firing applied steps (used for a first engine) to get orbit’s
period before and after firing. Calculations takes 6 extra revolution – looks
like raw GPS data for calculations of orbit’s parameters will be critical to
avoid delay in real launch. Application become bulky with optimization steps.
Apr 20, 2011. Was added
step to calculate orbit period after first engine firing. Two periods (before
and after) recorded. Optimization time step is set to 100s via TRA.XML. When
apogee function A(t) reach maximum, then step’s direction switched sign and
step's value reduced by reduction coefficient (from TRA.XML). Whatever takes
previously 2-4 hours to get max apogee now obtained in seconds. Setting step's
value was useful – sometime big step lead to a long iteration cycle.
Apr 19, 2011. Now in
trajectory's calculations needs to fasten all steps together. First will be a
try of all possible firing times for the first engine to score a maximum apogee.
Usually best results achieved firing at a perigee point on the orbit(max speed),
but positions of the Sun and the Moon impact on results. Instead of
investigating the physics of each celestial body and creating formulas was
proved try-the-time-and-maximize-the-result method for that optimization. In
tra.xml was added settings value to a first engine's section to calculate an
orbit period before first engine firing. In simulation it require 1.5
revolutions around the Earth.
18 Apr, 2011.
Trajectory actually looks like a corkscrew – craft travel 1.1 distance
from the Earth to the Moon. Then fly little back to the Earth, makes a turn,
pulled by Moons gravity, and landed on the Moon. Precision landing can be
controlled by a small impulse done somewhere from 1/3 to ¼ earth-moon
distance to the Moon.
Landing: (view from North pole):
Landing: (view to equanox direction):
Landing: Moon view X, Y (from North pole):
Landing: Moon view Y, Z (to equanox direction):
17 Apr, 2011.1.
Implemented forward and backward conversion of (X, Y, Z)
coordinates to latitude and longitude on the Moon surface. Added another
optimization method: “target practice to a point on the Moon surface”.
Now it is possible to set target latitude and longitude on the Moon and
try to reach it by (a) adjusting time of a main impulse engine firing,
(b) adjusting correction impulse (total 150gr propellant) firing angle.
Results are – adjusting (a) – gives the error 300km, combination
(a) and (b) gives error 600m. What is bad in all this trajectories - landing
happened 3 days before sunrise on the moon’s surface. What a . . . setback!
That trajectories require for the vehicle to be able to survive 3
earth-days-1/4-moon-night? Or may be just charge batteries, separate
vehicle from a craft, connected by fishing line, land and transmit only
telemetry (not the Mooncast), then slowly drain batteries (this will heat a
little bit batteries and electronics) for a 3 days (unacceptable crazy idea)
and then travel by fishing line with recording, transmitting and etc. Another
visible problem with trajectories – with 2 wheels design – angle for the Earth
on a moon’s sky will be limited – antenna probably will not work
with angles less 30 degree to the skyline.
15 Apr, 2011.
Brake impulse applied to some of the “good” orbits and the Moon reached
with dry mass 2kg – practically 2.5 times bigger then in first trajectory. It is still
unacceptable (total weight on low earth orbit can be 67*4 = 268 kg) but encouraging.
Useful technique – use 3thd impulse smaller just enough to reach 0.8 of an distance from the
Earth to the Moon. Then use the same time and increase impulse to get 1.1 of a distance
Moon-Earth – this needs to be done carefully – difference in 100gramms and satellite
fly away from earth – moon system. And from that point optimize firing time to get
closest “target practice” results to the center of the moon. It is interesting to see
how orbit smoothes and leaning first to the Sun then later to the Moon. If Moon is not reachable,
no needs to do a correction impulse but sit, relax, and try the next orbit.
14 Apr, 2011.
Recalculation – waiting orbit. Interesting – orbit is not so high
as it was with a bug fixed on April 11. With the bug actually impulse with
correct absolute value were used but the orbit were higher then after the bug’s fix.
Needs to investigate: may be better angles of firing is not an impulse tangent
to ellipse, or opposite to the vector of a velocity, or orthogonal vector from satellite
to the center of earth. If it is true, then some gain can be reached. Recalculation
of a firing time of a main engine get 16 different orbits (again this is a manual
step – needs to implement that step in TRA). Then was tried “target practice” for a
main engine burn. Was found 6 orbits reaching moon’s surface.
No “correction” == fourth impulse skipped.
13 Apr, 2011.
TRA application was optimized to remove rudimentary “optimization”.
Needs to has the ability to optimize 2 different values – (1) time of firing,
and (2) angle of firing, and optimization should calculates – (a) minimum
distance from any: the Earth or the Moon, (b) maximum distance from the
Earth or the Moon, (c) minimum distance as a “target practice” == missing the Moon
if distance from satellite to the earth bigger then distance from the
Earth to the Moon (by delta = N * radius can apply). The case (c) is actually real
target practice – firing angle can be found easily.
12 Apr, 2011.
Day off. Anniversary of a first manned space flight.
Interesting remark from Boris Chertok interview – He stated that if
today he will be asked to give a green light for Vostok-1, then based
on his today knowledge he will never put his signature allowing to
launch Gagarin to the orbit, ship, rocket and equipment was to risky to use.
11 Apr, 2011.
Bug was fixed related to Y coordinates Cos calculations.
Bad bug – but it is good that it was fixed. Trajectory’s recalculation
right away reached the Moon. With bug in code instead of use impulse
based on (X,Y,Z) initial direction vector it uses (X,X,Z) directions –
no dough that it was too hard to target the moon. Immediately was
implemented break impulse. Results are bad. Really bad. From 67 kg of
an original satellite mass to the moon’s surface was delivered only 0.8 kg.
May be this is good to delivery hockey pack but it is definitely not
good to delivery the 6 kg vehicle. With the same ratio it will require 670kg
probe on low earth orbit – totally unacceptable.
10 Apr, 2011.
Were done drastic attempts to reach the Moon – no success. Closest
distance 4000km – analyzed speed in closest point – it is too fast to reach the Moon.
Was fixed some problems in algorithms, no landing. Something is wrong.
9 Apr, 2011.
Trajectories close to the Moon. At some of them it is 10 radiuses
to the Moon. At that closest trajectories satellite gets energy from the Moons' gravitational
field. But Moon’s surface not was reached.
8 Apr, 2011.
The next step - firing a correction impulse to reach the Moon. The probe
flyby near the Moon, close but can not reach a moon surface. For an optimization
of a firing angle done that algorithm: (0) iteration – initial (practically random)
direction firing vector. (1)-(6) derivatives from (0) vector – (1),(2) two vectors
at (X –delta, Y, Z) and (X +delta, Y, Z) direction; (3),(4) two vectors at (X, Y –delta, Z)
and (X,Y+ delta, Z), and last two (5),(6) vectors (X, Y, Z –delta) and
(X, Y, Z +delta) direction. Then all values (0) –(6) were analyzed to get a minimum
distance from the Moon. For a next step choosing a minimum value direction. If it is
vector (0) then delta decreased. Steps repeated.
6 Apr, 2011.
7 Apr, 2011. All 16 trajectories leaning to the Sun direction - which is good,
but the initial orbit’s keplers can be different. For sure initial orbit for a
satellite can bring not foreseeing results. Leaning to the Sun also creates
a problem - at specific position of the Earth, the Moon, and the Sun the trajectory
actually move satellite far away from the Moon. Nobody know is it good or bad.
6 Apr, 2011.
Another optimization step (it is done manually) tried. Previous step (Apr 5, 2011)
gives the time, and that time plus an orbit period also gives another maximum,
but the Sun location in that case different and slightly adjustment has
to be done to the time. Were calculated 16 different firing times and
all was recorded. The maximum of all 16 gives a prime target time. (Not sure that it
is a correct approach – but any way it is a try).
5, Apr 2011.
Added one of the optimization step – calculate a minimum distance at the apogee
(calculated based on the Earth position) to the Moon. Kind of a strange sentence
“minimum distance at apogee”, but very useful – constant monitoring a distance
from a satellite to the center of the Earth, then when a maximum distance reached
(apogee) calculates distance from the satellite to the center of the Moon that
is a “minimum distance at the apogee”. Adjusting a firing time of a main impulse
for each possible position will give a position closest to the Moon with a precision
of 1 sec.
4, Apr 2011. Computer
was restored and webmaster took it right away after the restoration with
explanations that he needs it to use for all night and disappear with his
girlfriend till the next morning. The satellites and orbits lives its own life. Interesting video about Boris
Chertock
http://www.youtube.com/watch?v=4hz5283UAac and Valentin Glushko
http://www.youtube.com/watch?v=cMyhc5Ip5j8
3, Apr 2011. Was found
a virus on a computer, simple and old, but an attempt to kill a virus made the
computer unbootable. The problem is - it is a Mac computer and there are no way
to boot to WinPE or from memory stick with WinPE. Was made an attempt to
continue orbit's investigation using different OS. MAC OS, but XCODE debugger is
really rudimentary, it is a headache to use it. Or to use a Linux machine
(Fedora version “what-ever-it-is”), and debugger is OK (KDE). Needs to clean the
computer and kick the webmaster by hockey stick, may be this can teach him how
to use his (memory) stick safely. Useful for that day conclusion – may be
different binary (MAC OS/Linux) can be used on different platforms – but nobody
needs it.
2, April 2011. The optimization step
was added to TRA. (a) to find first impulse (to achieve a
maximum apogee). Then was added (b) second step to find a maximum perigee of the
orbit. The best way to do such steps is to run TRA application in debugger. Two
predefined variables can be used to control a compilation flavor – “#define
FIND_IMPULSE_TIME 1” to compile TRA in the “find-the-orbit-mode” and the
predefined variable “_DO_VISUALIZATION” to compile TRA in the
“output-jpeg-files-mode”. The executable
available together with a source code, compiled with the visualization but
without a impulse finding code. To run it requires a file “bin410.bin” and “tra.xml”.
To compile project require ‘jpeglibr.lib” or “jpeglib.lib”. Search for a maximum
apogee takes 2 hours on really old computer, and the same 2 hours of a processor
time to find a maximum perigee.
1, Apr 2011. The
visualization was added to TRA – now it can output jpeg files with desired
format (1280x720 for HD video will be best, but 1024x1024 gives the best view).
All planets has different colors. Jpeg files outputs sequentially that makes it
useful to create the animation / HD video. It is possible to choose a planet to
base (0,0,0) coordinates, scale, and etc. The trajectory from previous day was
used to visualize the orbit. Actually the orbit is interesting – on the first
closest point to the Moon the satellite gets gravitation kick, then 30 days
later second kick send the satellite far away from the Earth and the Moon.
31, Mar 2011. Used the
same approach (find a time of a firing in the direction to vector of velocity)
to get a minimum distance to the centre of the Moon in at apogee. The useful
technique – find a time to get a minimum, then adjust the total weight (with 50
grams decrease) of a total satellite's weight, then again find a best firing
time to get another minimum, and again the decrease a total weight by 50 grams.
After 5 hours of a manual steps in debug mode of a compiler was found a minimum
distance achievable - 25,000km to the center of the Moon. Next steps does not
bring satellite close. Was found that it is hard to do a next investigation
without visualization of the orbit.
30, Mar 2011.The first
study for a trajectory was done – it uses Kepler elements for imaginary
satellite:
and an engine from
http://www.canadianrocketry.org/motor_files/37148-O4900-BS-P.pdf. In all
test runs was used the direction opposite to a vector velocity of a satellite.
It is useful to use a debug mode of a compiler to see results. First run was
tests to find time of firing on an orbit to achieve a maximum possible apogee.
TRA was set to try all points (time of firing engine) with interval of 1 sec.
Was found that the Sun’s position can do significant impact on the orbit. After
that was confirmed that (approximately) same mean anomaly (place on an orbit)
gives a similar apogee (difference depends on rotation of the Earth around the
Sun). Then was adjust scale coefficient (PropCoeff 1.0~3.0) to see how it can
impact orbit. Next in test's runs was discovered that proper firing of an engine
can give difference as a twice high apogee (i.e. 135,000 km compare to
70,000km). Then was found that for optimization better can be adjusted total weight of a
satellite. And in one of the tests the satellite actually reached one of
Lagrange points. This case was investigated and it was found that actually a
difference in going to a Lagrange point or stay on around the Earth orbit is
0.02kg (20 grams) in a total satellite weight (with constant weight for sure). Was found a proportion of an
engine weight (~80kg), PropCoeff (3.0 == 51kg of a solid rocket propellant) to
achieve distance 390,000 km. When that experiments was finished (it was
basically done to understand ballistics of a satellite orbiting the Earth) was
made attempt to see how to flyby the Moon. Was used mean anomaly (position on an
orbit) from previous steps to achieve minimum distance to the Moon at the apogee. As
it was expected, tests shows that it will require a some time (up to 30 days) to
use an optimum impulse.
Mar 29, 2011. Was
confirmed that a data available from JPL planetary and Lunar ephemerides
produces coordinates: X – direction to equinox, Z – to Earth’s north pole. That
mean no need for an adjustments of an Earth’s inclination to ecliptic.
Everything is ready to add to simulation engines impulses. Impulses was
implemented in tra.cpp as a graph from engine
thrust's tests, (i.e.
http://www.canadianrocketry.org/motor_files/37148-O4900-BS-P.pdf ). The data
was to be entered in a XML format:
For each satellite can be set different engines. For a convenience it is
possible to use a parameter PropCoeff to adjust the impulse. For sure a real
test’s data of a real engine could be use – but for an approximation it is ok.
Also PropCoeff can be used to simulate real engine firing – satellite can be
rotated and vector thrust can be controlled by rotation (траектория конуса), in
that case impulse can be less that 100% - and PropCoeff with corresponded value
will be a good approximation for that firing.
Mar 27, 2011. Kepler
elements
Kepler elements was processed to get the position of a an velocities of a
satellite in steps. The first step - to use a longitude of ascending node (where
the orbit passes upward through the reference plane), to calculate a clockwise
or contraclockwise direction on an ellipse. The second step – to calculate the
position (X0,Y0) and the speed (VN,VR) at mean anomaly . The third step – to
calculate (VX0, VY0) based on a direction (clockwise, contraclockwise see Pic1
from previous post Mar 26, 2011).
At that moment all calculation was done in the orbital plane, the coordinate Z
assumed equal 0.
The fourth step (X1,Y1,0) (VX1,VX2,0) - to adjust a argument of the perihelion
angle from an intersection line of the orbital plane and the reference plane to
a perihelion direction (a lower point on the orbit):
The fifth step (X1,Y1,Z1) (VX1,VY1,VY1) , values X1 and VX1 are intact from the
previous step - use an inclination of an orbit’s plane to a reference plane (the
inclination for a satellite done based to the Earth equator – in Tra.cpp it has
to be added Incl + <inclination the Earth to an elliptic plane) in call
KeplerPosition.
The last step - to use an ascending node angle btw the reference direction
(Easter) and the intersection line of the reference and the orbit plane.
One issue was not done et – the mean anomaly has to be adjusted from a satellite
epoch to a current epoch.
Mar 26, 2011
The bug was fixed in a Kepler element’s calculation to adjust the clockwise and
contraclockwise rotation. (tra.cpp)
Mar 25, 2011 The
source code was cleaned from a garbage of a last month experiments, added
a satellites simulation. The next step is to rotate satellite(s) around the Earth. Bug
was found in calculation of velocity’s vector direction. The modulus of a
velocity calculated from Keplers elements is correct but direction is wrong –
IIS actually instead of smoothly rotates around the Earth fly directly up and
fall back to the Earth. Really needs to insert into Tra source code for
visualization, it is actually funny to see it.
Mar 24 2011. Finally
was found a source of error in the Tra application. The sidereal year
(31558149.7635456 s) is one revolution around the Sun. The tropical year
(31556925.216 s) is another measure - ecliptic longitude of the Sun to increase by 2∏ (
2* 3.1415. . . = 6.283185307179586476925286766559 or rotate 360 °). The anomalistic
year (31558432.5504 s) is one revolution around aphelion. And (stupid Alex!)
calculation of a year was assumed as a closest point from a starting point of
Earth+Moon barycentre. It will be correct but actually all ellipse is moving –
and next year mark will be close to another point on orbit. Quick changes in
testing calculation (it was used 3 sin() of angles btw the Sun and the
Earth-Moon barycentre) and year is matched – nice (not actually – error is 50
sec - needs to use 3 sin() of angles btw the Sun and the Earth, not a
barycentre). Sin() also perfectly show the equinox, and the opposite point on
the orbits.
results file: results file: ttt11.txt
Mar 23, 2011. Tra.exe
source code was reorganized – to make it more readable. It is possible to
dynamically include or exclude from calculations some planets. Satellites
simulations can be done same way as planets.
Mar 22, 201 Applying
coef=1.0 gives a surprise. All error in Earth-Moon barycentre was 49000 m(!) per
year which gives 1.5 sec error with 410 data. Error on the geocentric Moon’s
position achieved 1000m in 7 days, then 1500m in 20 days, then it stay in limit
16000m (16sec) during 31558149 second. Data 410 really matched. What is wrong in
this case with a year's duration, is it calculation? Or is it something else? Or
velocities are wrong?
Mar 21 2011. In Tra.exe
was embedded JPL EPHEMERIDES 410 data. It is possible to compare each second
calculated position and coordinates from 410. First was used geocentric Moon
position. Coef =0.575 gives 1000m the error at 10 days with a 1/8 sec precision
and a 25 day error, then the error was flying out of a range. The barycentre of
Earth-Moon has some behaviour.
Mar 16, 2011. The attempt
to include into tra.exe the data directly from 410, a previous code was based on XML
compatible file produced by a modified version of rdeph.exe. XML is fancy but it
is not a necessary step. Playing with coef = 0.574 and 31558149 – was proved that
delta T = 1/8 sec or 1 sec does not help to get close to magic number 31558149.
May be needs to constantly compare planets position from 410 to find where the
error come from.
Mar 15, 2011.The attempt
to add to equations heavy planets. That makes calculations slow but results did
not show a magic number 31558149 – amount seconds in a year. Playing with a speed
of Earth in relation to the center of gravity Earth-Moon system can adjust a value
close to year’s duration but the coefficient is out of a range. Based on Earth's and
Moon's masses, geocentric coordinates of the Moon and the barycentre a simple proportion can
apply to calculate Earth and Moon coordinates. The Moon velocity in a geocentric
coordinates known and a vector’s direction for the Earth velocity is correct, but
a value of a vector has to be adjusted. Calculations shows coef ==0.574 which is
out of possible range 0.9 - 1.1.
Mar 13, 2011. Small
problems in a NASA’s published source code was fixed and
a
bin410.bin file (based on
header.410 and ascp2000.410
) was generated. The output file with XML lines ready for tra
simulation was generated with positions/velocities of the Sun, the Earth, and the
Moon based on Jan 1 2000, (Julian Date = 2451544.5 ), and tra was forced to use
da ata from DE410 – results is actually discouraging. Error jumped to 8000 seconds
per 1 year. Now needs to find the better way to understand where the error comes
from (for sure it is nothing to do with JPL’s data). The problem also in a way how
the position/velocity from observations fits into a prediction. Some authors
did interesting job by applying the computer power and just tailoring coefficients
at Fourier Transformation to minimize the error and minimize processor's time
inside satellite’s onboard computer. But anyway – one of a possible design of a
vehicle stuck – to actually give green light for it’s development needs to
achieve precision of 10 m on the Moon's surface.
Mar 9, 2011. Was
assumed that positions/velocities of Sun-Earth-Moon’s bodies brings errors. Was
done an attempt to use NASA’s data – some of DEXXX available files(The ephemeris
package is available over Internet from the anonymous ftp server:
ftp:\\ssd.jpl.nasa.gov\ and dir
pub/eph/planets). Was fixed some minor errors in C version of a code (convert.c)
done by David Hoffman from a NASA Jonson Space Center. Looks like porting code
from Fortran was a source of errors (arrays in C started from 0; does in Fortran
it starts from 1?). Some of memory was corrupted around R1 and R2 constant
(array of 400 elements initialized, but in line “for ( i=0 ; i<=400 ; i++)”
needs to change condition to “i<400 ;). Also another memory corruption around
“val” variable - ARRAY_SIZE assigned to 1018 – but in assigning “val” operator
“if (3*i+1 > recSize) break;“ has to be changed to “if (3*i+1 >= recSize)
break;”. Additional for Windows function “fopen” require “outfile =
fopen(argv[3], “wb”);” and in module ephem_read.c “Ephemeris_File =
fopen(fileName, “rb”);”. Modified source code:
append.cpp, append.vcproj,
convert.cpp,
covert.vcproj,
epheem_read.cpp,
ephem_read.h,
ephem_types.h,
ephem_util.cpp,
ephem_util.h,
rdeph.cpp, rdeph.vcproj,
tra.cpp, tra.vcproj,
tra.xml, tra.sln
Mar 5, 2011 It does
not show much actions when the software is in a development process – bytes and a source
code does not looks attractive as a bad designed vehicle. After one week of an
investigation (what was done year ago) a memory refreshed and everything goes
back to a debugging. Probe’s Kepler’s elements were commented out and a main
task switched to a business – estimate an error by applying formulas of a
sun-earth-moon system for 1 year with 1/16 second interval. Rough calculation
shows that actually there is no better way to find The Moon position than just
look at a sky. When the center mass Earth and Sun model assumed, GM3 used, error
actually in 1.5 sec range for 1 years simulation (see results). But when into
simulation added Sun's positions/velocities around center of mass, and
positions/velocities of a Earth-Moon barycentre the error jumped to
unacceptable level around 700 seconds per 1 year
Mar 2, 2011. Tra.xml
file was updated, the same with new 32, and 64 bit build target. 1 year
calculations with 0.125 sec takes in debug 2 min 40 sec, release 2
min 5 sec, 64 bit release with fast floating point 1 min 35 sec, error 1km in 30
days. Switching to precise fl. point brings same speed as on 32 bit.
Flight scheme.
1. Launch on a “low earth” orbit can be done via commercial vehicle or as additional
payload form regular government’s funded space launch. Sample is amateur’s radio
satellites, which has low weight and was launched as by-product of commercial /
government satellite’s launches. Payment for launch must be done as a requirements
for participation in competition. Orbit can be pre-calculated but likely be unpredictable.
Parameters of orbit after successful launch are to be made independently (from a
launcher company) calculated and verified by GPS module(s).
2. Up to 5-20 circulation will required the check of all on-board equipment/systems
and for preparation for low-orbit high-orbit manoeuvre. Crucial systems functionality
has to be confirmed: astro-orientation, orbit parameter's calculation, communication,
image delivery, data transfer.
3. “Low-orbit” to “high-orbit” transfer has to be done via two impulses. High orbit
has to be achieved because of unknowing parameters of low-orbit, resulting in an
unknowing waiting time (up to one month) before flight to the moon. Impulses can
be roughly calculated and preformed by less precision high-thrust engines. High
orbit has to be achieved to avoid atmosphere influence on waiting orbit, manipulators.
4. “High-orbit” to “waiting-orbit” transfer must be done via low-thrust precision
engine. The engine needs to be fired up a couple of times to delivered impulses
for orbit correction. Without rushing all system functionality needs to be tested
at “waiting-orbit”.
5. “Waiting-orbit” to “flight-orbit” transfer must be done via one impulse less
precision high-thrust engine. After impulse used engine’s parts are to be disconnected
or ejected. All command for orbit correction has to be verified before this manoeuvre.
6. At “Earth-moon orbit” intensive orbit corrections must be performed. All correction
must be done by low-thrust engine.
7. Brake impulse can be preset and constant at design stage, plus-minus variation
verified at testing stage. “Earth-moon orbit” correction together with intensive
calculations on mission control system, and on-board computers to delivery probe
in specific point, with specific velocity in sun-earth-moon celestial point. Astro-orientation
system must set impulse vector based on desired landing place. Brake impulse should
slow probe enough to allow for soft-landing (air-bag based) system to adsorb impact
of a probe in the lunar surface. Before soft lading all unused parts and engines
need to be disconnected /ejected. Probe manipulators / components need to be placed
into a landing position.
All calculation will be done via simulation software available here.
Tra.cpp
Tra.sln
Tra.vcproj
Tra.xml
Tra2010.sln
Tra2010.vcxproj
stdafx.cpp
stdafx.h
added JPL data:
ephem_read.h,
ephem_read.cpp,
bin410,bin,
convert.cpp, rdeph.cpp,
rdeph.vcproj,
rdeph2010.vcxproj
added for viualization:
traimg.cpp
jpeglib.lib
jpeglibr.lib
jini.h, jini_md.h,
jpeglib.h, jri.h,
jri_md.h,
jritypes.h, lwinfig.h,
prcpucfg.h,
prtypes.h
xp_core.h,
jconfig.h, jmorecfg.h
binary with visualization, but not orbit optimization
tra2010.exe
For now this one year old code allows to play with:
– Keplers coordinates entry for Earth, Moon, and satellite
– Different “space” constants (actually different source
gives different trajectories for earth, moon and etc.)
Impulses needs to be added to finish simulation, together with detection of a
landing. Also it will be nice to process data available from Moon’s mapping to
proper detect landing point.
Another main add-on to be done to the simulation – calculation 4
impulses time of initial orbit parameters.