Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coordinate transformations #2

Open
ShujuanGeng0227 opened this issue Jun 5, 2023 Discussed in #1 · 1 comment
Open

Coordinate transformations #2

ShujuanGeng0227 opened this issue Jun 5, 2023 Discussed in #1 · 1 comment

Comments

@ShujuanGeng0227
Copy link

Discussed in #1

Originally posted by pgrebolt May 29, 2023
Hi all,

I am working with the DFN darkflight modelling code and, looking deep into it, I think there are some conversions between frames that are not done properly. I have seen that when converting from ECI coordinates to LLH, a transformation involving ECEF->LLH is applied, thus neglecting any Earth rotation effect. For example, this occurs in df_functions.py, in line 77 (AtmosphericModel). In my opinion, the steps should be ECI->ECEF->LLH. I have made the conversion as:

Pos_ECEF = ECI2ECEF_pos(Pos_ECI, t_jd)
Pos_LLH = ECEF2LLH(Pos_ECEF)

Similarly, this also happens in df_functions when converting the wind vector (in ENU) to ECI or in trajectory_utilities.py when computing gravity_vector(). In the case of the wind vector I am now conducting the following conversion:

lat = float(Pos_LLH[0]); lon = float(Pos_LLH[1]) # (rad)
ENU2ECEF_matrix = ENU2ECEF(lat, lon)
Wind_ECEF = np.dot(ENU2ECEF_matrix, Wind_ENU)
Wind_ECI = ECEF2ECI(Pos_ECEF, Wind_ECEF, t_jd)[1] + v_rot

However, I am still wondering if in this case v_rot should be added.

Has anyone wondered the same? Is it possible that I am missing some approximations between ECI and ECEF?

Thank you

@ShujuanGeng0227
Copy link
Author

Hello, I have asked the same question to one of the author and we would like to repo his answer here:

%%
You may notice I've put an ECI position vector into a ECEF2LLH conversion. From memory, I believe that was because I wanted to save computational time and also because we don't have access to timing information at that point in the code to do the proper conversions from ECI -> ECEF -> LLH. I think the +-40m was calculated by me and is due to the small difference between Earth's ECEF z-axis and Earth's ECI z-axis. If I pretend those z-axes are the same (as I've done in the code), I'm actually shifting the Earth's ellipsoid in one of those frames very slightly, changing heights on the ground.

If I pretend those z-axes are the same (as I've done in the code), we end up with a possible height difference on the ground (height between the blue and green ellipses) of about 40m.

That said, I don't think this is a problem at all because (1) the meteoroid is probably travelling almost vertically by that point anyway so the impact site in lat/long would be almost the same, and (2) as far as I'm aware, we are not yet including proper ground height information, besides a constant height above sea-level set in a config file somewhere.

You are welcome to change it to use the proper conversions, i.e. ECI -> ECEF -> LLH, but you will slow down the code quite a bit and you will need to pass it the timing information somehow.

%%

That's the answer. Hope this will help you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant