Attitude Determination and Disturbances

[Moanalengkeek]

Feature

Related to issue 180

Desired Behavior / Functionality

Adding a geometrical model, which contains pointing vector, as well as attitude disturbances to the model.

What Needs to Be Done

Each of the following points will be done. For points 1-7, there will be one pull request per point.

1. Create the geometrical model
2. Add the pointing vector to the geometrical model
3. Create an attitude disturbance model
   3.1. Add Aerodynamic disturbance torque to the disturbance model. Will be done by @GiordanoNesci
   3.2. Add Magnetic disturbance torque to the disturbance model. Will be done by @Mr-Medina
   3.3. Add Gravity disturbance torque to the disturbance model. Will be done by @Moanalengkeek
4. Update the thermal model to use the geometrical model

Then create tests for each of these sections. Lastly create a notebook simulating two satellites and showing the various attitude disturbance contributions. The specifics for these satellites are found in the assignment given.

In terms of timeline, points 1 and 2 should be done by the end of this week. Point 3 is the individual contribution, and we aim to finish this by the 15th of Jan. We also aim to complete point 4 by the 15th of Jan. The tests for the corresponding sections should be completed in parallel with the coding, but as separate pull requests.

The notebook with the simulation should be done by the 24th.

How Can It Be Tested

Creating new tests per section of code, as well as the notebook with the example simulations.

[GabrieleMeoni]

Thanks for posting your intended workflow. The workflow looks reasonable except for the following:

• Make sure each Pull Request (PR) includes the related test. Do not include tests separately in a final PR. You shall verify your test before pushing it.
• Create a dedicated PR for the final notebook (intended but TBD for the moment)
• Take your time, and do not rush. A few days for points 1 and 2 is a bit on the short side.
• Please, create an issue for each point.
• We keep the workflow flexible depending on how things go.

[gomezzz]

Thanks @Moanalengkeek @GiordanoNesci @Mr-Medina , happy to hear about your upcoming contributions!

On the "Desired Behavior / Functionality" I think some more details may be necessary. A bit more thorough explanation what will constitute the individuals compontents would be good, possibly in separate issues as @GabrieleMeoni suggested.
Details I would suspect are important:

• What are the variables of the geometric model? Is it a mesh?
• Ideally list all individual functions that users should know about so that we can add them later in the readme. Initial candidates, I would suspect: ActorBuilder.add_attitude_model , Actor.pointing_vector, Actor.get_mesh,
• Is there a reference (book, paper or such) that describes the models 3.1 - 3.3? Might be good to mention here already
• Will the model interact with the communications model? (e.g. a comm link could be limited to directional comms with this new feature)
• Are there plans for the actor to be able to changes its attitude actively? If so this is probably a separate function on the actor? If so, is it instantaneous?
• In which reference frame are geometric model and pointing vector described?

On "What needs to be done", I would suggest to outline a bit in which files you foresee changes. E.g. the initialization of the models can go here https://github.com/aidotse/PASEOS/blob/main/paseos/actors/actor_builder.py .

Ideally post where you plan to put what, then I can give you some feedback if it fits well. Also be sure to have a look at some of the already implemented models to get some ideas how the files are structured etc.

Step 1 and 2 may be easier to switch, since the pointing vector does not require any data etc.

For schedule please keep the holidays in mind as in that time less feedback may be incoming ;)

Looking forward to your plans and implementation!

[Moanalengkeek]

Thank you for your feedback!

First of all we have found that we do not have access to create a branch. Is this something that can be given to us, or is there an alternative workflow that you would recommend?
On your recommendation, we will also be relaxing our initial deadline of steps 1 and 2, but aim to now finish these before the 7th of Jan.

We've had a more detailed look at it, and also have the answers to some of your questions. Firstly, we've created a flowchart of how we think the code structure will look, in regards to the inputs, output and relations between the points mentioned above.

PASEOS_attitude_basicflowchart.pdf

Point 1 above is the pointing vector file, point 2 is the geometrical model file, and point 3 is the disturbance file. Each of these models will indeed be initialized in the actor_builder.py. The files themselves we will put in a new folder: attitude.

We will also be creating an issue for each of these points to go over the specifics within each of the boxes above. And indeed each of these points will include the specific tests for that section.

In regards to the specific points you’ve mentioned:

• We will initially be using a simple cuboid shape for the geometry, as none of us are familiar with using a mesh. But we may try to implement this later on
• Regarding the individual functions, we have some idea of how this will be implemented, but it will mostly likely be updated during implementation. Do we then update this issue with the functions we have created, or is there somewhere else we list them?
• We will be linking the approach taken for the disturbance models of 3.1-3.3 in the specific issues we will raise for those points. At this time we do not yet have the approach identified.
• There are currently no plans to adapt the communications model, or to add in active attitude changes. But we will aim to build the model in such a way that this can easily be added in later on.
• The geometrical model defines the satellite reference frame, which is a right-handed reference frame with the following axis at time zero: z-nadir pointing, y-along track, and x completing the reference frame when the Euler angles are zero. The pointing vector is attached to the z-axis of the satellite reference frame. Each of the disturbances will be done in the satellite reference frame, but we will transform it to the inertial (PASEOS) reference frame to give the output.

[gomezzz]

@Moanalengkeek Thanks for the elaboration, code and further details!

I will leave a bunch of comments here and in the PR and other issue. Just before, please note though that @GabrieleMeoni has to decide which of those are relevant to your project. If not relevant @GabrieleMeoni and I will take care of them later. So, until @GabrieleMeoni chimes in, feel free to disregard any comments ;).

[gomezzz]

First of all we have found that we do not have access to create a branch. Is this something that can be given to us, or is there an alternative workflow that you would recommend?

We can add you to the repo if necessary but typically, you can work with forks as described here but I think you figured that already in your PR. :)

We've had a more detailed look at it, and also have the answers to some of your questions. Firstly, we've created a flowchart of how we think the code structure will look, in regards to the inputs, output and relations between the points mentioned above.

For the inputs:

• What do you mean with dt? (The actor's local time as simulation's time step dt are defined already elsewhere)
• The satellite's position should also be defined already?

geometrical model file

usually it's geometric :P but I am not sure I understand why do you need any files?

Regarding the individual functions, we have some idea of how this will be implemented, but it will mostly likely be updated during implementation. Do we then update this issue with the functions we have created, or is there somewhere else we list them?

Once there is an initial PR for a part we can move the discussion mostly into the PR. no need to keep the issues up-to-date at that point. We will mostly use them to get initial feedback on specification / requirements analysis.

or to add in active attitude changes. But we will aim to build the model in such a way that this can easily be added in later on.

Okay just to clarify, maybe @GabrieleMeoni you want to comment there too. So for the moment we basically add tumbling but no way to stop tumbling?

Each of the disturbances will be done in the satellite reference frame, but we will transform it to the inertial (PASEOS) reference frame to give the output.

Okay, this gives me a bit of a headache because so far everything in paseos is in Earth inertial frame, so far, we could avoid any conversion between references frames. If you really need / want another reference frame, we should put code for the conversion between references frames somewhere in a utils folder or similar. Ideally, the user also can specify when adding the model. @GabrieleMeoni any comment on this part?

More comments to follow :P