feat(devices): V5 Inertial Sensor support

[Tropix126]

Adds high level bindings to the PROS IMU API through the InertialSensor struct. Currently untested on actual hardware.

Limitations:
- The fields on pros_sys::imu_raw_s appear to be private, making it impossible to implement the InertialSensor::gyro_rate and InertialSensor::accel without manually modifying the bindings. As such, i've left these methods commented out for now.

Let me know if any of the naming for things here seem off. (specifically, should data structs be InertialStruct or InertialSensorStruct?)

[Gavin-Niederman]

Your naming is perfectly fine as it is.

[Gavin-Niederman]

Thank you for contributing! there are only 2 things that I would change.

[Gavin-Niederman]

I think this is ready to merge unless lewis disagrees

[Gavin-Niederman]

Thanks for doing these bindings, I was putting it off.

[Tropix126]

Okay, seems we have a choice on how we want to handle calibration (currently we call the non-blocking function):

Any thoughts?

[Gavin-Niederman]

Ah, I say we use the blocking function for the sync API and the non blocking one to create a future for the async API.

[Tropix126]

Sounds good, will do.

[Tropix126]

Any thoughts on bringing in a crate like mint which provides standard container types for other math-related crates to interop with?

• Quaternion -> mint::Quaternion
• Euler -> mint::EulerAngles
• InertialRaw is essentially a mint::Vector3, serving as either an angular velocity vector with gyro_rate or an acceleration vector with accel.

Could also make it an optional feature and just provide conversion types rather than straight up returning them.

[Gavin-Niederman]

I think that if we do that it should definitely be a feature. I also think that there are many crates that provide similar functionality to mint, such as nalgebra, so there should be discussion on which one we would use. For now I think we should continue without bringing in a library like that, but I am open for discussion about it later.

[Gavin-Niederman]

After this and testing, it should be ready to merge.

[Gavin-Niederman]

Everything looks good! If you think that testing isn't necessary I will approve and merge.

[Tropix126]

Everything looks good! If you think that testing isn't necessary I will approve and merge.

Still need to test the newer async stuff against the executor fix branch, which i'll try to get to tonight, tomorrow, or monday. Everything else has been tested to my knowledge.

[Gavin-Niederman]

Alright sounds good. I hope we can get this merged soon.

[Gavin-Niederman]

LGTM (Lets Get That Motion)