It seemed good to me to make a midterm overview of what I have done. It would have been better if I would have done this a week earlier, before my midterm, but this will in the end also be helpful for the final evaluation.

GitHub references

Below I summarize the issues and PRs that I’ve worked on. The following color coding has been used: merged/closed PR or issue, open issue and open PR.

In preparation of GSoC:

  • Raised and closed issue #23358 on the incorrect velocity calculation of Point.vel with merged PR #23362.
  • Opened draft PR #23359 proposing a zero velocity check to the velocity and acceleration theorems.
  • Raised issue #23382 which advises to compute the velocity in the Point.vel method in a recursive way.
  • Closed issue #22956 on incorrect PinJoint velocity with merged PR #23392.
  • Raised and closed issue #23393 which was a discussion on what the definition of a velocity in a frame is.

During GSoC period:

  • Participated in issue #21964 on making the Body analogous to ReferenceFrame.
  • Reviewed still open PR #23580 on returning kinematic equations implicitly in KanesMethod.
  • Merged PR #23628 which enhances the Point.acc method to also compute the acceleration if the velocity is not yet defined.
  • Merged PR #23705 adding the four-bar-linkage example using Joints.
  • Raised issue #23706 on the visibility of images when using the new dark theme.
  • Closed issue #21705 on the need of a figure explaining the Joint arguments with merged PR #23730.
  • Raised issue #23741 discussing how ReferenceFrame and Point should go about saving states.
  • Merged PR #23890 converting the joint images introduced in #23730 to svg.
  • Raised issue #23913 on the problem that the use of temporary relationships between ReferenceFrames in the Joint class can lead to deleting correct relations.
  • Opened PR #23920 changing the definition of a Joint to use intermediate frames.
  • Raised issue #23933 on the unnecessary dependency of test_pinjoin_arbitrary_axis on test_functions.py.
  • Opened PR #23981 adding an optional frame argument to RigidBody.parallel_axis and implementing Body.parallel_axis.
  • Opened PR #23982 changing Body to always have an inertia, also when representing a Particle. This will partially solve issue #23269.

Short reflection

Overall I’m quite happy with this list. Multiple things have been improved (green), for which I also have to thank my mentors. Especially the advise of reading this paper was really good, partially because it also lead to #23920 and maybe more. And there are also some open PRs ready for review (blue), so still work in progress :)

Recommendation

When going over the list a few things can be noticed.

Firstly a decision how to go around with state saving should be made. Since this affects: #23741, #23913, #23359 (follow up of #12322), #23382 and probably also some other issues and PRs from the past. Personally I would like a system, where only methods used by the user to create a relationship (e.g. Point.set_vel) may store a state in the state dicts (e.g. _dcm_dict). While the other methods, which compute a requested relationship (e.g. Point.vel) store the states in a separate cache dict (e.g. _vel_cache). Overwriting a state in the state dict results in resetting all cache dicts to be the same as the state dicts, while in the state dicts only the edited state will be updated. So, if the user did use the previous state to save another state, than this state will not be affected.

A second more like set of problems, which is not entirely notable in this list, is that the Body class is currently underdeveloped. Namely a clear decision should be made and executed on how analogous a Body should be to a ReferenceFrame. This mainly affects: #21964, which has multiple open PRs: #21974, #22926. Another problem is that Body is currently not fully compatible with KanesMethod and LagrangeMethod (#23269). However this is mainly a problem that should be fixed within _Method (#21772).

Lastly, there is also still a need for more joint types, so that is also where I’m currently working on.