intelligent-systems-lab-org / simunex Goto Github PK

An AUV (Autonomous Underwater Vehicle) is a class of UUVs (Unmanned Underwater Vehicles) that can be considered an underwater counterpart of an UAV (Unmanned Aerial Vehicle). As they operate underwater, they experience a multitude of environmental forces such as drag, lift, buoyancy, and added mass.

Added mass is a unique force that acts on the acceleration of the moving body. Since the magnitude can vary across DOF, the simplest way to implement an acceleration-based force is by using a mass matrix $M$ and operating the physics engine in acceleration force mode by using the formula: $a = M^{-1} \times F$, where $F$ is the 6DOF applied force and $a$ is the 6DOF acceleration.

New to SimuNEX is the implementation of control surfaces such as fins which allow for movement underwater along with propulsion. Just like the PropellerFunction, an equivalent FinFunction would be implemented for fin dynamics as a MotorLoad object.

TODO

• Implement drag forces (linear, quadratic, cross-drag etc) (see 5028e87)
• Implement buoyancy (see 222f3c5)
• Implement fin forces (see 576f66c)
• Implement added mass forces (see 3f073b9)

Actuators and sensors play crucial roles in SimuNEX. By adding faults to both systems, it enhances the realism and variability of simulation scenarios and thus the fidelity of the simulator.

TODO:

• Implement a system that "marks" and captures specific variables in an Actuator and Sensor as Faultable.
• Implement FaultSystem* interface - this is for storing faults for each variable.
• Implement the editing of faults in the Unity Editor.
• Implement various types of faults including bias, scale, gaussian, dead zone, etc.

Description:

To implement a system of environment fields and forces to simulate various physical phenomena in SimuNEX.

A proof of concept is where an environment is defined as a specific space where these forces are applicable. Outside of the field, the forces are absent. Examples include gravitational fields and buoyancy when submerged in a fluid.

TODO:

• RigidBodyF

  • A specialized class derived from RigidBody that contains relevant fluid properties such as volume, etc.

• Environment Class:

  • This class should handle the registration and deregistration of objects within a defined boundary or area.
  • It should provide methods or mechanisms to apply forces or effects to objects within its boundaries.

• ForceField Class:

  • This should be an abstract base class that provides a template for specific force fields.
  • It should define the core functionalities like applying and removing forces on objects.

• SimpleGravity:

  • Implement a class that simulates the gravitational force.
  • This force should be constant and act in a specified direction.

• SimpleBuoyancy:

  • Implement a class that simulates the buoyant force, which is felt by objects submerged in a fluid.
  • Should account for factors like the density of the fluid, the volume of the object submerged, etc.

• SimpleGravityField:

  • Implement a force field that applies the simple gravity force to objects within its boundaries.

• SimpleBuoyancyField:

  • Implement a force field that applies the buoyant force to objects submerged in a fluid within its boundaries.

TODO:

• MotorLoad (see d3dec6b)
• Propeller models (see 9994438)

In our CI/CD pipeline, the checkout GH action is a crucial for fetching the repository content into the runner environment. However, we've encountered situations where the action fails or behaves unexpectedly, and the logs do not provide sufficient detail to understand the root cause.

The checkout action was tested with v2-v4, all of which result in the same error: (Error: fatal: could not read Username for 'https://github.com': terminal prompts disabled), with various solutions tried but all of failed to work.

We are looking into an alternative workflow (e.g., CircleCI) and any contributions would be appreciated.

There is an ongoing issue with the build system, which is crucial for creating SimuNEX executables.

This issue relates only to ROS 2 since it is currently the only communication "protocol" (ROS 2 is actually a middleware, not really a protocol).

Upon building the demos, it seems that the topics created by the COMSystem with the ROS 2 Connector do not initialize at runtime.

This issue should be fixed ASAP.

Implement an interface and also models for simulating motors.

TODO

