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

More tests #62

Merged
merged 14 commits into from
Oct 27, 2024
Merged

More tests #62

merged 14 commits into from
Oct 27, 2024

Conversation

JacksonElia
Copy link
Member

@JacksonElia JacksonElia commented Oct 27, 2024

In this PR I:

  • Cleaned up and fixed DataProcessor
  • Fixed all existing tests
  • Wrote tests for the gravity vector stuff and quat orientation
  • Got tests for the accel rotations and vertical velocities

@harshil21 harshil21 changed the base branch from main to apogee-pred October 27, 2024 00:52
@JacksonElia JacksonElia marked this pull request as ready for review October 27, 2024 00:56
tests/test_data_processor.py Outdated Show resolved Hide resolved
tests/test_data_processor.py Show resolved Hide resolved
@harshil21 harshil21 added the tests For PR's which improve tests label Oct 27, 2024
@JacksonElia JacksonElia requested a review from harshil21 October 27, 2024 04:00
Copy link
Member

@harshil21 harshil21 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good job on passing data processor tests! I would still like 2 more tests, for the _multiply_quaternions and _calculate_quaternion_conjugate functions.

airbrakes/data_handling/data_processor.py Outdated Show resolved Hide resolved
airbrakes/data_handling/data_processor.py Outdated Show resolved Hide resolved
tests/test_data_processor.py Show resolved Hide resolved
tests/test_data_processor.py Show resolved Hide resolved
tests/test_data_processor.py Outdated Show resolved Hide resolved
tests/test_data_processor.py Outdated Show resolved Hide resolved
@@ -369,12 +478,64 @@ def test_max_altitude(self, data_processor):
],
)
def test_calculate_rotations(self, data_packets, expected_value):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want some more cases on this test. Another case should involve e.g. different axis of gravity vector, different gravity sign, no gyro data, etc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm gonna wait on this one for will

assert rotations[1][-1] == pytest.approx(expected_value[1])
assert rotations[2][-1] == pytest.approx(expected_value[2])

def test_initial_orientation(self):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ideally this test should also be paramterized so it covers literally all 6(?) gravity cases. The two cases you chose are sufficient so this isn't necessary but still.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was a pain to write these and I figured the cases covered everything, but you're probably right. I think I'll also wait on will for this one.

tests/test_data_processor.py Outdated Show resolved Hide resolved
tests/test_data_processor.py Show resolved Hide resolved
@wlsanderson
Copy link
Contributor

wlsanderson commented Oct 27, 2024

Regarding some of the unit tests with rotating acceleration vectors, I will most likely have to do another pass over the math. It most likely wont work given a flipped dataset where +Z is vertical. For the time being, if you are giving it normal compensated accelerations, gravity vectors, and quaternions that appear on the existing datasets, tests should pass and everything will work fine. I will most likely need to work on #63 a bit first so that I can fix the math with flipped datasets. I can be responsible for updating and passing those tests once I get that sorted out, and add some case scenarios for different vertical orientations.

@harshil21
Copy link
Member

You mean only the rotated accelerations would have an incorrect value? If that is the case, the unit tests should've already caught them in a way. Anyway, the unit tests should actually test every possible orientation and configuration, and we need to be sure the values are correct (cause it's hard to do the math manually). Do you know if there's an online calculator or something so we can double check?

@wlsanderson
Copy link
Contributor

wlsanderson commented Oct 27, 2024

No, It has to due with how the IMU would log data depending on orientation. With the rocket being -Z vertical (like interest launch) you would expect on launch pad assuming directly vertical:

  • compensated acceleration: [0, 0, -9.8]
  • gravity vector: [0, 0, 9.8]
  • quaternion (not normalized): [1, ~0.01, ~0.01, -1]

From this, we rotate the acceleration, which gives a vector pretty close to [0, 0, -9.8]
we then flip the sign because the gravity vector is positive, so the result is [0, 0, 9.8]
this is correct. What I forgot to account for is that on an inverted flight (+Z is vertical), the initial quaternion would cause it to rotate 180 degrees.

  • compensated acceleration: [0, 0, 9.8]
  • gravity vector: [0, 0, -9.8]
  • quaternion (not normalized): [1, ~0.01, ~0.01, 1]

When you do the same operations, I believe the acceleration would come out to [0, 0, -9.8], but we want it to be positive.
I'm not aware of any online calculators to help with this, but I'm going to use the physical IMU tomorrow to test some values and orientations and do the calculations, both in matlab and in the codebase unit tests.

@JacksonElia
Copy link
Member Author

@wlsanderson @harshil21 what do you want to do with this PR? I would prefer to merge this as it is, then make a new branch for fixing the math and improving the tests for them. Alternatively, we could make a branch from this fixing the math, merge it into this, then merge this into #47, but then I feel like we will have way too many branches and conflicts down the line and I don't want to deal with that.

Merging #47 with main is already going to be a headache as is

@JacksonElia JacksonElia requested a review from harshil21 October 27, 2024 19:10
@harshil21
Copy link
Member

I'm going to use the physical IMU tomorrow to test some values and orientations and do the calculations, both in matlab and in the codebase unit tests.

alright I get it now. Can you make sure to get 6 different data sets (csv files) for all the orientations? Simply running main.py with the Pi and IMU should give you the all the data we need. We can then easily pass a couple of those packets to the unit tests to make sure we get everything right. (perhaps in a new folder in tests/imu_data/?)

@harshil21
Copy link
Member

@wlsanderson @harshil21 what do you want to do with this PR? I would prefer to merge this as it is, then make a new branch for fixing the math and improving the tests for them. Alternatively, we could make a branch from this fixing the math, merge it into this, then merge this into #47, but then I feel like we will have way too many branches and conflicts down the line and I don't want to deal with that.

Yeah a separate PR after merging this is the way to go, to keep things atomic.

Merging #47 with main is already going to be a headache as is

dw, there wouldn't be too many conflicts (I already solved most yesterday)

Copy link
Member

@harshil21 harshil21 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The mock sim is failing. If that passes, this PR should be good to go.

@JacksonElia JacksonElia requested a review from harshil21 October 27, 2024 20:21
@JacksonElia JacksonElia merged commit 72a9bf2 into apogee-pred Oct 27, 2024
1 of 2 checks passed
@JacksonElia JacksonElia deleted the more-tests branch October 27, 2024 20:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tests For PR's which improve tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants