Last night’s orbit correction manoeuvre ran as expected, with nominal completion at 23:00 CEST (21:00 UTC).
The thruster burn got underway as scheduled at 16:21:58 CEST (14:21:58 UTC) and ran for 6hrs:39mins, about 2 minutes less than planned but well within margins. About 190 kg of fuel was used.
The manoeuvre was triggered automatically by a command stack that had been uploaded on Tuesday. Engineers were able to monitor the event in real time via ESA’s 35m deep-space antenna at New Norcia, Australia.
The Rosetta flight control team can’t say what the precise results were in terms of actual delta-v delivered until Flight Dynamics here at ESOC do a review and orbit determination, which takes a day or so, but if a burn runs for anywhere close to the planned time, then we know it went more or less OK – as it did (see note below).
Next OCM is planned for 18 June; details to follow.
Note: In fact, this variability in the actual thrust delivered versus what’s planned is one of the reasons why the required orbit corrections are being done in a series of smaller burns. Any variation in one burn can be made up in the next, helping the entire process to be more efficient and optimise the use of fuel.
Discussion: 11 comments
Welldone guys…..
We were all waiting for the status !!!
Question : how much time is needed for the control team to check the new speed and position of the object ?
Could anyone explain how this speed is measured from earth ?
Serge/
Doppler I suppose. If the frequency of the telemetry signals indicate shifted down from previous then they would know that Rosetta has slowed as desired. Of course I’m stating what’s obvious to me as a layman! It makes sense to my mind anyway! It’s how would do it!
Great achievement! Very interesting to witness the closing to 67P.
To make it even cooler: why not making the telemetry data available once it comes in?!?! The data is in your computer system, so publishing it on a dedicated website is only a small step then.
That enables us to witness these great moments in real-time!
As an example: see https://spacestationlive.nasa.gov/displays/index.html showing the telemetry of the ISS. Clicking SPARTAN shows all the solarpanel data.
I guess this should be possible for all spacecraft, right?
Hi Serge, it will take a day or so to be sure of the exact change in DeltaV .
The velocity of Rosetta can be measured by the change, or Doppler changes in the radio frequency from Rosetta to Earth, also using the NavCams and OSIRIS cameras, the position of the target comet in this case 64/P Churyumov-Garasimenko (think I have spelt it correctly) with respect to the background stars at regular intervals, intervals between Rosetta being sent a signal and waiting for the response at regular intervals, position of Rosetta within the Sun’s gravity well with respect to Earth, usage of fuel for course corrections ( the current series of OCMs being prime examples). All of these can determine the velocity of Rosetta with respect to Earth.
Andrew.
The views from here are not good as I am double parked in a parallel universe. May the farce be with you
So why did the burn run for a shorter time than planned? A very naive view of things would be that turning the thrusters on and off at the planned times should be easy. But that’s a simplistic view on the burns, I doubt the actual reason was that you had a 2 minute error on your timer for turning off the thrusters, so why did it run for 2 minutes less than planned?
Hope the rest of the burns goes well!
That’s because the orbit correction is not commanded to the spacecraft as a thrust duration, but either as an impulse (in Newton.seconds) or as a deltaV (in m/s).
So you don’t ask the spacecraft to switch on and off the thrusters at a given time, but you ask it to perform an orbit correction of a given amplitude (and direction) at a given time.
The planned duration (6H41) is the predicted duration needed to achieve the requested orbit correction.
There is some source of error in this prediction (mostly due to the variability of thrusters performances)
The resulting error (2 minutes out of 6H41) corresponds to a relative error of 0.5%, which seems pretty good.
Ah, yeah, I didn’t mean to imply that it was a major error, just that I was intrested in knowing what the reason was. I feel a bit dumb for not even considering the fact that the burn could be commanded as an impulse/deltaV change and that it then would be the reason for the difference. Oh well.
Thanks for the answer!
Daniel, thanks for the question. I think it was a good one. 🙂
Next question that comes to mind is how the spacecraft determines the achieved deltaV in a timely manner. How often does it perform this action? It can’t know the actual thrusters impulse better than its inventors can. Or can it?
Immediately after completion of the burn, the Flight Control Team can see telemetry (on-board status information) that says, in effect, ‘The burn ran for more or less the correct length of time’ — therefore, we know that the needed/planed delta-v was achieved more or less correctly. It takes a few days to get a precise calculation of the delta-v actually achieved because this is based on the next orbit determination done by the Flight Dynamics team, and this takes some time to obtain the data and do the calculations.
On Mars/Vexu Express, I know the spacecraft has an accelerometer: it can integrate the measured acceleration and stop the burn after the required deltaV is reached. However, there are measurement errors, so real deltaV will be different.
Rosetta is based on the MEX/VEX design, however, I don’t know if it has an accelerometer (I don’t/didn’t work on any of these missions).
Most spacecraft don’t have accelerometers and you command a total impulse to be achieved. You are right that the spacecraft does not know better than ground the real force produced by each thruster, so you could think that the impulse is simply the product of assumed force and thrust time.
The reason it’s not like that is that the thrusters are off-modulated to control the attitude of the satellite. This means the real thrust duration is longer than total impulse divided by assumed force.
This is the normal way of controlling spacecraft in thrust-based mode, so I’m sure you’ll find plenty of on-line explanations and papers if you look for “AOCS” and “off-modulation”.