Adobri Solutions Ltd
   Google+    www.googlelunarxprize.org        P2P web search portal    



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.hephem_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.