5 ms·

Question for someone who knows more about satellites than me: > In satellites, the STT typically gets a good fix and sends the data to the IRU. The IRU uses th

Question for someone who knows more about satellites than me: > In satellites, the STT typically gets a good fix and sends the data to the IRU. The IRU uses the data to set its current reading and to measure how far it drifted since the last update. After calculating the drift it uses drift adjustments to compensate for the future drift. Clearly if the compensation calculation is wrong the future readings are going to be wrong. This appears to have played a role since the ACS attempted to correct a rotation that didn’t exist. The erroneous configuration information led the ACS to aggravate, not correct, the rotation. Does this mean that error will compound if either the attitude or compensation are calculated or performed incorrectly? If so, is there a way to reduce that compounding, perhaps by making them more independent systems? Or am I reading too much into a summary? (And, you know, space is hard.)

walrus01 10y ago
There are satellite that use the STT system almost entirely independently of all other systems. Particularly ones that need to remain in a certain orientation for 100% of their service life, such as geostationary telecom and weather satellites that orbit along the equator and are always aimed towards the visible hemisphere of earth. On those, the directional hemisphere and spot beam antennas are fixed in place (or can only move a few degrees motion at best, such as Ku band spot beam antennas), relying on the body orientation of the satellite to service a certain area of the visible hemisphere. Satellites are designed to go into "safe mode" if certain fault protection events happen, or the multiply redundant control systems/onboard computers don't agree with each other. Safe mode usually means shutting down all nonessential electrical loads and trying to orient themselves so that solar panels receive the greatest amount of charge, while listening for command and control data on their omni (L and S band) TT&C antennas. With this event it sounds like something REALLY went wrong since not only did the satellite try to correct a nonexistant wrong orientation via its reaction wheels (reaction wheels are not nearly as powerful in real life as they are in kerbal space program), it then decided to start expending propellant and spun itself up to such a RPM of revolutions that it tore off its own solar panels, and anything else that would be vulnerable to high centrifugal G forces. Automated code that expends propellant is usually checked much more carefully than this, since the amount of propellant is fixed and non renewable, usually the primary constraint on the total service life of the satellite. Most satellites run out of stationkeeping/orientation propellant (or propellant for ion engine delta-V changes) long before their multiply redundant solar/charge controller/battery/computer control systems fail.
drostie 10y ago
The way I read it, the bug is something like this: There are three components, one is a Controller which goes out into the world and calculates how we're oriented, the second is basically just a Model in the MVC sense (the IRU). The first Controller has a responsibility to update the Model with whatever it finds out. The third component is a separate part of the IRU which is essentially both a view on the model (where am I pointed, where am I supposed to be pointed?) combined with a controller which fires some thrusters to try to point you in the right direction. The problem was that the first component wasn't updating the model. Therefore the second component set "fireThruster1: true," but then never got any information that it was approaching the right direction -- therefore kept that variable set. The thruster continuously fired, spinning the satellite around and around until it was ripped apart by centrifugal forces.
2PetitsVerres 10y ago
> Does this mean that error will compound if either the attitude or compensation are calculated or performed incorrectly? If so, is there a way to reduce that compounding, perhaps by making them more independent systems? It's more the opposite. (well, not quite exactly the opposite, but I'll try to explain. It's a simplified explanation, I hope I didn't make any obvious error in the simplification) IRU is mainly composed of gyroscope, measuring the spacecraft angular rate over three axis. They don't give you the absolute orientation. Of course, if you know the initial orientation, you could integrate angular rotation and have the current one. Except that in reality, you have several problems. The first one is that even if you have a perfect unbiased gyro, you need a continuous time integration, and not use sample every 0.X seconds. But the main problem of gyro are the instantaneous bias, and the slow change in bias over time. And when you integrate bias over a long time, the result diverge (all the type of gyroscope have these, but the level are different. There is also added noise on top and quantisation of the output. You get value over 8, 12 or 16 bits, not a real number. But integrating this should average to 0, so that's ok) So you can't use only an IRU. Could you use only a star tracker? Again, in an ideal world, yes. The star tracker gives you the absolute orientation and if you want the angular rate, you can get it by derivation (by differentiating, in discrete time) But the star tracker has its own problem. It cannot gives you an orientation when you turn it on, it has an acquisition phase first. It does not work when you have the sun in the field of view, or the earth, and sometimes also the moon. (it's basically a camera trying to take picture of the stars.Plus a lot of complicated software) As it includes a lot of complicated software, you don't necessarily want to use it in safe mode (software has bug. Also it uses electrical power) Sometime STT don't work when the rotation speed is too high also. And complexity also means more failure modes. So STT only for all phases, including safe mode, if often not accepted by the system engineer/the satellite final client/the quality assurance department/... (sometimes its just not possible) So what is usually done on satellite including both an IRU and a STT is to blend their data together. That gives you an accurate position (coming from the STT when it is ok, or by integrating the IRU data for "short" period when you get the sun in the field of view, for example), an estimation of the (current) gyro bias, and an accurate rotation rate (by using the IRU data minus the estimated bias)(this is usually based on a (extended) Kalman filter, but there are probably other methods) With all this, you actually get a better attitude and rotation rate than IRU or STT alone. (when going in safe mode, you will probably switch to an attitude estimation based on IRU and some inaccurate but really simple sun sensor. Safe mode usually only wants to point some satellite axis to the sun with a bad accuracy, up to a few degree) When everything works fine, it's nice. But according to what they say, it seems that they have got an error in the algorithm (or some specific bug triggered by some strange sequence). There was the Earth in the field of view of the STT (so it was unavailable), then it has been to acquisition mode (no usable data), the tracking mode (data is good). At this point, there is a huge gap in the bias estimation (this kind of stuff happens when you re initiate a filter, or when conditions change), it's supposed to converge relatively fast to the good value (with "fast" being dependent on your algorithm). But during this convergence phase, they think that the STT did go back to acquisition mode. (for some reason, not completely clear). The estimated bias had a relatively high value (21 deg/h. Big for a bias), not corresponding to the real bias. But the satellite has keep using this value, until it finally reached safe mode. It's not clear if it continued to use this bias value in safe mode, but it does not really matter (21 deg/h bias is not that big when you start using thrusters. It may use more fuel than needed but that's 0.3 deg/s. Relatively small). An error in other data uploaded in the software had basically transformed the safe mode to a kill mode (from what I understand, any transition to safe would have been extremely bad)

walrus01 10y ago

There are satellite that use the STT system almost entirely independently of all other systems. Particularly ones that need to remain in a certain orientation for 100% of their service life, such as geostationary telecom and weather satellites that orbit along the equator and are always aimed towards the visible hemisphere of earth. On those, the directional hemisphere and spot beam antennas are fixed in place (or can only move a few degrees motion at best, such as Ku band spot beam antennas), relying on the body orientation of the satellite to service a certain area of the visible hemisphere. Satellites are designed to go into "safe mode" if certain fault protection events happen, or the multiply redundant control systems/onboard computers don't agree with each other. Safe mode usually means shutting down all nonessential electrical loads and trying to orient themselves so that solar panels receive the greatest amount of charge, while listening for command and control data on their omni (L and S band) TT&C antennas. With this event it sounds like something REALLY went wrong since not only did the satellite try to correct a nonexistant wrong orientation via its reaction wheels (reaction wheels are not nearly as powerful in real life as they are in kerbal space program), it then decided to start expending propellant and spun itself up to such a RPM of revolutions that it tore off its own solar panels, and anything else that would be vulnerable to high centrifugal G forces. Automated code that expends propellant is usually checked much more carefully than this, since the amount of propellant is fixed and non renewable, usually the primary constraint on the total service life of the satellite. Most satellites run out of stationkeeping/orientation propellant (or propellant for ion engine delta-V changes) long before their multiply redundant solar/charge controller/battery/computer control systems fail.

drostie 10y ago

