sbarthelemy / arboris-python Goto Github PK

joints with limits are modelled by an instance of joints.LinearConfigurationSpaceJoint (for the parametrization and the integration) and an instance of constraints.JointLimits (for the limits...).

These two class may be merged, to make the implementation simpler.

pro:

• easier to implement (no more need for init())
• easier for user (fewer names for the user), however a factory could also handle this
• in real world, joints work that way

con:

• yet another multiple inheritance
• the two algorithm are distinct

Currently the visu is hard to extend because :

1. the WorldDrawer is quite complicated, and there is no well defined way to add custom data to it
   • we could dispatch its data in the osg graph (in UserData fields) instead
2. there is no way to add custom code (like: draw and update a force)
   • we could add arboris-defined callbacks
   • we could use osg-defined callback (this would make our code more similar to (and compatible with) the osgAnimate one)
3. the Viewer (especially the KeyboardHandler) is hard to extend
   • maybe we could support several KeyboardHandlers (simultaneously)
4. There is no well defined way for the viewer to modify the simulation
   • add support for kinematic (0-order) joints ?
   • allow to move subframes whose parent is ground ?

states are positions and (sometimes) velocities. Velocities are already grouped in World._gvel and thus easy to manipulate, but positions are scattered through the joints.

We should probably provide a better way to handle them. It would be useful when saving trajectories too.

In some case, several joints are couple (Nao's hip is an example), it is probably possible to support this situation.

this would be useful for creating reduce the complexity of some models (creating a planar model for instance).

An alternative solution would be to make the locked joints stateless as stated in #9

When a box and a point are in contact, the normal computation fails. The math should be changed.

http://groups.google.com/group/arboris-devel/browse_thread/thread/5ba807045059be89

There several small cleanups that could be done but would break compatibility.
Better to discuss them here and perform all of them at the same time.

1. rename World.iterbodies to World.bodies
2. remove World.getbodies (doing NamedObjectsList(World.bodies)) is easy enough
3. remove robots/simpleshapes.py. They are only used for tests and not flexible enough for other uses
4. change the extension of the doc files from rst to txt

setup.py imports a cython module, which fails if cython is not available.

As the number of options grow, the keyboard shortcuts one has to remind grows too. Having a menu system in the browser would help circumvent this problem.

displaying a grid would be useful to:

• have a perception of the ground level and the vertical direction
• have perception of the distance

However this would add more parameters to tune:

• the size of the grid
• the spacing of the grid

and in many cases a shapes.Box would still be needed for collisions with the ground, and would hide the grid.

a grid with adjustable spacing would be useful to improve space perception of the ground

Here is an example of WorldObserver that tries to pickle world at each simulation timestep

#import cPickle as pickle
import pickle

class WorldPickler(WorldObserver):
    def __init__(self, world, file):
        self._file = open(file, 'wb')
        self._dumps = []
        self._world = world

    def init(self):
        pass

    def update(self, dt):
        world = self._world
        self._dumps.append(cPickle.dumps(world, protocol=-1))

    def finish(self):
        pickle.dump(self._dumps, self._file, protocol=-1)

However, it fails with this error:

pickle.PicklingError: Can't pickle <type 'instancemethod'>: it's not found as __builtin__.instancemethod

Currently, gravity is handled as an additional force, in a dedicated controller. It could be computed more efficiently as an acceleration offset, acting on a FreeJointWithGravity joint.

currently, a user can mess everything when setting a world state.

For instance joint.gvel[0] = 2. is ok, but joint.gvel = 2. is not, as it breaks the link between joint.gvel and world.gvel. The same problem occurs with joint.gpos.

maybe joint.gvel should be removed completely, as it is redundant with world.gvel. Currently, joint.gvel is used...

• in joint.integrate(), but it could be passed as an argument to integrate.
• to set the joint initial conditions. This could be done with world.gvel[joint.dof] = ...
• in joint.twist, which is itself called in Body.update_dynamic(). It's less easy to remove it from there.

Note also that we do not povide a joint.gforce interface, which could be useful and seem logical as long as there is joint.gvel.

The JointsList class is an attemps to provide a nicer interface. It currently provides

• joints.dof (a 1d array or a slice)
• joints.gvel (a 1d array wich is a copy of the selected joints gvels)
• joints.gpos (a 1d array wich is a copy of the selected joints gpos if they are 1d)

maybe the gvel and gpos should be dropped, or moved in another class (such as a per-robot one: human36, ...)).

For reference, KDL has a different approach: they have a single joint class that handles all the (1dof) joints, and which does not store the joint state at all.

Currently the GS algorithm stops after 20 iterations, this may be not enough or too much, we should change that.

Joints are used to

• parametrise the world
• restrict the relative motion between two bodies

For example, for RzJoint only allows rotations around z-axis. To specify the z-axis position relatively to the bodies, SubFrames are needed in most cases.

We could remove this need be replacing RzJoint with H0RzJoint or RzH0Joint, where H0 is a constant transform.

Doing so would have advantages:

• fewer SubFrame objects in many cases,
• many other formalisms/simulators work that way (DH parameters/HuMAnS/KDL...), it is good if arboris can accommodate their frame choices,
• this would not break the way arboris currently works (it could be implemented by adding H0 to the current joints with a eye(3) default value)

and some disadvantages...

• yet another way to do the same thing
• it we add this to the current method, it will be slower (one more matrix product). We can avoid this additional product if we know that the Joint _frame attributes are Body and not SubFrame, but it would be less flexible then.
• it will break the "link" display in visu_osg

Presently, the add_{robot} function anchor the robot at "world.ground".

We should add a parameter "frame" where the first joint will be anchored. "frame" would default to "world.ground"

this would mean adding an 'up' vector to the world

human36 module is a mess that should be cleaned.

using named tuples (from the collections module) might help

The code structure allow support for non-hlonomic joints such as wheel on a plane, however, no joint of this king is implemented yet.

We could

1. select a joint by clicking on it (or on its child body)
2. move it forward/backward with the keyboard