Wrong results when running main.py

[AngelMamba]

Hi,

Following the tutorial of full feature, I tried to run main.py, but I got this wrong result.

Also, I didn't choose any filters or methods, but it shows only one set of result.

Did I miss something or misunderstand the tutorial? Looking forward to the reply.

Best regard.

Xavier

[AngelMamba]

I think I found the reason. The data in orbit.csv are all meters, so in main.py

def read_args():
    parser = argparse.ArgumentParser()
    parser.add_argument('-f', '--file_path', type=str, help="path to .csv data file", default='orbit.csv')
    parser.add_argument('-e', '--error', type=float, help="estimation of the measurement error", default=10.0)
    parser.add_argument('-u', '--units', type=str, help="m for metres, k for kilometres", default='k')
    return `parser.parse_args()

the unit deflault should be set as 'm' @hornig @aryadas98 @Curious-Nikhil @vidhanarya @archithadge @sciduck @PerezHz

[hornig]

hi @AngelMamba you are right. this input is in meters in the example csv.

we already chattet on zulip about it what would be usefull. I like iso units, because of hughe numbers having km as the default value is not uncommon. we haven't decided yet what would be most useull. any ideas?

[AngelMamba]

Hi @hornig Thank you for the reply. I did not glance over what you had been talked about on zulip, but I think it makes sense as long as the dataset in the example csv and formulas in code share the same unit. So the main concern might be the computational performance? Huge number may cause low performance? I like iso unit too, so, km seems better? I am not sure. I am focusing on algorithm itself.

[hornig]

Hi @hornig Thank you for the reply.

you are welcome! :)

I did not glance over what you had been talked about on zulip, but I think it makes sense as long as the dataset in the example csv and formulas in code share the same unit.

yes. input data format is not yet fully decided. this will be another point we/you could start discuss. (for example I am a big json fan and would like to have everythin in json :D)

So the main concern might be the computational performance? Huge number may cause low performance?

in general you are right and also "back in the day" that was a big problem. me personally I do not care much, as long as it is defined what is the input. and as long there is no "type" statement in the input, the user should be able to select it. but the main reason is "people". if you for example have to express 150million km, that it is already a huge number and it is easier to then use 1AU. :D. okay, these are for inter planetary probes and not really our aim (yet). but also in earth's orbit some python libs use a different default unit. poliastro and astropy are nice there for example to let the user select the unit by their own class statement.

I like iso unit too, so, km seems better? I am not sure. I am focusing on algorithm itself. we can decide. it is not important as long as it is correct and defined.

so, what are your algorithm thoughts?

[AngelMamba]

Hi @hornig Thank you for the reply.

you are welcome! :)

I did not glance over what you had been talked about on zulip, but I think it makes sense as long as the dataset in the example csv and formulas in code share the same unit.

yes. input data format is not yet fully decided. this will be another point we/you could start discuss. (for example I am a big json fan and would like to have everythin in json :D)

So the main concern might be the computational performance? Huge number may cause low performance?

in general you are right and also "back in the day" that was a big problem. me personally I do not care much, as long as it is defined what is the input. and as long there is no "type" statement in the input, the user should be able to select it. but the main reason is "people". if you for example have to express 150million km, that it is already a huge number and it is easier to then use 1AU. :D. okay, these are for inter planetary probes and not really our aim (yet). but also in earth's orbit some python libs use a different default unit. poliastro and astropy are nice there for example to let the user select the unit by their own class statement.

I like iso unit too, so, km seems better? I am not sure. I am focusing on algorithm itself. we can decide. it is not important as long as it is correct and defined.

so, what are your algorithm thoughts?

Hi @hornig Thank you for such specific explanation. To be honest, as a control system enginner, I am just a freashman in this field (aerospace engineering). Still a lot of things to learn. I may have some experience in control algorithm, but satellite orbit determination is totally new for me. Sorry for not giving any ideas about the algorithm, but I am very exicited to find such an amazing python lib for orbit determination. Still need some time to taste it :D)

[hornig]

Hi @hornig Thank you for such specific explanation.

you are welcome. It's a good question.

To be honest, as a control system enginner, I am just a freashman in this field (aerospace engineering). Still a lot of things to learn. I may have some experience in control algorithm, but satellite orbit determination is totally new for me.

I know that orbit determination is something unusal. On first glance it is maybe difficult, but it is not. So if you are a control engineer, you should have some experience with kalman filters. That we also have in our project, so maybe that is a one way to start it :).

Sorry for not giving any ideas about the algorithm, but I am very exicited to find such an amazing python lib for orbit determination. Still need some time to taste it :D)

Thank you :). We are still working on it to make it more useful. Every comment helps. If you are interested come to our zulip chat https://aerospaceresearch.zulipchat.com/#narrow/stream/147024-OrbitDeterminator

to come back to this issue: what do you think, shall we still keep it open?

[AngelMamba]

Hi @hornig Thank you for such specific explanation.

you are welcome. It's a good question.

To be honest, as a control system enginner, I am just a freashman in this field (aerospace engineering). Still a lot of things to learn. I may have some experience in control algorithm, but satellite orbit determination is totally new for me.

I know that orbit determination is something unusal. On first glance it is maybe difficult, but it is not. So if you are a control engineer, you should have some experience with kalman filters. That we also have in our project, so maybe that is a one way to start it :).

Sorry for not giving any ideas about the algorithm, but I am very exicited to find such an amazing python lib for orbit determination. Still need some time to taste it :D)

Thank you :). We are still working on it to make it more useful. Every comment helps. If you are interested come to our zulip chat https://aerospaceresearch.zulipchat.com/#narrow/stream/147024-OrbitDeterminator

to come back to this issue: what do you think, shall we still keep it open?

I will close the issue. It's totally for me. I've got perfect answer.:D) Yes, you're right. I used to design kalmen filter in other field, mainly chemical engineering, but it should work for satellite orbit. Now, I'm starting to learn basic orbit determination algorithm, and also trying to join the zulip chat. Thank you for the advice and resources. Looking forward to further update.