The way I read it, the bug is something like this: There are three components, one is a Controller which goes out into the world and calculates how we're oriented, the second is basically just a Model in the MVC sense (the IRU). The first Controller has a responsibility to update the Model with whatever it finds out. The third component is a separate part of the IRU which is essentially both a view on the model (where am I pointed, where am I supposed to be pointed?) combined with a controller which fires some thrusters to try to point you in the right direction. The problem was that the first component wasn't updating the model. Therefore the second component set "fireThruster1: true," but then never got any information that it was approaching the right direction -- therefore kept that variable set. The thruster continuously fired, spinning the satellite around and around until it was ripped apart by centrifugal forces.

2PetitsVerres 10y ago

> Does this mean that error will compound if either the attitude or compensation are calculated or performed incorrectly? If so, is there a way to reduce that compounding, perhaps by making them more independent systems? It's more the opposite. (well, not quite exactly the opposite, but I'll try to explain. It's a simplified explanation, I hope I didn't make any obvious error in the simplification) IRU is mainly composed of gyroscope, measuring the spacecraft angular rate over three axis. They don't give you the absolute orientation. Of course, if you know the initial orientation, you could integrate angular rotation and have the current one. Except that in reality, you have several problems. The first one is that even if you have a perfect unbiased gyro, you need a continuous time integration, and not use sample every 0.X seconds. But the main problem of gyro are the instantaneous bias, and the slow change in bias over time. And when you integrate bias over a long time, the result diverge (all the type of gyroscope have these, but the level are different. There is also added noise on top and quantisation of the output. You get value over 8, 12 or 16 bits, not a real number. But integrating this should average to 0, so that's ok) So you can't use only an IRU. Could you use only a star tracker? Again, in an ideal world, yes. The star tracker gives you the absolute orientation and if you want the angular rate, you can get it by derivation (by differentiating, in discrete time) But the star tracker has its own problem. It cannot gives you an orientation when you turn it on, it has an acquisition phase first. It does not work when you have the sun in the field of view, or the earth, and sometimes also the moon. (it's basically a camera trying to take picture of the stars.Plus a lot of complicated software) As it includes a lot of complicated software, you don't necessarily want to use it in safe mode (software has bug. Also it uses electrical power) Sometime STT don't work when the rotation speed is too high also. And complexity also means more failure modes. So STT only for all phases, including safe mode, if often not accepted by the system engineer/the satellite final client/the quality assurance department/... (sometimes its just not possible) So what is usually done on satellite including both an IRU and a STT is to blend their data together. That gives you an accurate position (coming from the STT when it is ok, or by integrating the IRU data for "short" period when you get the sun in the field of view, for example), an estimation of the (current) gyro bias, and an accurate rotation rate (by using the IRU data minus the estimated bias)(this is usually based on a (extended) Kalman filter, but there are probably other methods) With all this, you actually get a better attitude and rotation rate than IRU or STT alone. (when going in safe mode, you will probably switch to an attitude estimation based on IRU and some inaccurate but really simple sun sensor. Safe mode usually only wants to point some satellite axis to the sun with a bad accuracy, up to a few degree) When everything works fine, it's nice. But according to what they say, it seems that they have got an error in the algorithm (or some specific bug triggered by some strange sequence). There was the Earth in the field of view of the STT (so it was unavailable), then it has been to acquisition mode (no usable data), the tracking mode (data is good). At this point, there is a huge gap in the bias estimation (this kind of stuff happens when you re initiate a filter, or when conditions change), it's supposed to converge relatively fast to the good value (with "fast" being dependent on your algorithm). But during this convergence phase, they think that the STT did go back to acquisition mode. (for some reason, not completely clear). The estimated bias had a relatively high value (21 deg/h. Big for a bias), not corresponding to the real bias. But the satellite has keep using this value, until it finally reached safe mode. It's not clear if it continued to use this bias value in safe mode, but it does not really matter (21 deg/h bias is not that big when you start using thrusters. It may use more fuel than needed but that's 0.3 deg/s. Relatively small). An error in other data uploaded in the software had basically transformed the safe mode to a kill mode (from what I understand, any transition to safe would have been extremely bad)