Refactor/clean the xml

[stimpfli]

• Explore the usage of multi dog joints
• Clarify the relationship between dof sequence and inverse kinematics:
  • Either make it flexible to using any sequence
  • Or write script to change the order
• Remove actuators and cameras and initialise them in init()
• Check that simulation parameters are fully relevant
• Check that body, joint, inertial and geom parameters make sense

[stepanove]

According to the docs, all those dummy bodies (like *Coxa_roll/yaw) where multiple DOFs are required can be just removed

When a joint is defined inside a body, its function is not to connect the parent and child but rather to create motion degrees of freedom between them. If no joints are defined within a given body, that body is welded to its parent. A body in MJCF can contain multiple joints, thus there is no need to introduce dummy bodies for creating composite joints. Instead simply define all the primitive joints that form the desired composite joint within the same body. For example, two sliders and one hinge can be used to model a body moving in a plane.

https://mujoco.readthedocs.io/en/stable/modeling.html#kinematic-tree

[stepanove]

In theory, cameras and actuators can be moved to separate XML files and then included, but for the actuators it would require to have joints names fixed.

include (*)
This element does not strictly belong to MJCF. Instead it is a meta-element, used to assemble multiple XML files in a single document object model (DOM) before parsing. The included file must be a valid XML file with a unique top-level element. This top-level element is removed by the parser, and the elements below it are inserted at the location of the include element. At least one element must be inserted as a result of this procedure. The include element can be used where ever an XML element is expected in the MJCF file. Nested includes are allowed, however a given XML file can be included at most once in the entire model. After all the included XML files have been assembled into a single DOM, it must correspond to a valid MJCF model. Other than that, it is up to the user to decide how to use includes and how to modularize large files if desired.

https://mujoco.readthedocs.io/en/stable/XMLreference.html#include

[stepanove]

MuJoCo has a powerful mechanism for specifying default values to almost anything On one hand it makes XML file much less cluttered, but on the other hand it can be difficult to keep track of this tree of default classes in a large file, having everything defined explicitly in-place has its own benefits as well.
https://mujoco.readthedocs.io/en/stable/modeling.html#default-settings

For example, dm_control quadruped example made me totally confused when I looked at it for the first time :)
https://github.com/google-deepmind/dm_control/blob/main/dm_control/suite/quadruped.xml

Also it might be just a waste of time if you are ever going to import an updated model or something like this.
It might be beneficial to have the model file not human readable/editable but rely on some external tools like FARMS blender or something like this.