mechmotum / symbrim

A Modular and Extensible Open-Source Framework for Creating Symbolic Bicycle-Rider Models
https://mechmotum.github.io/symbrim/
Creative Commons Zero v1.0 Universal
10 stars 3 forks source link

Attachments #103

Closed tjstienstra closed 1 year ago

tjstienstra commented 1 year ago

This PR tries a conversion to using attachments classes, which is coupled to #100

tjstienstra commented 1 year ago

What I feared actually happened, namely that the number of operation in the EOMs have increased. This is most probably due to the usage of just the attachment (interframe and point), where the body's center of mass is not computed anymore via the velocity two-point theorem. There are several solutions:

  1. Revert the change of using attachments. Not ideal as the previous implementation just builds upon incorrect assumptions.
  2. Upgrade the Point.vel method. While it would be ideal to make this more advanced, it is quite a nasty problem to solve.
  3. Add an optimize_velocity_definition when exporting to a single System, which can later be moved to System within sympy. This is also not a simple solution, as one needs to detect when it is advantageous to compute a velocity using a certain theorem.
  4. Add a manual set of velocity theorems in WhippleBicycle to optimize the velocity definition. This has the disadvantage of a constant labor.

For now I am in favor of option 4. Though option 2 and 3 would also be quite great.

tjstienstra commented 1 year ago

I have not been able to figure out how to get the better EOMs in a short amount of time. This will require further research and it is preferable to have this bug fixed. In the end the high performance BRiM actually had on the number of operations after CSE has so far been unexplainable.