Template refactor code cleanup#90
Merged
Merged
Conversation
…inematics` using the Scalar typename * Each header includes the corresponding .inl file holding the templated methods, thus improving code readability and scalability
…grator` class that contains Scalar typenames * Fixed smaller logic bugs in implicit euler and midpoint
* THIS TOOK SO LONG
… inlined oeprators.
…bers, using Scalar typename alongsideinlined oeprators.
…ors, along with scalar operations
…ce risk of uninitialised arrays (means reduced overflow risk)
…sts`, separating each subset of tests into its own .exe
…entation in main code
… RK2 harmonic oscillator state and sensitivity tests (rather than a much smaller 1e-5), separating state, sensitivity, and energy tolerances
…to reduce accidental singularities
…ce, and jacobian accuracy
…nalytical and fdm Jacobians, aswell as exploring the cross-variable propogation of coupled non-linear systems
* ALL TESTS PASS, given they are basic, but my logic is good * Though my brain is frazzled by the abstraction, i am going to try get the implicit testing done relatiove to the dual numbers
…ed tests over to AD
* This is going to change, however, I want something that fits with the current templating.
…d result definitions in `step_impl`, need to furhter explore BETTER methods * This is why we have a logger... looks cool and helps generally but is a godsend when debugging!
TODO * Once confirmed this is fully working I am going to change the logic to have a template scratch cache owned by trhe executation context
* Leaving this here because I am going bowling TODO * Reimplement friction model * Improve friction model using LPV??
* Will actual refine later down the line, do not really understand some of the better models, so I need to research and make sure my understanding matches what I am implementing! * Also I am soon going to be working on getting BASIC particle dynamics (iteractions implemented) --> This is a big goal
…r until I have developed my understanding further, this is in addition to sorting some other aspects of my core implementation out. * I am so fed up of the current debugging (that has lasted for a week) and since this is a personal project I can sort of just let it be for now. * I am leaving the current code in, just removing any enablers (i.e. switches) to turn it to AD... I am going to correct and fix this once I am confident in my underwstanding.
…ity implementation and execution * There are way too many changes to log (bad VC I know) * I decided to go abck through and see if any of the problems were missing params, or bad logic rather than purely mathematical * I am no renabling commented out coriolis and friction in dynamics
…n `spatial_jacobian` * I am almost certain remaining errros reside in my clearning, resizing, and calling of `DynamicsScratch` and `DynamicsResults`
* I am now going to merge this with ANOTHER branch (it will be named `Dev/template_refactor_code_cleanup`, in order to focus on correcting template syntax and general code pipeline, I have found that I am struggling to mentally visualise some parts of my code, and I think this is down to rapid development. The resolution I have is to spend some time basically house cleaning (which for me means correcting and cleaning code), aswell as starting the process of prepping DSFE for not just ROBOT SYSTEMs, this may mean a bigger refactor of how I step in time, with a more general method (maybe, or that I actually just have many steppers for each sub project, robotsystems being one, particledynamics being another, stellardynamics being another)
…ed in reset of robot (temp for now)
…no longer hardcode joint dynamic values.
…ation methods in core and GUI callbacks.
… header and into the DualNumber header, updating relevant methods with new fmod
…(leading to O(N^2)) in `automaticDifferentitationJacobian`
…with coulomb friction
… x_real var in `newton_raphson` after ten iterations
…int rather than constant across all joints.
…hod rather than if-else clamp
…move results window, just have it inhouse again, but safely).
… the non-templated VecX (VecX_T<double> def) rather than ambiguous templating of vector type * And just like that it works, there are many smaller issues I have noted to fix, but again I am really on the edge of my understanding here. * Next up for a change of pace is going to be the particle dynamics, but first that means making a functional state-driven workspace system in the GUI -> I am planning on really orientating this towards a visual proof, then going back and rebuilding the CLI batch to match newer logic -> Since I am no longer being graded on this (for now) it allows me to enjoy the process in my own way! :)
SaltyJoss
added
documentation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces significant enhancements to the integration subsystem, especially by adding support for automatic differentiation (AutoDiff) integration methods and refactoring the integration services for better flexibility and extensibility. It also includes some build system improvements and minor code cleanups.
Integration system enhancements:
DifferentiableIntegratorclass and theeAutoDiffIntegrationMethodenum, enabling support for AutoDiff-based integration methods such asAD_ImplicitEuler,AD_ImplicitMidpoint,AD_GLRK2, andAD_GLRK3. The implementation includes a newAutoDiffStep.inlfile with the corresponding step logic. [1] [2]IntegrationServiceclass to use a templatedStepOut_T<Scalar>struct, improving support for different scalar types and preparing the codebase for both standard and AutoDiff integration. The adaptive step logic and method selection have been modularized.Build system and configuration improvements:
gtest_force_shared_crtto ensure GoogleTest uses the shared CRT, improving Windows build reliability. [1] [2]/bigobjcompiler flag for MSVC builds ofDSFE_Coreto support larger object files.PxMLibtoMathLib, reflecting dependency updates.API and enum extensions:
ProgramData.handIntegrationMethods.hto include the new AutoDiff integration methods, making them selectable throughout the application. [1] [2]Code cleanup and minor fixes:
doubleinstead offloatsuffixes in telemetry data structures, and replacedstd::maxwithmathlib::maxfor consistency. [1] [2] [3]SpatialDynamics.cpp) from the core sources.MathLib.hheader and cleaned up legacy includes. [1] [2]Other changes:
DSFE_Unit_Testssubdirectory