Year 2011. События за год 2011
ON FEBRUARY 16, 2011 06:11 PM Introduction to Team Plan B
Главная цель в соревнованиях.
Team "Plan B" это Ванкуверская группа энтузиастов объединенных
задачей достигнуть Луны, выиграть Google Lunar XPRIZE, и показать, что с помощью компьютерных технологий,
возможно минимизировать затраты на достижения Луны до 5-10 миллионов долларов.
В нашем понимании соревнования предоставляют уникальную возможность в истории космического исследования
космоса и Луны.
This engagement is taking place when advances in technology,
electronics, telecommunications and science are stretched to their limits.
Furthermore expansion and technological slump is readily at everyone's disposal.
It’s a time of planting new grass. Seeds will adsorb everything available in current soil of innovation,
grow strong on existing high-tech's compost, compete unpredictably with each other,
and at the end of the day fertilize new ground for the next metamorphoses of technical knowledge.
Team "Plan B" hopes that our feasible supplements will help make that next technological stride possible.
For our mission we choose to utilize handy solutions in software, microprocessors, communication,
guidance and robotic systems to produce a light weight vehicle capable of wandering 500+0.5 m around
the landing site; with coordinate’s 2ºS 15ºW on the Lunar surface. The light weight
vehicle must be able to transmit a mooncast. The vehicle will be delivered to the
Moon by a probe/craft with fixed impulse engines.
Target weight on low-earth orbit for a probe+craft is 100-150 kg, which places it into a category of
amateur satellite. Flight scheme will include two orbit correction impulses, one main and one brake
impulse with direct arrival to the Moon surface with air-bags providing the soft landing.
Designed and manufactured vehicle/craft must pass thermal, mechanical, and vacuum's ground tests
prior to making launch arrangements. Two launches are planned to increase chances to succeed.
Success on first launch is desired, but is not expected, mistakes in design, errors in calculation,
bugs in software on first mission will provide valuable input for the second (Plan B) vehicle/craft/probe
re-design. Second launch is planed for 9 month after the first mission.
While in flight, the probe's orientation will be performed via inertia momentum created by the
rotation of three masses. As a Canadian team, we choose those 3 masses to be three hockey pucks,
not because hockey pucks are heavy, but because the touch down will be simultaneously the first
face-off on the Moon, in the history of Mankind. All project's development is licensed under
Creative Commons Attribution-ShareAlike 3.0 Unported License. This allows everybody to share
(to copy, distribute and transmit) and to remix (to adapt) anything related to designs and development
done by team "Plan B".
Октябрь 2009 - Ноябрь 2009
Это начальная точка дизайна ровера. Кабы версия 0.9
Цель - повыпендриваться с дизайном - так для удовольствия, не более.
Идея была сделать полность плоский ровер, удобный к транспортировке в полете, с пятью ногами, переваливающимися по поверхности.
Крайние две ноги это антенны. Две ноги силовые, с четырьмя шаговыми моторами,
каждый шаговый двигатель исилен редуктором.
Центральная нога с двумя камерами. На трех ногах, с двух сторон - солнечные батареи.
Две крайние ноги имеют две степени свободы. Конструкция может переваливаться по поверхности луны.
Красивое движение получается. Но, если чесно - все будет запылено. Особенно антены, с них надо как-то статикой
Солнечныные батареи тоже надо как-то защитить от пыли.
В принципе не плохо - устойчивое движение можно легко обеспечить. :
on a surface:
одну ногу с камерой можно поднять, сфоткать окружающую действительность,
направить одну из двух антенн на землю, передать картинку, а потом как ванька-встанька
- вообще то как флип-флоп а не Ваньку валять. With one camera elevated to get picture (or in movement) :
Антена направленная для коммуникации с землей - (плохо- каждый раз нужно
наводить, но если достаточно энергии и отладить контроллер на ориентацию к земле
с точностью 2 градуса, то можно путешествовать пару дней - пока не сдохнут
With one antenna oriented to earth direction :
На фотографии собраная боковая нога - самым тяжелым оказались редукторы шаговых двигателей.
And that are pictures of assembled leg :
Удобство конструкции - можно надуть небольшую резиновую подушку и упасть на
поверхность луны плашмя. Редукторы очень тяжелые получаются - нужно делать
из hard anodizing aluminum. Попытка обойтись без редукторов тоже не удалась -
угловой момент вращения на доступных шаговых двигателях недостаточен для
движения в условиях 1/6 земной гравитации. Оценка веса конструкции показала 8-10
кг. Цыфру конечно можно уменьшить за счет карбоновых композитов, но редукторы и
шаговые двигатели оказались самыми тяжелыми и карбон-композиации не могут быть
подвергнуты. Высота камеры над поверхностью тоже не дай боже.
Эксперименты конечно интересные, но реальный ровер должен быть другим.
Upon the lunar surface all probes will land flat - 0.5m x 0.5m x 0.05m perfect
for air bag protection. But idea does not work – calculations showed that even with
1/6 of earth gravity geared motor are required. Regular step motors does not produces
enought momentum. One (motorized) leg was designed, built, and tested. Tests
also showed that it will be hard to protect solar panel from damage due to sharp
stones and sharp lunar dust. Another problem – weight of leg give estimation for
total weight – 8 -10 kg. Despite perfect moving capabilities and ideal camera's
viewing position this design was abandoned. As a result those pictures are only
what was left to remind – calculate first and do build after.
Далее следуют фотографии с различными крепленями двигателей - ничего
алюминевого не должно быть -только углеродный композит. Но побаловатся можно
было. On previous picture holder for a 360 degree motor. Was not strong enough –
can be re-enforced by changing bolting screws
Also another problem - need to reinforce back of the motor – otherwise it will bend
at certain degree of impact::
It is clear visible on previous and next picture.
It is clear visible on previous picture.
Солнечные панели расположенны на растоянии 25 мм от поверхности - посередине
ноги. Могут побится об булыжники и гарантировано запяляются.
Solar panel (screw for bolting visible on a tube) will be in 25 mm distance from
a ground - need to place protection shield on both sides – all shields will reduce
А два шаговых двигателя дают возможность крутиться ногам как только
пожелаешь. Only one part was satisfactory – extender between two motors - it gives 360 degree
movement for a second motor.
Для шаговых двигателей понятно что необходима их переделка. В каждом подшипники,
подшипники должны быть заменяны на керамические. Керамические подшипники
увеличивают цену двигателя на 100-150 баксов.
Another useful knowledge from that “flat” design - stepper motors will require disassembling
and removing original bearings and changing it for ceramic one – bearing needs to
be easy to change. If decision will be made to return to “geared” motors – gears
have to be ceramic ones – even with different ceramics available now - design and
build can be problematic and time consuming.
ON FEBRUARY 22, 2011 05:17 PM Team Plan B – vehicle design update.
Главный офис требует дизайн ровера от каждой команды (как будто это главная
часть). Ну раз просит - тогда нарисуем. Итак понятно нужно сначала получить опыт
полета возле земли. Проверить коммуникационную аппаратуру. Если покупать с
полки, то обдерут как липку. Проверить систему ориентации. Опять же - декларация
о том, что систему можно купить в нынешних условиях развития космоса, то скорее
всего всучат что-то очень дорогое, старое (пардон проверенное!) и работающее не
так (секретность разработки). Проверить орбиту. Это вообще песня - платишь
умникам (пардон баллистикам) из университетов 100 штук, потом нужно пресчитать -
опять платишь. И так до бесконечности. Ну и перед полетом готовишь 100 штук для
НАСА - платишь и они делают свой расчет. Считают сигмы ошибок и выдают
разрешение на старт. Затем нужно проветить на полете двигатели, Затем шмякнутся
в луну. А затем дойдет вермя разработать ровер и лететь. Но у Гуггл Лунар
своё видение соревнование. Хорошо - нарисуем трехколесный велосипед с антеной, и
Vehicle design. Three wheels powered by stepper motors gives the vehicle the ability to travel and to steer in desired direction (limited but ability). However, positioning an antenna to the Earth direction will require something more than a stepper motor’s steps with 1.8 degree precisions. Obvious way to do this is to use some ceramic gearbox (one at least). An attempt was made to understand how to build such a gearbox. Was investigated way to manufacture cast for planet and sun gear in Epicyclic gear type (http://en.wikipedia.org/wiki/Epicyclic_gearing). Such gear’s type was chosen to make it as small as possible and as a result to achieve light weight. For a cast manufacturing it is handy to use a 3D printers (http://www.makerbot.com/ , http://www.botmill.com/ , http://www.pp3dp.com/ , or a more easy way - to make 3D model design in .stl format, upload it to personal factory like http://www.ponoko.com/ , and build plastic cast with precision 0.2 mm (the same technique can be used to create a cast for any carbon fiber elements of a probe/vehicle). Castable ceramic like 672, 510, 646, 589 can be used. See more on http://www.adobri.com/ProjectVe.aspx
ON FEBRUARY 28, 2011 03:04 PM Team Plan B. Introduction. Message A.
Дочь помогла записать вступление - со всех требуют видео - 45 минут в месяц.
Кто не выдаст видео на-гора, того грозят выгнать. 45 минут это минимум 18 часов
редактирования. Кроме того хотят чтобы видео было информационным,
образовательным, впечатляющим, чтобы больше людей смотрело, заходило на Гугл
Лунр ХПРАЙз, на видео в ютюбе (больше рекламы - быстрее гугл отобъет деньги,
басрее долетим до луны).
ON MARCH 07, 2011 05:19 PM Team Plan B. Vehicle design update.
16 month left to the deadline. Attempt to re-design a vehicle. It will be the third re-design from beginning of project, first was flip-flop movement with 5 segments, 8 stepper motors and 2 segments/antennas used as helping legs. First design was abandoned because of a high weight (>8kg) and sophisticated gears which does not reduce mass. Was considered different methods of movement. All was looking good and promising, but requires complicated mechanical parts movable against each other in a vacuum condition, survivability of drop also will be questionable. Mechanical engineers suggest some. . . See more on http://www.adobri.com/projectve.aspx
ON MARCH 15, 2011 02:02 PM Trajectory Calculation Issues
Simulation position and velocity of Sun, Earth, and Moon bodies brings errors. An attempt was done to use NASA’s data – some of DEXXX files are available. Minor errors were fixed in the C version of the code (convert.c) done by David Hoffman from a NASA Jonson Space Center. Looks like porting code from Fortran was a source of errors. Some memory was corrupted around R1 and R2 constant (array of 400 elements initialized, but line “for ( i=0 ; i<=400 ; i++)” need 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, “wb”);” and in module ephem_read.c “Ephemeris_File = fopen(fileName, “rb”);”. Further information at http://adobri.com/ProjectTra.aspx
ON MARCH 27, 2011 10:51 AM vehicle development
Sketches for 2 wheels design and two type of movements were made. Next step is to create drawing. Considered making composite structures. Parts for carbon fibre production will be done in two steps – manufacturing at Ponoco plastic component, and testing, then using same component to make forming using modeling ceramic. Aluminum parts will be manufactured as it was done previously.
ON APRIL 01, 2011 09:53 PM Update on trajectory calulations:
Kepler elements was processed to get position on velocities of a satellite in steps: First step - to use longitude of ascending node (where the orbit passes upward through the reference plane), calculated clockwise or counterclockwise the direction of the ellipse. Second step – calculated the speed position (X0,Y0,0) and speed (VN,VR) on mean anomaly. Third step – calculate (VX0, VY0,0) based on direction (clockwise, counterclockwise see Pic1 from previous post). At that moment all calculation were done in orbital plane, coordinate Z assumed equal to 0. Fourth step - adjust argument of perihelion angle from intersection line of orbital plane and reference plane to perihelion direction (lower point on orbit). See pic2. Fifth step (X1,Y1,Z1) (VX1,VX2,Z1) values X1, VX1 intact from previous step - use inclination of an orbit’s plane to reference plane (inclination for satellite to the Earth equator – in Tra.cpp it has to be added Incl + http://www.adobri.com/ProjectTra.aspx
ON APRIL 07, 2011 11:54 AM Discussions about already abandoned second prototype vehicle’s design.
See more on http://www.adobri.com/ProjectVe.aspx
ON APRIL 15, 2011 03:00 PM Trajectory study
. . . that mean no need to do adjustments for an Earth’s inclination to the ecliptic. Everything was ready to add engine's impulses to a simulation. Impulses was imported into TRA application as a data from plot on engine’s firing tests . . . For a convenience it is possible to use parameter PropCoeff to adjust a total impulse. For sure real test’s data of a real engine should be use – but for an approximation it is ok for now. Also that PropCoeff can be used to simulate a real engine firing – satellite can be rotated and vector thrust can be controlled by a rotation, in that case an impulse can be less that 100% - and PropCoeff with a corresponded value will be a good approximation for that firing. The first study for a flight trajectory was done – it uses Kepler’s elements for imaginary satellite and engine from http://www.canadianrocketry.org/motor_files/37148-O4900-BS-P.pdf. In all test’s runs was used the direction opposite of a vector velocity of the satellite. Debug mode of a compiler found to be useful for checking results. First tests targeted to find a firing time on an orbit to achieve a maximum possible apogee. TRA were set to try all points (engine’s firing time) with interval of 1 sec. It was found that the Sun’s position can do impact on the orbit. Then was confirmed that (approximately) a same mean anomaly (place on an orbit) gives a similar apogee (difference depends on rotation of the Earth around the Sun). Then were adjusted scale coefficient (PropCoeff 1.0~3.0) to see how it can impact the orbit. Next in test’s runs were discovered that proper firing of an engine can give a difference as a twice high apogee (i.e. 135,000 km compare to 70,000km), possibility that this is just is a bug in TRA application is not ruled out. Then it was found that experiments better to be done with satellite’s total weight variation then with impulse variation. At one test satellite actually reached one of Lagrange points. This case was investigated and it was found that actually difference in going to a Lagrange point or staying on high apogee Earth orbit is 0.02kg (20 grams) at total satellite weight. Was found proportion of an engine weight (~80kg), PropCoeff (3.0 == 51kg of a solid rocket propellant) to achieve distance 390,000 km (which is not good!). When experiments was finished (it was basically done to understand ballistics of a satellite orbiting the Earth) was made an attempt to see how to flyby the Moon. Was used previous step’s mean anomaly (position on an orbit) to achieve minimum distance to the Moon on apogee (may be apogee is not a good point?). As it was expected it shows that it will require some time (up to 30 days == one revolution of the Moon around the Earth) to achieve an optimized impulse. (see more on http://www.adobri.com/ProjectTra.aspx)
ON APRIL 18, 2011 02:47 PM Latitude and longitude
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? see more on: http://www.adobri.com/ProjectTra.aspx
ON APRIL 19, 2011 04:03 PM Photo Album. Thermal tests -78C. All tests passed as expected.
ON APRIL 29, 2011 01:30 PM Ceramic gear design and manufacturing.
ON MAY 12, 2011 12:48 PM Thermal tests. Part one. -78C.
ON MAY 20, 2011 10:41 AM Thermal tests -78C. Part 2.
ON MAY 30, 2011 05:15 PM Update on vehicle design.
Design page http://www.adobri.com/ProjectVe.aspx will be updated to reflect current changes on recent drawing in step by step vehicle design. Wheels. Each wheel has 16 springs made from ether steel or carbon fiber. For steel’s it is easy to cut parts from specific thickness steel’s sheet and a coefficient for a Hooke’s formula can be easily calculated, confirmed and controlled. More complicated process is for a carbon fiber – all controllable parameters are: amount of layers (one, two, or three layers of a carbon fabric), different types of fabrics, and amount of epoxy (solo depends on a mold). The mold manufacturing can be complicated. It was chosen simple approach - first made 3D model and manufacture it at http://www.ponoko.com/showroom/TeamPlanB. Ponoko Personal Factory can produce parts from a plastic which is not suitable for real springs, but plastic model can be used in mold’s manufacturing. Then depend on a results (carbon fiber’s molding or steel springs cutting) can be made the decision: what is better. Arbitration are usual - the weight of a wheel, and performance at different temperature. Absence of a gear will definitely reduce weight, and springs flexibility can accumulate energy to get momentum enough to travel over obstacles and craters. Coefficient in Hooke’s formula and precision delivery of a momentum by stepper motors can pump energy (using resonance frequency) into a spring system and a precision release (of that energy) will give jump’s type of movement for a vehicle. This is similar to a case (if somebody remember from past) when a car was stuck with one wheel at road’s hole, small oscillation (as back and forward push) can release car from road trap. From another hand (to save a time) plastic parts can be used in vehicle software development, some flexibility plastic already has and braking plastic part can be indication of a proper resonance frequency achieved. Wona stated that this type of wheel is totally useless without controllable software. Problems: 1. How to make a mold for carbon fiber? Probable answer on that question – to order mold from a different type of ceramic/plastic. 2. How to control stiffness/elasticity for carbon fiber’s springs? Probable answer – to make 3 different (1, 2, or 3 layers of carbon springs) and use combination of different springs. 3. How to calculate resonance frequency of a wheel in assembly? Probable answer – software has to be adaptable to different parameters/performance of springs. 4. Does it require carbon fiver clothe wrap to make bigger surface contact? Answer for this question is actually: Yes Blender files available. SW file coming soon.
ON JUNE 02, 2011 11:51 AM Frame design.
Two aluminum tubes with two aluminum plates, holding tubes in parallel each other. Four stepper motors – two for wheels and two for antenna and camera stands. Motors for a camera stand and antenna was to be with gears with 1.x 3.5 ratio. Gears made from ceramic grinding tools. On a frame mounted an aluminum mirror allowing HD camera’s observation in holding position. On tubes mounted flexible solar panels with angles 45 degree to the center line, solar panels both sides orientation. Aluminum frame and plates will be warped for enforcement with one or two layers for a carbon fiber. This will create “composite’ structure – soft aluminum inside and carbon fiber outside. For mockup all parts except aluminum tubes ordered over http://www.ponoko.com/showroom/TeamPlanB. Problems: 1. Needs to find flexible solar panels with good performance in temperature range and under of UV and high charged particle’s conditions. Current power capabilities are around 6-8 W total, and in real life it will be around 2.5-3 W. Which is not acceptable at all. 2. Orientation for aluminum mirror. 3. What a minimum distance from solar panel to antenna’s stand rotation axe? (To avoid interference with communication). 4. Protection for a two wheel’s stepper motors. Originally wheel’s springs will give protection at impact, but looks like it will require some carbon’s bees’-comb-like structure for additional protection. 5. Manufacture molds for top layer of carbon fibber (for tubes and plate) with bees’-comb-like pattern. 6. Protection for a gear needs to be decided. 7. Holder for solar panels does not look good.
ON JUNE 28, 2011 05:50 PM Draft for range calculation
Attached is the video where Alex and I discuss the task of calculating the range between the lunar surface and our probe.
ON JUNE 30, 2011 12:58 PM Schema draft 2
This video shows Alex and I go a little further in depth about the probe's range calculation schema
ON JULY 04, 2011 09:06 AM Breadboard Prototype
This video was to be posted for the month of June. Technical difficulties aside the video shows Alex test out the laser range calculator.
ON JULY 18, 2011 12:04 PM Soldering Laser Range Prototype part 1
Alex soldering laser range prototype part 1.
ON JULY 20, 2011 12:38 PM Soldering Laser Range Prototype part 2
Alex soldering Laser Range Prototype (medium stages)
ON JULY 25, 2011 05:58 PM Laser Distance Finder
During descent, to ignite brake engine at 2800 m/s requires real time distance measurement to Moons’ surface. We think radar or laser can be used. Weight for radar is heavier of the two concepts, around 2-3 kg, which is too large for our small landing vehicle design. Alternative approach is a Laser Distance Finder (LDF). In this case weight will include only two optical lenses, electronic equipment and mounting, significant saving in total mass of a probe. Off-shelf laser range finders can work on maximum distance for a couple kilometres. Requirements – measure distances from 30 km to 5km, reflection from a lunar dust, 0.5W laser. Additionally (a) if it possible the same system can be used to transfer data by laser beam and (b) be used to measure distance to reflectors on a moon on early approach stage. See more on http://www.adobri.com/ProjectCr.aspx
ON AUGUST 02, 2011 11:43 AM Systems from a craft can not be tested on a ground but in orbital flight.
Check - which systems from a craft can not be tested on a ground but in orbital flight. The critical one (a) GPS data collection from raw data ID 30, (b) orientation system (on a ground it can be only a simulation), (c) communication system with 2.4 GHz, (d) orientation system with 3 axes (e) astro-navigation system (calculation direction to the center of Earth, and star matching system). (f) backup communication. GPS any way needs to be developed for correct main impulses direction. Electronics can be done in 2 weeks, and software will be major development. First it will transfer ID30 satellites reading using backup communication. Then by formula on a ground calculates Keplers elements and transfer orbit params back using backup system. Weight for a sensor 25 g. For ground tests can be used the same TRA app with 5 GPS satellites Keplers element and simulation of a ID30 data. When formulas finalized and errors estimated the same source code can be inserted into a flight main computer. No backup calculations of Keplers elements in microcontrollers. ..... See more on: http://www.adobri.com/ProjectCr.aspx
ON AUGUST 08, 2011 05:29 PM Systems from a craft to be tested on orbital flight.
Orientation system will include 3 stepper motors. For a test on 1kg total mass it will be require motors with bearing. Suitable weight for each 30 g. And lubrication can be changed to molybdenum. Gyro sensor readings should be compared with targeting XYZ values. Onboard main computer has to be adaptable to different type of motors, (a) different inertia momentum, (b) delays of control to avoid oscillation. Dynamic parameters of a system has to be calculated (not predetermined) using same gyro-sensor. Placement of 3 stepper motors may be not in a center of mass – as a result to support orientation along any of 3 axes, system should calculate parameters by itself. On ground tests for a system can be done only for one axe, and in plane intersect center of mass. In worth case scenario it will require to download new binary for orientation system (effectively for a main onboard computer). See more on http://www.adobri.com/ProjectCr.aspx
ON AUGUST 15, 2011 12:41 PM Composits parts
Small panic about 526N epoxy – by all parameters it is acceptable (-78C +300C tolerance, flexibility, outgassing, and etc.), but it is not in it http://outgassing.nasa.gov/cgi/sectionb/sectionb_html.sh Material Alphabetical Listing. This (not in list) may be problematic for any composites used in vehicle and craft.Epoxies 517, 556, 568 present in a section B list but it is not suitable. After contacting manufacturer it was confirmed that 526N actually was tested around 20 years ago for outgassing study and Total Mass Loss (TML) at 125C is 0.49 (less then 1%) and Collective Volatile Condensable (CVCM at 25C) Materials is (0.00) with curing conditions 2H (93C) and 16H (204C). Epoxy is good, looks like it will be require re run ASTM E-595. Anyway satellite (including vehicle) was to pass vibration tests according launch vehicle profile and thermal-vacuum bakeouts to ensure level of outgassing at minimum vacuum 5x10-4 Torr. Manufacturing of composites was to be documented. See more on http://www.adobri.com/ProjectCr.aspx
ON AUGUST 17, 2011 11:29 AM Molds, epoxy, ant etc
All molds were received – now it is possible to make different thickness’s springs: 1.5, 2.0, 2.5, 3.0 mm. Also was proved – amount of carbon fiber / threads inside the mold 1.5mm – 4 layers of carbon fiber , 3 layers and just threads (no fabric) gives a different linear elasticity (easy to measure – on a electronic scale – amount of a weight require to connect sides of a spiral). Also was discovered a mistake (may be not) – if to place the assembled mold into a vacuum chamber, then excessive air pockets inside mold squeeze out epoxy from the mold. From one point it is not looking good – a cross section of a spring is not regular – but spring become lighter 25%, epoxy stays just on carbon fiber, and coefficient elasticity is bigger. For future use – placing in a vacuum chamber has to be done before closing the mold (for nice looking springs), or in assembly (for saving weight and increase elasticity). Also was found a way to speed up process (up to 5 times) and make spring more controllable. The carbon fiber has to be in a braid (or a plait) – different technique can be used to control amount of fiber and physical dimensions (5 x 1.5 x 500 mm). Also was proved an easy way to control temperature for epoxy’s curing – the induction stove from Wal-Mart + connecting sequentially to a thermo element variable (10-100kOm) resistor and the temperature inside the chamber wrapped by aluminum foil will stays with 1 centigrade range. See more on http://www.adobri.com/ProjectVe.aspx
ON AUGUST 17, 2011 11:31 AM Molds, epoxy, ant etc. (and video part 1)
ON AUGUST 17, 2011 11:31 AM Molds, epoxy, ant etc. (and video part 2)
ON AUGUST 23, 2011 10:17 AM Composite Spring part 1
ON AUGUST 23, 2011 10:18 AM Composite Spring part 2
ON SEPTEMBER 01, 2011 03:50 PM 2.4GHz communication
Antenna 2.4Ghz – for ground station helical antenna design and manufacturing – it will be better to print such antenna than make it by hands – 3D printing material suitable is Nylon 12. Two 3D printing facilities : Ponoko: http://www.ponoko.com/design-your-own/products/2-4ghz-ground-antena-6246 and Shapeways: http://www.shapeways.com/model/322767/2_4ghz_antena.html?gid=sg85851 . After printing all what will be left - to connect flat reflector made from PCB board, and 0.3 dia wire. For mockup of a testing antenna on CubeSat (that one has to be made by hands) 3d model: http://www.shapeways.com/model/322768/small_2_4ghz_antena__for_cubesat_.html?gid=sg85851 or http://www.ponoko.com/design-your-own/products/2-4-ghz-antena-for-cudesat--6245
2.4Ghz band is actually a junk band but according FCC ((http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&tpl=/ecfrbrowse/Title47/47cfr15_main_02.tpl ) and in Canada http://www.ic.gc.ca/eic/site/smt-gst.nsf/vwapj/rss210-issue7.pdf/$FILE/rss210-issue7.pdf it is possible without license to use 4wt (Canada) and in 1wt (USA) transmitters (assuming BlueTooth as a core), without limitation on antennas. For local noise cancellation microchip is: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=QHX220IQT7CT-ND According spec >20dB noise cancellation possible. Manually (which is proved and possible) for ground station can be achievable 50dB noise (junk) suppression.
Also was discussed the same technique for suppress noise on a transmitter – transmitter antenna on satellite oriented to the point on the earth at the same time noise helical antenna looks backward 180 degree. Second (noise) antenna needs to be with receiving pattern covering the same sky area as a ground antenna (this depend on a orbit, otherwise needs mechanical adjustment). Mixing delayed (61.3mm) noise on 2.4Ghz from a particular place on a sky with a transmitting signal, then subtracting same noise on receiver can give ~50+20=70 dB which will be good as it sounds. Complications: see more on: http://www.adobri.com/ProjectCr.aspx
ON SEPTEMBER 06, 2011 06:04 PM Communication protocol nightmares
Communication protocol changes. Unit must be capable to support serial and I2C multi-master protocol in different configuration. Unit interfacing “serial device” needs to relay received and transmitted data from “serial device” to another unit via I2C. Units interfacing “I2C devices” needs to relay received / transmitted data via serial. All serial units linked each other into a ring. Serial out of each unit connects to serial in of a next unit. Propagation delay (in transfer data from unit N to unit K will depend on an amount of units btw N and K. Serial communication speed - 56K/s, I2C around 200-300Kbit/s. Un-standard speed for serial can be set to 100Kbit/s, but temperature instability can reduce speed back to 56-32k. Each unit can change speed of communication. On master reset serial speed is 9600. Each unit on “power-on” transfer over serial loop sends greetings message. Traveling over the loop this message ended up at originated unit and loops functionality verified. Main processor unit can monitor traffic and detect all functional units. The same technique of traffic monitoring can be useful to avoid re-transition the same data. I.e. “Camera unit” send data to a “memory” unit at the same time main processor grab data for IKV processing and/or “24Ghz communication” unit can relay packages from “Camera unit” to “memory” with retransmitting same packages to ground station.
More scary etc. on http://www.adobri.com/ProjectComm.aspx
ON SEPTEMBER 13, 2011 10:52 AM Trajectory calculations. Keplers elements. Pt 1.
ON SEPTEMBER 19, 2011 05:29 PM Avionics – Communication protocol, memory storage, Camera, Gyro, Stepper motors.
Supporting commands for transport layer reduced to 3:
1) '~' serial communication loop is functional.
2) '=XCI' retransmit data
For unit allocated 3 queue – one for serial input, another for I2C input, and third for output (output can be serial or I2C, but output queue is only one). Command “=XCI” force input from serial to be transmitted to unit ‘X’ with command ‘C’ over I2C line. Command “=XCc” force input from I2C to be transmitted over serial output to unit ‘X’ with command ‘C’. CMD ‘C’ can be set as ‘ ‘ (space) this will skip inserting command into a retransmission. The same correct for a ‘X’ unit address for retransmission – setting ‘ ‘ (space) will force retransmit but without sending unit address. This is convenient to retransmit data from memory storage over I2C to any unit. When received command ‘<’'<'I2Caddr'>''<'data'>'[‘>’'<'bytes-to-read'>'@ ] this force retransmit data over I2C to device with I2Caddr. Placing ‘>’ at the end of the command with force I2C set Stop-Start condition and read response data from I2C device.
For command/stream handling used 3 callback functions. Call back Function called in a serial->I2C (or I2C->serial) retransmit state each time before processing bytes from input queues. Return code allows specify end conditions for retransmission.
Call Back Main calls each time in a loop of processing both input queues. I2C queue has priority over serial. Clock based on 8Mhz internal oscillator and it gives around 30 interrupts per second, seconds accuracy depend only on a stability of a internal oscillator. 29 counts of a 1/30 of a second different from last count – last count adjusted to properly set seconds or termal conditions. For synchronization unit uses MCR. Second timer can be used for setting any wait events.
1.Each unit can accept command from each unit. Each command can produce next commands for any unit. Functionality of each unit independent from other unit. Stream of a commands traveling over serial and I2C supports functionality of a vehicle and craft. Functionality of each unit for craft should be used for vehicle.
2.Protocol layers separated into . . .
See more on http://www.adobri.com/ProjectComm.aspx
ON SEPTEMBER 23, 2011 11:32 AM Speech? – As it is.
ON SEPTEMBER 29, 2011 02:02 PM Boring. Gyro. (Part one. Electronics, and calibration)
ON SEPTEMBER 30, 2011 11:13 AM Boring job of a software engineer. Gyro. Software. Endless calibrations.
ON OCTOBER 11, 2011 03:01 PM Fiasco with Gyro. Hope with magnetic sensor. Power Plant.
Testing gyro was calibrated for range of temperatures, calibrating values 64K of 3x16-bit words was stored in memory. Gyro has fixed in stable position with X axe oriented to a North Star, Y to the West and Z orthogonal to X-Y forward to the Earth’s rotation axe. Drift of a zero was in a range of 5 degree per 256sec (4 minutes). Sensor was forced to max possible sensitivity (undocumented future in ITG-3200, but it gives 1/115=0.009 degree per sec – it still require 10 better sensitivity to detect earth rotation). Sensor set to 296 samples per sec (microprocessor is slow – needs to be at least 32MHz). Zero drift was random (range from 0.01 – 5.0 degree per 4 minutes) and not depend of a derivative of a temperature. Drift was related to an orientation of a gyro, and on a previous gyro’s readings (possible that factory calibration gives drift).
Such drift is totally not acceptable for navigation, needs to eliminate error first. On the Earth or on the Moon it is possible to do this by reading accelerometer and magnetic sensor orientation. Field of gravity is stable on the Earth and the Moon, and magneto sensor readings on the Earth are stable too (for sure to some extend). Reading from accelerometer gives absolute reading. Flying average from accelerometer can give good indication of an absence or existence of rotation and can allow to exterminate gyro’s zero drift.
Normally this is done by Kalman filter, it assuming that absolute direction is for a gravity field and based on that assumption correction to gyro’s readings (speed of a rotation) can be done. Kalman filter works good when noisy measurements done for predictable object. It is nice and well known approach, source code available for such filters including combination of 3-x accelerometer and 3-x magneto sensor. But such approach is not working on the low Earth orbit. Hope is for a magnetic sensors – first needs to calculate flying average of a 3D magnetic field orientation. If flying average during 2 sec (500 samples) is not in moving than current drift of a gyro assumed as a zero.
Then time measured for a slowest changes (derivative of a orientation) gives point on a orbit when satellite crossed equator. Two times btw crossing the equator can give Keplers elements of a orbit. Checking point will be apogee and perigee – direction of a magnetic field at those two points must achieve maximum of a derivative of a direction of a magnetic field. Current position of a magnetic poles will give offset for a final ... see more on ... http://www.adobri.com/ProjectComm.aspx
Solar panels combined in 4 groups. 4 high capacitance capacitors can be charged by any solar panel’s groups . To control such process require 16 pins for a control. Then 4 charged capacitors can give power to 4 main users of a power – (a) backup microprocessor, main electronic including main computer; (b) backup communication; (c) main communication amplifiers; (d) orientation stepper motors/ 2.4GHz antenna deployment. This power distribution require another 16 pins. Power source for main communication amplifier controls by pins on a STM_BT microprocessor. Power source for stepper motors controls by STM_SM microprocessor. Power source for a main electronics controls by STM_MEM microprocessor.
Assumed 3 different mode of power operation.
- Initially first capacitor gives power to STM_MEM module. When it powered up it can monitor state of any 4 capacitors and switch itself power source to any of it. At this point all onboard electronics and users are switched off.
- Then at a time when it is enough power accumulated by power plant STM_MEM can go to second mode - powered backup communication module, gyro module, camera module, stepper motors/orientation module, main communication module. Each of the modules on a request from command stream from STM_MEM can initiate ... See more on ... http://www.adobri.com/ProjectCr.aspx and http://www.adobri.com/ProjectComm.aspx
ON OCTOBER 17, 2011 12:47 PM PLAN (Path of Learning Almost Non-predictable).
Ok – this is a deal – lets assumes – (a) power plant on satellite has 6 surface – each 2 of it can be assumed parallel, looking in opposite direction with solar panel attached, that makes 3 groups by 2, each group orthogonal each other; (b) gyro precession is 1 degree per 4 minutes; (c) magnetometer gives readings (absolute) of a magnetic field with precession 2 degree. First step will be to stabilize satellite (eliminate rotation) to a level 0.5 degree per hour. It can be done by monitoring readings from a solar panels and do correction by rotating stepper motors. Then after 4-5 hours when error is less then 0.5 degree (per hour) magnetometer readings will be prerecorded during two orbits. This gives 2x3x75x75x2 ~ less 100K of data. Data analyzed for min and max of derivative and chunks of data with max and min values can be transferred by backup communication (not require orientation of a craft) to earth control center (~10K of data). On the ground center simulation program of a magnetic field on a low earth orbit will match (by brutal computer run) observed readings with approximated Keplers elements. Basically it will try all possible Keplers elements and find best match for observation reading. When Kepler’s found then for a time equal ½ hour before next communication session can be generated magnetic fields readings which craft has to follow for a proper orientation in a time of beginning of the session. When session will starts, gyro with precession 1 degree per 4 minutes (session time) can orient satellite to perform session. Ground station antenna will use the same logic for orientation with assumption that earth rotates 360 per 24 hours, coordinates and direction to a north magnetic pole can be reliably verified. The picture taken by camera fixed to the craft frame using the same method of orientation (30 minutes of prior picture session) can confirm precision of a method. The same technique will be used to orient craft for a main impulse on a way to the moon, in this case max 160 minutes of predicted magnetic field values needs to be downloaded. More complicated procedure on a way to the moon (travel time 7-9 days) for correction impulses – lets assume the orientation of a magnetic field in each point of trajectory will be stable during at least 1 hour. Direction to the moon and earth can be preloaded, then using gyro it is possible to orient craft’s camera (fixed to a frame) to estimated direction to centers of the earth and the moon. Picture can be taken and gyro will return craft back to the orientation before picture session with precision 0.25 degree (basically this mean picture has to be taken in a intervals of 1 minutes). Then magnetometer’s readings can be used to stabilized previous (before session) direction. Solar plant will give another vector for orientation to the sun. Two picture can be processed on board to get direction to the center of the earth and the moon. And calculated earth’s direction can be used for communication session. On correction impulse it has to confirm (by picture) direction to the earth, the moon, the orientation of a magnetic field and using gyro (1 min) before impulse . . . see more on http://www.adobri.com/ProjectCr.aspx
ON OCTOBER 25, 2011 12:12 PM Report for my friend Shura. (With promises to translate to English later).
Саня, докладаю - ситуевина значит такая – магнитометр == позавчера - получил от него наконецто точность в 0.3 градуса - могу теперь эту точность повышать практически до бесконечного нуля - в магнитометре конечно присутствует ошибка связанная с неравномерностью замера силы магнитного поля (полля!) по осям – но эту ошибку приготовился исправлять с помощью калибровки - на листе бумаги нарисовал углы - прискотчил прибор к детскому деревянному кубику с люминевой линейкой, замеряю по трем осям и прямиком в таблицу.
Магнитометр позволил определить широту Ванкувера по наклону магнитного поля - вчера для моего колченогого стола 18.1 градус совпали прекрасно.
Модель магнитного поля простая - синус - косинус и уж непомню где, но пополам . Загрузил вчера 1977 года фортрановские программы Николая Циганкова - он сделал достаточно точную модель магнитного поля земли - включая солнечный ветер на больших расстояниях от земли. Нужно будет переводить код в Си для моделирования - займет конечно временя - не меньше недели.
По поводу гироскопа - незакончил - неделю назад понял что нужно делать (или думаю что понял)- после проверок точности магнитометра буду с софтвером так - 2 секунды полета == 16 км - за две секунды магнитное поле уйдет на 0.3 градуса - та же точность будет у магнитометра - за одну секунду 0.3, (за две будет гдето 0.15-0.2) - т.е. порог замера. Затем гироскоп считывает по уже существующей температурной калибровке и получаю- (а) гироскоповские углы (бэ) магнетометоровские углы (цэ) гиро за 2 секунды (дэ) магнитометр за две сукунды - (а) и (бэ) плывут друг от друга как труба им на душу положит. Но если магнитометр покажет (дэ) меньше 0.3 по всем осям - значит (це) это ошибка - которую и принимаем в какчестве корректировки. На своем микрочипе в 500 байов памяти прекрасно могу сделать (цэ) и (дэ) плавющими без потери точности -2000 замеров == всего лишь 32К - деление как в школе по логарифмам - арктангенс из квадратного корня по таблице брадиса (разов 100 быстрее) - коррекция осей магнитометра в ней же - даже думаю в доллар 20 умесчюсь (1МБ), если нет - то доллар 81 пойдет (4МБ). Может придется делать температурную калибровку гироскопа по каждой оси отдельно (перпендикулярно земле).
Разница в гироскопе для луного трактора - вместо магнитометра беру акселерометр и весь софтвер тот же.
Разница в гироскопе для наземной станции – никакой (моожно конечно испоользовать магнитометр для эффектного фокуса – демонстрировать вращение земли на обрудовании неспособном такое вращение детектировать – но это лишнее).
Думал что теряю вермя - затем заглянул в книгу Бориса Чертока – все теже мои проблемы - гироскоп - его питание – спалили прибор при тестирвании - отсутствие телеметрии вне наземной станции - ориентировка по солнцу земле луне - гироскопу дали недостаточно времени на раскрутку, земля попала в край картинки. С четырнадцатого раза только удалось все правильно сделать.
ON NOVEMBER 03, 2011 02:35 PM Report to my friend Shura (Alex). (Translation as it was promised)
Ok Alex - this is a situation – the magnetometer – yesterday (all my troubles seemed so far away…) got from it accuracy 0.3 degree with capability to increase accuracy to any desired precision (first luck in last month). For sure in the magnetometer exists error related to a different measurements on different axis, but this error can be corrected by calibration, on big paper sheet I just marked angles – taped magnetometer to a wooden cube (yes, I am still playing with a wooden cubes – the are not magnetic) with long aluminum ruler, do measurement on each axis and corrections hammered directly into a (flash memory) table.
Magnetometer allowed to confirm (surprise!) latitude of aVancouver– yesterday on my uneven table 18.1 degrees matched perfectly (angle btw horizon and direction of a magnetic field’s vector).
Model of a (earth) magnetic field is simple – some cos() – sin() functions and somewhere (already forget where – in saved spreadsheet) something divided in half. Loaded yesterday (year 1977) FORTRAN’s programs by Nikolai Tzigankov. He made nice model of Earth magnetic field including influence of a solar wind on far distances from the earth. Needs to convert code to C, and adapt it to my simulator/tra-calculator. This for sure will take a time (no less a week), conversion takes no longer then hour(s), but needs to be careful with default names of integer/float variables, and mostly time spend on each line verification.
About “gyro navigation device” == “my shame” == “not finished” – one week ago understood what needs to do (or may be just foolish-ing myself that understood) – after magnetometer calibrations and implementing (magnetic) model plan-b for software == 2 second on a orbit == 16 km == vector of a magnetic field can change 0.3 degree – the same error will be in the magnetometer – for one second confirmed error is 0.3 (for 2 seconds it will be 0.15-0.2 degree ), then gyro’s readings corrected by temperature calibration, that will give: (a) gyro angles, (b) magnetometers angles, (c) difference in angles by gyro, (d) difference in angles by magnetometer. (a) + (b) flying independently against each other, but if (d) is less 0.3 on all axis then (c) is a correction’s value. On my microprocessor with 500 bytes can be perfectly implemented (c) and (d) without losing single bit – 2000 readings == 32K, dividing (like in a school) by logarithms and arctan(sqrt()) from Bradis table (school’s technology proved faster 100 times). Correction on magnetometer axis’s readings is in flash table too. I think it can be fit into 1MB (1.20$). if (not) then 1.81$ (4MB) will be suitable;
Difference in gyro implementation for rover – instead of a magnetometer it will be accelerometer – all software is the same.
Difference in gyro implementation for a ground station == zero (it is possible to use magnetometer + gyro + accelerometer to demonstrate effective trick == detection of earth rotation with a device totally not capable to so – trick will be nice but it is extra == does not worth spend time on it).
I thought that I was loosing time (and time is not my friend for today), but after careful examination Boris Chertok’s book I found that story about Luna9 has had similar problems/questions – 1 second (1/60 degree) error == 200km error on the moon, gyro, not enough power for a gyro, burned devices at tests, power station does not work, absence of telemetry out of a ground stations, orientation using sun-earth-moon, gyro does not get enough time to reach precision because of a power limitation, earth’s image was on a corner of sensor, failed deadlines, lost money and etc. One of a sample “bug” reported by Boris – after lost probe was found that one department (hundreds of people assigned to do trajectory calculation) understood “clockwise” direction totally opposite the understanding by another department. Only 14th attempt was successful.
ON NOVEMBER 15, 2011 12:53 PM J2 coefficient. Earth is flat. Isn’t it?
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.
ON NOVEMBER 21, 2011 01:14 PM RFM
When you meet your physics teacher 30 years after the school, and old man told that he dose 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 =
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)
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.
ON DECEMBER 14, 2011 11:56 AM Boris Chertok
14/12/2011, at age 100, passed away Boris Chertok. Our condolences to family. For space community Boris was un-replaceable. Boris Chertok’s books was inspiration for all development in Team Plan B.
На 100 году жизни скончался Борис Черток. Наши соболезнования семье. Вклад Бориса Чектока в космонавтику невозможно оценить обычнмым способом. Влияние его честных, точных, инженерых книг на космонавтику еще будет оценено будущими поколениями космического сообщества.
Team Plab B.
ON DECEMBER 25, 2011 10:37 PM Forging CubeSat.
ON DECEMBER 26, 2011 05:27 AM CubeSat discussions (electronics)
ON DECEMBER 26, 2011 03:52 PM CubeSat manufacturing.
ON DECEMBER 27, 2011 02:11 PM CubeSat component's discussion.
ON DECEMBER 28, 2011 11:41 AM CubeSat, two plungers, one pin.
ON DECEMBER 29, 2011 01:07 AM CubeSat, zero-point-zero-one-mm
ON DECEMBER 30, 2011 02:17 AM CubeSat, required precision, discussions.