Skip to content

Latest commit

 

History

History
198 lines (148 loc) · 9.13 KB

TODO.md

File metadata and controls

198 lines (148 loc) · 9.13 KB

This file contains gathered ideas which could be one day opened in the issue tracker.

A collection-like attribute results in double transform.

Having a Thing which aggregates some of its (mounted!) properties in a list-like property (or generator) makes subsequent accesses to such listed properties (through this list) receiving the transform twice.

Memoization is a key tool used in the library, yet is currently extremly naive and inefficient.

Some day it would be nice to improve the string-based current approach.

How to systematically access location of mount points?

  • When accessed, a TransformResolver is returned. However, there is no

MuJoCo export joints use pos properly.

Should resolve currently used hack with zero-mass virtual body.

Assemble to Nested Mount Points.

Currently, the mount points need to be "brought" to the Thing's reference frame in order to be used in assembly. Allow more over-the-joint references.

Allow Declarative Assemblies?

Currently, we need to keep strict hierarchically encapsulated structure, i.e., LinkBase is in fact LinkBaseAndSubassembly.

Automated Part Version Identification?

Internally call git blame to automatically identify a version of the Thing as the commit hash of the source file.

Unify Assembly and Reference Geometry Syntax?

This is a rather conceptual decision. I.e., everything will be assemblies, but with a binary flag whether it is assembled "for-reference". Will require cycle detection.

Headless Rendering.

Investigate how to invoke rendering in some driving script, maybe even headless. (Directly to file.)

Internal Structures Modeling.

According to SOTA, there is a problem of representing internal structures. These are often dependent on manufacturing and in practice implementation-dependent.

Multi-Resolution / Level-of-Detail Management.

The component to be represented in a multiple-resolution manner. E.g., a servomotor may be either assumed as a single solid body with inertia or an assembly of stator, gear and motor all the way down to discrete electrical parts. How to address this systematically?

Conventionalize another class-inheritance semantics?

  • Subclasses with registered "zoom-in" or "zoom-out" semantics. The zoom-out would be e.g. low-poly collision model.
  • A part could have these levels of predefined detail:
    • atomic (of course infeasible)
    • molecular (of course infeasible)
    • total discrete (each nameable part fully specified)
    • mechanical
    • visual
    • collision (parametrized by precision)
    • bounding box

I could imagine

class Thing:
  def lod_zoom_out() -> Thing: # Creates another Thing representing the same but with rougher LOD.
  def lod(which:LOD_ENUM) -> Thing: # Creates another Thing representing the same but with rougher LOD.
class Dynamixel (Thing):
  THING_LOD = Thing.Visual # Class variable defines which Level of Detail (LOD) this class specifies.
class Dynamixel_collision (Dynamixel):
  THING_LOD = Thing.Collision

Variable LoD via Lazy Evaluation?

Given component will have all the level of detail declared as attributes to the fullest detail. However, the attributes will not be computed until accessed. Then, such parts will be cached. One big issue: How to address the macroscopic properties like mass or inertia tensor? It can be either declared ad-hoc or based on rough model, but it would not match the finest-detail computation which is, however, expensive.

Moreover, how to address automated graph traversal, when to cut the recursion?

Generalized Interfaces.

It is feasible to attach a Thing only at particular locations. Such attachments often require some degree of consistency, e.g., you cannot fit M4 screw to M2 hole. Or, you may attach a wheel to a rod only one way, not to collide with the car. An interface would be a mechanism to assert such constraints, perhaps both on declarative (logical) level and on geometic level (not colliding). Maybe even basic mechanical properties might be checked?

Programatically, an interface might be a nestesd class instance compatible with bd.Location, moreover checking whatever needs to be checked. It sounds to me like a generalization of current Mount point mechanism.

Interaface declares

  • where (reference location)
  • how (type of supported relative motion)
  • what (compatibility, logical or spatial constraints)

Constraints.

Augment the current assembly tree with constraints which turn it into a generic graph. Constraints may be simply listed in some global registry? (Plus, do we need some global registry of Things?)

Allow designer to provide collision models.

(See also level-of-detail task.)

  • Find a way to inject specific to_mjcf overridings or adjustments, providing collision boxes and such.
  • A simple way would be having to_mjcf methods.
  • Nicer way might be extending the singledispatch.

Improve Inertia Matrices computation.

Currently, a nasty hack is created: A library is used to voxelize the Thing and consequenly compute the inertia there.

Implementation possibilities.

Improve and Enhance Material Class.

The class would carry all relevant macroscopic material properties, useful for subsequent simulations...

Pack as a NIX package.

NIX is cool.

Unit analysis libraries

Unfortunately, the library is not written in strongly typed language like C++ where unit conversion would be a piece of cake. So far, the library assumes a generic single unit of measure, typically millimeters. However, it would be great if any unit of measure could work. Altough I found Python libraries for this purpose, still, after all, I gave up for now.

Manufacturing Hints.

An annotation which states, e.g., how the Thing should be 3D printed, from which material, ...

GUI with explicit dependency and reference geometry visualization and management.