search

RobSimulatorGroup / gobot

Go, robot go!
GNU Lesser General Public License v3.0
16 stars 2 forks source link

Define a basic framework for robot kinematics and collision #62

Open StephenYu-R opened 1 year ago

StephenYu-R commented 1 year ago

Hard to script a graph, so split uml into following parts.

Robot3D/Skeleton3D =======|------- Segment3D/Bone3D ============|-------- Joint info (Body connections and spring/damping constrains) ============|-------- Frame/mesh info from PhysicsBody3D)

Inheritance Chain: Node3D <- CollisionBody3D <- PhysicsBody3D <- Segement3D ====================================|<- RigidBody3D ====================================|<- SoftBody3D ...

WIth frame info, one could implement kinematics and collisions in PhysicsBody3D and thus could be queried by Robot3D.

It's good to have a abstract layer of kinematics so that one can implement sorts of reused RobotTypes just by overriding kinematics as follows,

Robot3D <- Industrial6R =======|<- Collaborative6R =======|<- Palletizing4R

StephenYu-R commented 1 year ago

A numeric-based kinematics solver should be provided as a fundamental component before closed-form solvers are added as a plugin as the later will introduce parts of hardcodes to constrain general configurations.

StephenYu-R commented 1 year ago

A 3rd-party kinematics solver is also considered as dynamics solver will be applied when solving motion plans, such as jacobian, pseudo-jacobian, inverse-jacobian, etc.

StephenYu-R commented 1 year ago

RigidBody3D and Joint are only two basic types needed to compose a Robot3D so these two will be defined first. We'll give up any abstract classes, such as CollisionBody3D and PhysicsBody3D. Robot3D will be reconsidered after that.