Closed tjstienstra closed 6 months ago
It might be an idea to study the Point.vel
warnings it gives on that a velocity can be computed w.r.t. different points. They seem to be different than before.
This regression has been solved with the implementation of AuxiliaryDataHandler._compute_velocity
in #128. The current number of operations in the EoMs before and after CSE is 266594 and 1908 respectively (2e7c89f456cb2c59895a4ed3862955c4e0522f5d).
$\mu \pm \sigma$ (s)
before CSE
after CSE
The table also shows some other implementations as a reference, which are also in the
benchmarks/test_whipple_bicycle.py
file. The first three results were specifically created over 50 runs on an Inter(R) Core(TM) i7-8750H CPU @ 2.20GHz with BRiM commit: ec02a0a7852b15de2f37e0630e2af962f69bba9d. Note that the computation time does not matter too much and should be taken with a grain of salt, as the timing results differ more than the standard deviation from time to time.I have tracked the change down to the fact that the usage of the
rear_frame.steer_hub.to_valid_joint_arg()
instead ofrear_frame.body
as parent argument in the steer joint results in the increase of operations after CSE. This means that the velocity graph of the points is defined a little differently. It is notable that the number of operations in the EOMs before CSE actually decreases.In #103 I propose the following three solutions:
Point.vel
method. While it would be ideal to make this more advanced, it is quite a nasty problem to solve.optimize_velocity_definition
when exporting to a singleSystem
, which can later be moved toSystem
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.WhippleBicycle
to optimize the velocity definition. This has the disadvantage of a constant labor.When working on the third point I noticed that I was not able to get the wanted decrease when manually specifying the velocities which would be set by
PinJoint when using
rear_frame.body`. My hypothesis is that the automated velocity computation just follows a suboptimal path or multiple paths to compute the same velocity component. It would be optimal if everything always uses the same velocity component and not an alternative, but figuring out how to force this is quite a challenge.This issue challenges us to find the exact reason for the seen regression and find an appropriate fix for it.