Open tjstienstra opened 1 year ago
Do we want to keep a dcm
, ang_vel_in
, ang_acc_in
in RigidBody
or should someone just use RigidBody.frame.dcm
? I thought I discussed this with someone some time ago and the conclusion was that it would be better to keep it really as composition.
Hey @TJStienstra,
we talked on the issue Make Body and ReferenceFrame analogous
#21964 about implementing BodyBase
and leaving Body
& ReferenceFrame
to composition. And, I see Body
hasn't been deprecated yet.
Let me know the specifics to be done to solve this and/or to deprecate `Body'.
Hey @sujantkumarkv,
Good that you've read through the issue. I would like to deperecate Body
and JointsMethod
after implementing the currently implemented features in #24234. Therefore, I would not really recommend putting too much effort in Body
.
To give a little more inside in the planning: a current open PR implements the Inertia
, next the Loads
will be implemented (expect to open that one next week). If those are both merged I expect to open a PR implementing System
, which will take some more time to get reviewed.
I don't have an immediate issue to point you at. What I would recommend is to experiment a little by solving a mechanics problem. In this process you will not only get some more experience with sympy.physics.mechanics
, but you can also find bugs and inconveniences. This is a good reference if you need to know more about the mechanics used in SymPy.
P.S. There are currently also some issues/PRs mentioning that some parts of mechanics are a bit slow. Maybe looking into how for example KanesMethod
can be made faster is also worth looking into.
Another challenging but forgotten issue, which might be nice to look in is #23382. Note that this is an issue which might actually be a bit too tricky.
This issue is coupled to the experimental mechanics development described in #24234. Feel free to comment down below and suggest improvements or even discuss a different approach.
Issue
The current implementation of the body classes follows the structure, where we have a
RigidBody
and aParticle
class, which are both inherited by aBody
class. ThisBody
class can then be used to represent either aParticle
or aRigidBody
. The advantage of thisBody
class is that it has a same interface for both types of bodies, e.g. it has aframe
. ThisBody
class is used in the joints framework, as that requires a body to have aframe
and aParticle
does not have aframe
. However there a several problems with this current implementation:RigidBody
and aParticle
(also called a point mass` are both types of bodies.Particle
,RigidBody
and aBody
differently.Body
is not compatible with for exampleKanesMethod
#23269 (note that these problems can be fixed).Solution
A more logical structure would be an abstract body class, called
BodyBase
, from which bothParticle
andRigidBody
inherit. This removes duplicated code, makes sure that they use the same interface and is also more logical from a physics point of view. The problem of aParticle
not being compatible with the joints framework can be solved using the intermediate frames of the joints.Implementation
The implementation of this reorganization in planned to be done in multiple PRs:
BodyBase
,Particle(BodyBase)
,RigidBody(BodyBase)
(#24238)Particle
andRigidBody
withJoint
(#24550, #24699)Body