The latest from Ria Novasti: Phobos Grunt could be sent into lunar orbit if communications are restored, and if Phobos Grunt reenters all the pieces would disintegrate.
Google translated:
http://tinyurl.com/bql688g
The velocity vectors at perigee and apogee are at right angles to each other, so the force would have to act in different directions.
Simply not true. Velocity vectors at perogee and apogee are in fact parallel.
Ouch. You are right, of course. Must have had a right angle in my spatial thinking circuits ...
The latest from Ria Novasti: Phobos Grunt could be sent into lunar orbit if communications are restored, and if Phobos Grunt reenters all the pieces would disintegrate.
Google translated: http://tinyurl.com/bql688g
I suppose they can spin it declaring scientific
innovation (that's a political word now) saving the mission.
What would that really accomplish? Can it actually land on the moon? Can the sample returner escape moon gravity? Is there a camera available to take a look around? Might the Chinese satellite be placed in lunar orbit?
These machines are designed for a specific mission. If there is some flexibility, maybe the moon is marginality better than zero return.
--- CHAS
So you would have as much chance as the President of the United States and the four Beatles performing the rescue mission themselves as you would being able to launch this so-called rescue mission during the current launch window.
I know enough math to see that there's something fishy about your answer: You have overestimated the number of available Beatles by an order of magnitude assuming the use of base two. Ahem.
But I did totally forget that the Hubble rescue for example, was a carefully planned mission, not a dash. So thanks for taking the time to answer.
I agree it may not be the most likely, but I don't think we can exclude some sort of loop, even if it isn't the prime mover in this failure. It needn't be a loop in the "10 PRINT "HELLO" 20 GOTO 10" mold, it could be a more complex behavior emerging from otherwise well intentioned code. What follows is rampant speculation and imagination:
{snip}
The loop is more likely to be
5000 WAIT 0.1 * SECONDS
5010 GET #SUN_SENSOR LOCATION
5020 IF LOCATION = NO_RESPONSE THEN GOTO 5000
Although probably written in C, ADA or FORTRAN.
Regarding the possibility of debris survival to Earth's surface, I remind readers of Paul Maley's overview of the subject here:
http://www.eclipsetours.com/sat/debris.htmlAs Paul writes, it's rare but does happen -- and propellant tanks are among the most common elements that are found.
Regarding the possibility of debris survival to Earth's surface, I remind readers of Paul Maley's overview of the subject here:
http://www.eclipsetours.com/sat/debris.html
As Paul writes, it's rare but does happen -- and propellant tanks are among the most common elements that are found.
Very interesting article. Hmmm, plenty of spheres on Phobos-Grunt!
I agree it may not be the most likely, but I don't think we can exclude some sort of loop, even if it isn't the prime mover in this failure. It needn't be a loop in the "10 PRINT "HELLO" 20 GOTO 10" mold, it could be a more complex behavior emerging from otherwise well intentioned code. What follows is rampant speculation and imagination:
{snip}
The loop is more likely to be
5000 WAIT 0.1 * SECONDS
5010 GET #SUN_SENSOR LOCATION
5020 IF LOCATION = NO_RESPONSE THEN GOTO 5000
Although probably written in C, ADA or FORTRAN.
Or it might have been coded correctly. We have no data to suggest either way and no reasonable basis for what you are suggesting. Also what you are suggesting is something any realtime operating system would not allow to occur and turn into a system hang-up. We also still have no data to suggest a software problem occurred with more data leaning towards a hardware issue (remember the attitude control software is apparently still working).
Also I'll remind you that no real programmer uses Goto statements anymore except for assembler language programming and then for branches to labels (never numbers). Goto statements cause programs to fail and haven't been used for professional programming since the early 1970s.
So, while it may be "fun" to speculate that they couldn't program any better than an average six year old, there is no basis for it and someone reading this is going to believe that there is data to support what you wrote when there is none.
Andy
Comga contacted me by email and helped to explain what is happening.
I'm working this out by myself for the first time so of course I may have missed out something. Thinking about it some more, Comga is absolutely right. We wait until the orbital plane of PG precesses such that the orbit relative to the ecliptic is in the right position (looking at the Earth with the Sun to the left and Earth in front, that is in the same direction as Earth's rotation around the Sun, PG's orbital plane needs to be edge on). When PG reaches this, it fires its engine to send it on a hyperbolic trajectory. The asymptotic trajectory will then be parallel to the Earth velocity vector.
So this means we only need to wait 30 days for the next firing opportunity. Actually, if the 6° per day is relative to the stars and as we want PG in the right plane relative to the Sun, this means the sun-relative precession is 6+360/365.25 = 7° per day. This means we need to wait 180°/7 = 25.7 days, which would be around 4 December.
Attached is diagram showing what is happening. I've shown Earth as if it was in the middle of northern hemisphere Winter, which is not correct and so the angles of the PG planes will be different to that shown, but the conclusion is still the same. That is, the inclination of PG's plane (as long as its edge on) does not affect the exit velocity, which remains the same. This also means that PG does have a TMI opportunity around 4 December.
According to your diagram, on or about November 21st Phobos-Grunt will be in a polar orbit. We know that’s not true, so the diagram does not capture the actual situation.
The inclination (the angle between the equator and the plane of the PG orbit) doesn’t change. The orientation of the plane of the PG orbit in inertial space is changing.
I believe what you need is a diagram viewed from above the sun. Earth and Mars are moving counterclockwise and the plane of the PG orbit is rotating clockwise. When will the plane of the PG orbit again be tangent to the Earth’s orbit?
I think the seven degrees per day is correct, so December 4th looks about right.
More analysis from Ted Molczan:
http://www.satobs.org/seesat/Nov-2011/0214.htmlThe unusual evolution of the orbit of Fobos-Grunt (11065A / 37872) continued through 2011 Nov 18 UTC.
[snip]
A second process (besides drag), is causing F-G's orbit to become more circular, manifested by apogee decreasing and perigee increasing at the same rate (after accounting for drag). A side-effect of this is about a 30 percent increase in the rate of precession of the argument of perigee. The net contraction of the orbit is at about half the rate expected given the object's dimensions and mass. Therefore, it appears that an in-plane force is raising the orbit, and shifting the argument of perigee, negating about half the effect of drag.
[snip]
He's also done considerable work to check the methodology used to get these results.
I agree it may not be the most likely, but I don't think we can exclude some sort of loop, even if it isn't the prime mover in this failure. It needn't be a loop in the "10 PRINT "HELLO" 20 GOTO 10" mold, it could be a more complex behavior emerging from otherwise well intentioned code. What follows is rampant speculation and imagination:
{snip}
The loop is more likely to be
5000 WAIT 0.1 * SECONDS
5010 GET #SUN_SENSOR LOCATION
5020 IF LOCATION = NO_RESPONSE THEN GOTO 5000
Although probably written in C, ADA or FORTRAN.
Or it might have been coded correctly. We have no data to suggest either way and no reasonable basis for what you are suggesting.
Also what you are suggesting is something any realtime operating system would not allow to occur and turn into a system hang-up.
If you believe that you obviously do not know much about real time operating systems. The WAIT will be implemented by a call into the operating system that causes the process to be rescheduled and the watch dog timer reset. This is the classic way of writing a deliberate infinity loop.
We also still have no data to suggest a software problem occurred with more data leaning towards a hardware issue (remember the attitude control software is apparently still working).
Also I'll remind you that no real programmer uses Goto statements anymore except for assembler language programming and then for branches to labels (never numbers). Goto statements cause programs to fail and haven't been used for professional programming since the early 1970s.
BASIC still uses GOTOs.
We had a little training exercise for new programmers - write a structured program only using GOTOs. It stopped them from talking a lot of nonsense. Then if they write WHILE (I == I) {}; they know what they are saying.
I agree it may not be the most likely, but I don't think we can exclude some sort of loop, even if it isn't the prime mover in this failure. It needn't be a loop in the "10 PRINT "HELLO" 20 GOTO 10" mold, it could be a more complex behavior emerging from otherwise well intentioned code. What follows is rampant speculation and imagination:
{snip}
The loop is more likely to be
5000 WAIT 0.1 * SECONDS
5010 GET #SUN_SENSOR LOCATION
5020 IF LOCATION = NO_RESPONSE THEN GOTO 5000
Although probably written in C, ADA or FORTRAN.
Or it might have been coded correctly. We have no data to suggest either way and no reasonable basis for what you are suggesting.
Also what you are suggesting is something any realtime operating system would not allow to occur and turn into a system hang-up.
If you believe that you obviously do not know much about real time operating systems. The WAIT will be implemented by a call into the operating system that causes the process to be rescheduled and the watch dog timer reset. This is the classic way of writing a deliberate infinity loop.
We also still have no data to suggest a software problem occurred with more data leaning towards a hardware issue (remember the attitude control software is apparently still working).
Also I'll remind you that no real programmer uses Goto statements anymore except for assembler language programming and then for branches to labels (never numbers). Goto statements cause programs to fail and haven't been used for professional programming since the early 1970s.
BASIC still uses GOTOs.
We had a little training exercise for new programmers - write a structured program only using GOTOs. It stopped them from talking a lot of nonsense. Then if they write WHILE (I == I) {}; they know what they are saying.
And so...getting back to the point of all this...what evidence do you have this is the scenario on Phobos-Grunt?
And, yes, BASIC has GOTOs. Do you know of any critical real-time systems implemented with BASIC? I don't know of any. Maybe you could enlighten me. It would have to be a compiled BASIC system since no one would use an interpretted BASIC scheme for a critical real time systems.
BASIC still uses GOTOs.
People still use unstructured BASIC in 2011? Really?
Without knowing anything about Fobos-Grunt's avionics, if the software is multithreaded then there's always the possibility of a race condition occurring. Maybe the thread that handles propulsion system burns is running just a little bit faster than the thread that checks to see if it's time to fire the engines, resulting in the probe knowing that it's time to fire but this not being communicated in time to the engines, resulting in the software aborting the burn. Of course, this only makes sense IMO if the "mission planner" thread isn't allowed to preempt/interrupt the "propulsion system" thread, as would be the case in a cooperative multithreading system.
Total speculation, of course.
More analysis from Ted Molczan:
http://www.satobs.org/seesat/Nov-2011/0214.html
The unusual evolution of the orbit of Fobos-Grunt (11065A / 37872) continued through 2011 Nov 18 UTC.
[snip]
A second process (besides drag), is causing F-G's orbit to become more circular, manifested by apogee decreasing and perigee increasing at the same rate (after accounting for drag). A side-effect of this is about a 30 percent increase in the rate of precession of the argument of perigee. The net contraction of the orbit is at about half the rate expected given the object's dimensions and mass. Therefore, it appears that an in-plane force is raising the orbit, and shifting the argument of perigee, negating about half the effect of drag.
[snip]
He's also done considerable work to check the methodology used to get these results.
Assuming the sc is sun-oriented, it seems plausible to me that some form of thrust from a constant direction could be simultaneously raising the perigee and lowering the apogee. I think somebody suggested this already in this thread a few pages back.
Imagine that the force is from a tank venting at the 'back' of the sc. At one point in the orbit, this will be accelerating the sc; at the opposite end it will be deccelerating it. If the thrust is constant, there will be other effects, of course, as the force moves from being tangential towards being perpendicular.
But if it
is a constant source, from a venting tank, how long can it continue for?
But if it is a constant source, from a venting tank, how long can it continue for?
Probably until it enters the atmosphere.
Also what you are suggesting is something any realtime operating system would not allow to occur and turn into a system hang-up. We also still have no data to suggest a software problem occurred with more data leaning towards a hardware issue (remember the attitude control software is apparently still working).
I'll agree that a functioning RTOS shouldn't allow a single routine to grab the entire system and hang everything up (a-la the "Hey, Outlook hung my PC situation that I deal with a couple times a week at work"), thereby preventing an other routine from executing.
But that doesn't mean that you can't have software issues, perhaps even issues that involve an interaction between different software modules or between software modules and the RTOS (if that is even how PG's systems are architected). Or that such an interaction might not be contributing to the overall problem, even if it isn't the "prime mover" that started the whole thing off.
We don't know, we'll probably never know. Heck, I don't think we even know what sort of computer/OS is running this stack. So this IS total speculation.
BASIC still uses GOTOs.
People still use unstructured BASIC in 2011? Really?
Without knowing anything about Fobos-Grunt's avionics, if the software is multithreaded then there's always the possibility of a race condition occurring. Maybe the thread that handles propulsion system burns is running just a little bit faster than the thread that checks to see if it's time to fire the engines, resulting in the probe knowing that it's time to fire but this not being communicated in time to the engines, resulting in the software aborting the burn. Of course, this only makes sense IMO if the "mission planner" thread isn't allowed to preempt/interrupt the "propulsion system" thread, as would be the case in a cooperative multithreading system.
...and that makes sense to me. That's the way I would expect a modern O/S to work.
I still get back to the attitude control system apparently working which implies (no facts, of course) that the processor is still able to schedule tasks and execute them. I'm assuming it's the same processor that would schedule the burn and also perform attitude control, which may not (or may) be the case.
But if it is a constant source, from a venting tank, how long can it continue for?
Ted's looking into just that thing -- see the "Next Steps" section in the SeeSat-L message in the previous posting.
