search

ericstoneking / 42

Simulation for spacecraft attitude control system analysis and design
247 stars 82 forks source link

Update Orbit frames before InitSpacecraft() #36

Closed ThatcherC closed 4 years ago

ThatcherC commented 4 years ago

Hi Eric,

I've encountered an error in spacecraft attitude initialization. I found it while running a simulation

although I suspect it would effect simulations with slightly different configs as well.

Here's how to replicate the problem: Attitude setup in my Spacecraft.txt file (using angle sequence 123 to match the RPY.42 logs:

*************************** Initial Attitude ***************************
NAL                           ! Ang Vel wrt [NL], Att [QA] wrt [NLF]
0.6    0.5    1.0             ! Ang Vel (deg/sec)
0.0    0.0    0.0    1.0      ! Quaternion
60.0  50.0   40.0    123      ! Angles (deg) & Euler Sequence

I won't list the Inp_Sim.txt here, but the relevant parts are that it uses Spacecraft.txt assigned to an orbit defined by a TLE from a couple weeks ago, and I'm operating in EXTERNAL mode.

I'm using unmodified 42 + the change discussing in Issue https://github.com/ericstoneking/42/issues/33 that fixes the AbsTime/AtomicTime inconsistency. Here's what I get in the logs:

$ cat IO3/AbsTime.42 
652243041.000000
652243042.384000
652243043.384000
652243044.384000
652243045.384000
...
$ cat IO3/RPY.42 
60.000000 50.000000 40.000000
51.067364 -45.131788 135.628397
49.913295 -45.050428 135.773724
48.760679 -44.983642 135.919908
47.609659 -44.931445 136.066860
...

Even though time is stepping smoothly along, there's this huge change in attitude between the first and second lines.

ThatcherC commented 4 years ago

The cause appears to be that the Orbit CLN matrices aren't being updated to their state at the time at the start of the sim. The desired RPY angles are being set, but set correctly in the wrong frame (I think each Orbit's CLN frame is the orbit LVLH at orbit epoch time, which has no connection to the sim start time). I added a block of code from the Ephemeris() function in Source/42ephem.c that sets all the Orbit CLN matrices to their state at the current time, which if called at the end of InitSim(), is the sim start time. You can see what that change looks like here - https://github.com/ThatcherC/42/commit/8a3c229262a59971ffe869f569aee273d128ee21#diff-badd8b682bb40a7459dad382e49a2d33R4134 (just ignore the matrix printing code I've added elsewhere in that commit).

This way, when InitSpacecrafts() sets the Spacecraft CN matrices using Orb[i]->CLN and the RPY angles, we get the correct resulting orientation.

Making this change fixes the problem I observed so I can accurately set RPY attitudes relative to the Local frame of the spacecraft at sim time = 0, which is great. However, I'm not sure that adding the extra code from Ephemeris() to the end of InitSim() is the right/best way to apply the fix. Better ways might be to:

Which solution would fit best into the style and structure of 42? I've been chasing this attitude initialization bug for awhile and I'm excited to be this close to having it fixed in the main code. Thanks!

ericstoneking commented 4 years ago

Your fix has been adopted.

ThatcherC commented 4 years ago

Hi Eric - I saw that OrbitMotion is now included at the end of 42init.c as of your changes to the master branch this morning, which is part of the Local Frame attitude initialization issue. The other important part of the solution to that problem, though, is updating the CLN matrix of each orbit. That is normally done in Ephemerides, which is called after the spacecrafts are initialized, so LVLH attitudes don't init correctly.

PR https://github.com/ericstoneking/42/pull/37 introduces a new function SetOrbitLocalFrames that is called from Ephemerides() and from InitSim() so that orbit local frames can be updated before spacecraft attitudes are set. I think the PR's solution is a clean fix that matches the surrounding code style so hopefully it's a good solution. Thanks! Thatcher