• Motor interface
• Identity, DC, PMSM motor models (complete as of 73cac1b)
• StateSpace and Integrator interfaces (see bc49551)

Implement communication mechanisms with external entities. Only ROS 2 would be sufficient to complete the task. No need for packet loss functionality yet.

TODO:

• COMSystem and COMProtocol classes (implemented and test on bd69ad0)

Implement an interface for simulating dynamic systems.

TODO

• Dynamics interface (see 3cadb8f)
• RigidBody and Force interfaces (see defc719)

Requirements:

• Unity TestRunner

TODOS

• Code Coverage Reports
• Unit Testing for Unity

We have successfully encapsulated the Euler, Heun, and RK4 methods within our Integrator class. The unit testing framework we've constructed provides a robust preliminary examination of these methods across a set of three ODEs, benchmarking them against known solutions. However, this current setup predominantly confirms the capability of these solvers in handling ODEs, but it falls short of affirming the correct implementation of each individual integrator method.

To guarantee the correct implementation of our integrators, we need to add validation tests specific to each method. Here are some suggestions:

1. Analytical Comparisons:

   • For simple ODEs with known analytical solutions, compare the numerical results from every integrator with their exact solutions.
   • Calculate and document errors such as absolute or relative error for various step sizes.

2. Method-Specific Properties:

   • Confirm Euler's first-order accuracy, Heun's second-order accuracy, and RK4's fourth-order accuracy.
   • Also, test stability properties under different conditions.

3. Comparisons with Established Libraries:

   • Contrast the solutions derived from our integrators with those obtained from well-regarded numerical libraries.
   • Document any discrepancies and address significant deviations that arise.

This initiative aims to provide a more meticulous validation of our integrators, ensuring that each method is accurately implemented and performs reliably under a broad spectrum of conditions. Your insights and contributions towards this goal are highly valued.

Looking forward to your constructive feedback and collaboration on this endeavor.

Objective:
To integrate the Eigen C++ Library into the Unity framework for efficient matrix operations and advanced mathematical functionalities.

Background:
Unity lacks an efficient and transparent mechanism for intricate matrix operations. The Eigen C++ Library is widely used in high-performance applications, including TensorFlow and DART Physics. The inclusion of Eigen will bring transparency and reliability, which are vital for precision and repeatability in simulations, a shortfall observed in libraries like MathNet (which has been tried previously but was unsuccessful due to NuGet inconsistencies with Unity).

TODOS: (Do not tick unless there is an associated passing unit test)

• Implement base constructor for a 1D array with column and row-major options (see 3a8687e)
• Implement constructor for a 2D array (see 23d607c).
• Implement function that formats a matrix to string
• Implement matrix multiplication
• Implement transpose (in place and copy) (see 0561b15)
• Implement matrix addition and subtraction (see ae8b3fe)
• Implement equality operators (see 0c28743)
• Implement ordinary inverse (see d62cc11)
• Implement identity (see 388b5cf)
• Implement scalar multiplication (see a1c55c6)
• Implement conversions to 1D and 2D arrays (see 78438d2 for 1D, 16b8821 for 2D)
• Implement copy constructor (see 23b2516)

Exceptions
Exception handling is not needed at this stage in the interest of deadlines. However, at a later point in time, it will be mandatory to implement.

Deliverables:
A robust integration of the Eigen C++ Library into Unity, enabling high-performance matrix operations, enhancing algorithm efficiency, and paving the way for advanced mathematical and physics-based simulations in the Unity environment.

See 395919d.

A major change to the way forces is applied is necessary because of this issue.

One way I'm thinking of is have a Vector6DOF store a CoordinateFrame object which indicates its frame of reference. Then provide two methods to convert between frames and given a Vector6DOF is already in a specific CoordinateFrame, then do not apply.

When implementing interoperability with eigen3 in C#, unit tests were conducted without considering exceptions in interest of time. For example, adding matrices of unequal size, multiplying matrices with incompatible sizes, inverse on a non-square matrix, etc.