Apply rotations from Satellite Reference Frame to Local Orbit Frame

[ParisaShafiei]

Dear developers,

I have a question regarding the program called SimulateStarCamera.

Based on the description of this program, it generate rotations from orbit system or satellite frame to CRF. I think, here the assumption is that the orientation of SRF and LOF is the same, but what should I do for a satellite which has several yaw flips during the day?
Indeed, I have these rotations from SRF to LOF alongside the simulated starcamera measurements, but I am not sure where I should apply them in my processing.
Should apply both rotations, i.e. first from SRF to LOF and then from LOF to CRF, in my processing?

Thank in advance for your time and help.
I am looking forward to hearing from you.

With kind regards,
Parisa

[ParisaShafiei]

Hi @tmayerguerr,

Regarding the last question I asked, this is the problem I have

For a CubeSatellite which does several yaw flips per day, I have the attitude files like what you see in the screenshot. These quaternion are to convert spacecraft reference frame to orbit level frame.

My question is if I do not want use simulateStarCamera how I can use these quaternions in processing?

Thank you in advance.

With kind regards,
Parisa

[tmayerguerr]

Hi Parisa,

You must create an GROOPS instrument file from your quaternion file (SRF to orbit system). There is no conversion program in GROOPS for your special format.

As the orbit system is defined in a little bit different (x: along, z: not exact radial) in SimulateStarCamera you must adjust the source code:

    for(UInt i=0; i<orbit.size(); i++)
    {
        Vector3d z = -normalize(orbit.at(i).position);
        Vector3d y = -normalize(crossProduct(orbit.at(i).position, orbit.at(i).velocity));
        Vector3d x = crossProduct(y, z);

        StarCameraEpoch epoch;
        epoch.time   = orbit.at(i).time;
        epoch.rotary = Rotary3d(x, y);
        arc.push_back(epoch);
    }

Afterwards you can combine the two rotations with InstrumentStarCameraMultiply.

regards
Torsten

[ParisaShafiei]

Hi Torsten,

Thanks for your reply. I understood the strategy to apply the rotations from CRF to SRF in my case. I have already managed to get the quaternions (SRF to orbit system) in GROOPS starcamera format.

I modified the source code of simulatestarcamera and by checking the program called "Rorary3d", I came up with this question: Should I also changed the following portion of this program?

The probelm is when I changed the source code and multiply the two starcamera files with InstrumentStarCameraMultiply/html/InstrumentStarCameraMultiply.html), I got very big numbers of RMS and sigma values in the summery of my processing.

Original source code:

// Orthonormalize
x.normalize();
Vector3d z = normalize(crossProduct(x,y));
y = crossProduct(z,x);

field[0][0] = x.x(); field[0][1] = y.x(); field[0][2] = z.x();
field[1][0] = x.y(); field[1][1] = y.y(); field[1][2] = z.y();
field[2][0] = x.z(); field[2][1] = y.z(); field[2][2] = z.z();

---

Thanks in advance and I am looking forward to hearing from you.

With kind regards,
Parisa

[tmayerguerr]

Hi Parisa,

Rotary3d should not be changed.
I think the problem might be with the quaternion file. GROOPS assumes the scalar component first (q0, qx, qy, qz) but in your file the order is given as (qx, qy, qz, q0)

regards
Torsten

[ParisaShafiei]

Hi Torsten,

You are right. The problem came from the quaternions which I did not expect that.
Thus, I kept Rotary3d untouched and I just changed the source code of champ2AccStar as:

        Vector q(4);
        q(1) = String::toDouble(line.substr(50, 14));
        q(2) = String::toDouble(line.substr(8, 14));
        q(3) = String::toDouble(line.substr(22, 14));
        q(0) = String::toDouble(line.substr(36, 14));

        attFlag = TRUE;

It worked properly and the sigma and RMS values in the summery of processing are totally fine without seeing even jumps or big numbers.

Thank you again for going through my question and your great help. It's really appreciated.

With kind regards,
Parisa

[ParisaShafiei]

Hi Torsten,

I found a mistake in changing the order of the quaternions:

When I changed the source code of champ2AccStar, I noticed that I totally changed the order of all the quaternions. Then, when I plotted roll, pitch and yaw via using InstrumentStarCamera2RollPitchYaw, I got different angles from before, i.e. all the three axes were flipped.

Indeed, based on the source code of champ2AccStar, it is assumed that the order of the quaternions in CHMAP format is: qx, qy, qz and qw (scalar) and in the GROOPS simulated starcamera file, the order is q0 (scalar), qx, qy and qz.

Source code of champ2Acc:
Vector q(4);
q(1) = String::toDouble(line.substr(8, 14));
q(2) = String::toDouble(line.substr(22, 14));
q(3) = String::toDouble(line.substr(36, 14));
q(0) = String::toDouble(line.substr(50, 14));
attFlag = TRUE;
if(fabs(norm(q)-1)>1e-5)

GROOPS simulated starcamera:

Therefore, since my LEO attitude files are in CHAMP format, I think the problem does not come from the order of the quaternions, because they are in the right format and order. Is there something else that you I need to check? Or if I misunderstood what you meant.

Secondly, I wanted to make sure if I applied InstrumentStarCameraMultiply correctly or not.

To go from CRF to SRF, this is what I did:

1. First instrument star camera: SRF to CRF
2. Second instrument star camera: LOF to CRF

I was wondering maybe the problems comes from this part. Is what I applied correct?

Thank in advance for your time and help.

With kind regards,
Parisa

[tmayerguerr]

Hi Parisa,

Rotations are always confusing for me. When you rotate a vector, you multiply the rotation matrix from the left:

  pos_CRF = rot(SRF->CRF) * pos_SRF 
          = rot(LOF->CRF) * pos_LOF
          = rot(LOF->CRF) * rot(SRF->LOF) * pos_SRF

This means that the following applies to the entire rotation:

  rot(SRF->CRF) = rot(LOF->CRF) * rot(SRF->LOF)

In short, you have to swap the two matrices in InstrumentStarCameraMultiply.

Torsten

[ParisaShafiei]

Dear Torsten,

The good news is swapping the two matrices solved the problem.

Thank you so much or this clear explanation. I had a hard time in finding the right order of applying the rotation matrices in the processing.

With kind regards,
Parisa

[tmayerguerr]

See you at EGU?

[ParisaShafiei]

Hi Torsten,

Yes, I am attending EGU for the whole week and have a poster presentation on Friday, 28 Apr, 08:30–10:15 | Hall X2 .

https://meetingorganizer.copernicus.org/EGU23/EGU23-15932.html

It will be my great honor to meet you there.
Looking forward to seeing you.

With kind regards,
Parisa