Implement system hydrodynamics

[evan-palmer]

Checklist

• I have performed a thorough review of my code
• I have sufficiently commented my code
• The implementation follows the project style conventions
• All project unit tests are passing
• If relevant, documentation has been provided or updated to discuss the changes made
• System integration tests were performed successfully

Changes Made

This PR introduces a library which should be used by a controller to calculate the dynamics of the vehicle and its respective thrusters. Entrypoints have been implemented for the vehicle dynamics and the thruster dynamics. The current effects and thruster configuration matrices have also been added.

Associated Issues

• Fixes [FEATURE]: Implement hydrodynamics to support controller implementation #6

Testing

Google Test has been used to create a collection of test cases to evaluate the correctness of the implementation.

Additional Notes for Reviewers

The main points that I am hoping to elicit some feedback on are as follows:

1. Would the current effects be better off in a controller package?
   • Associated files:
     • blue_dynamics/include/blue_dynamics/current_effects.hpp/cpp
2. What are your opinions on the usability of the VehicleDynamics struct? I made the decision to implement a collection of structs to use for defining collections of variables to improve readability as opposed to listing all parameters. However, it may be painful to require users to instantiate each of these just to create the vehicle dynamics
   • Associated Files:
     • blue_dynamics/src/vehicle_dynamics.hpp/cpp
     • blue_dynamics/include/blue_dynamics/hydrodynamics.hpp/cpp
     • blue_dynamics/test/test_vehicle_dynamics.cpp
3. What are your thoughts on the general design of the package? Are there ways to improve?
4. Thoughts on passing the "stamped" version of a message versus the un-stamped version.
5. I am still working on the thruster dynamics, so please ignore that.

[dawsonc]

Overall, nice work! I have some high-level comments:

• When I see a struct/class called Dynamics, my assumption is that it will be able to compute the state derivatives (dx/dt) for me, but I don't see this in your code. Is that a feature that you plan to add to the VehicleDynamics struct? If not, then I would think of this struct as more of a VehicleParameters.
• I think that the intended way to interact with VehicleDynamics is not clear. All of the members are public, so am I supposed to just use them? But it seems like that could lead to easy mistakes (e.g. using added_mass.toMatrix() since you've defined those convenient helper methods rather than calculateAddedMassMatrix). Consider making it clear (in documentation and through use of private members) what the intended way to access these data is.
• I left a few scattered comments about how it feels inconsistent that some VehicleDynamics methods require you to manually pass in vehicle parameters, while others use parameters directly from the struct. Thinking about the intended use case: would you ever want to use these methods without a full VehicleDynamics struct? Would some of these methods be better off as private methods? I guess then they become harder to test, but there's some discussion of that online.
• You asked about stamped vs non-stamped message types. My feeling is that if you accept the stamped message type, you're making an implicit promise to respect the header and transform the type appropriately before using. It seems like your code is not doing this, which could lead to bugs when someone tries passing in a stamped type in a frame other than the inertial frame. It would probably be a pain to make VehicleDynamics rely on having a TF tree connection, since that would make testing a pain and break some isolation, so I would lean towards using non-stamped types and specifying in the function documentation that they must be in a certain frame.