romelaucla/robot-player

A wrapper library with simple, easy-to-use interfaces for controlling robots.

robot-player's Issues

send option isn't documented anywhere

send=True is used in the vrep interface to advance to the next timestep at the conclusion of the command.

This feature isn't documented anywhere.

Here is the function in question from vrep_interface.py:

    def set_command_position(self, ids, commands, send=False):
        for i,c in zip(ids,commands):
            vrep.simxSetJointTargetPosition(self._sim_Client_ID, self.joint[i]['sim_handle'], c,
                                            vrep.simx_opmode_oneshot)
        if send:
            self.send_command()

setting vrep to use simx_opmode_blocking vs. simx_opmode_streaming

Not sure if it's possible to do this easily since vrep should do all of this stuff during its initialization phase. Can put this in the initialization step of the VrepInterface.

ensure that id and command list lengths are the same in joint commands.

Currently, lists are zipped together. Zip fails silently if the lists are not the same length.

Some commands where this is an issue:

set_command_position, set_joint_velocity, set_joint_effort in vrep_interface.py

For example this snippet fails silently if the lists for ids and commands doesn't have the same length.

    def set_command_position(self, ids, commands, send=False):
        for i,c in zip(ids,commands):
            vrep.simxSetJointTargetPosition(self._sim_Client_ID, self.joint[i]['sim_handle'], c,
                                            vrep.simx_opmode_oneshot)
        if send:
            self.send_command()

Duplicate key in dxl_control_table DXLPRO

The key L54_30_S500_R appears twice in the resolution dictionary for DXLPRO and with two different values.

dxl_interface needs to be tested for compatibility and tests written.

after removing dxl_interface from rf, there's bound to be a few compatibility issues.

Perhaps a good compatibility test would be moving the peble codebase to use robot_player instead of rf.

motion manager should be the only thing needed to import

Motion Manager currently requires users to instantiate their own Interface, then give it to the Motion Manager as an argument. I think there's a good argument to be made for just having users give a preset bunch of arguments to the motion manager instead and just letting the motion manager handle all of that.

Defining a .shape for jit compilation could lead to unexpected behavior

In order to use jit, all returned vectors must have a defined np.shape. This means that vector objects do not really exist and everything is a matrix. Where previously we would have returned a generic (3,) vector, we now have to return either a (3,1) or (1,3) column or row vector (which is actually a mattrix)

This becomes a problem because we used to be able to return a vector V = [v_x, v_y, v_z] with dimension (3,) such that V[0] == v_x

Now, this same vector would be V = [[v_x, v_y, v_z]] with dimension (1,3) such that V[0] == [v_x, v_y, v_z]. This will lead to problems down the line when we index a supposed vector expecting to get a scalar value but actually get another vector.

A possible workaround is to wrap the jit compiled functions which return generic vectors in a decorator which would reshape the return from (1,3) or (3,1) to just (3,). This would mean that no adjustments need be made to the driver code and we can continue using the functions as before.

dxl interface needs to have velocity and torque control methods

dxl interface could use velocity and torque control methods, as well as a generic "write anything, read anything method".

Some motion_manager functions have not been implemented for DXL

Functions that don't have a DXL implementation yet:

• get_joint_velocity
• set_joint_velocity
• set_all_joint_velocity
• set_joint_effort
• set_all_joint_effort
• get_joint_effort
• get_all_join_effort

all marked with TODOs

motion_manager.set_goal_effort() requires stall and dxl arguments but they have no analogue in vrep

they should probably be made optional keyword arguments that can be passed down to the DxlInterface class instead of required arguments. You can use the **kwargs to pass down arbitrary arguments to functions.

to reproduce:
open data/vrep/test_single_joint.ttt
run robot_player/test/test_vrep_single_joint.py

Traceback (most recent call last):
File "/home/dsun/Dropbox/Programs/Python/robot-player/tests/test_vrep_single_joint.py", line 14, in
mm.set_goal_effort([1], [70], send=True)
TypeError: set_goal_effort() missing 2 required positional arguments: 'stall' and 'dxl'

Map joint names from a list

Most URDFs don't have joint names given as 'jointX', which is the preferred convention for this library. Possibly consider adding a feature to accept a joint name mapping that is converted internally for usage?

remove 'all' commands

Just realized that we could potentially cut down on the function length by changing the id parameter to be an optional keyword argument and have the function figure things out automatically.

It's an option, not necessarily a good one.

Incomplete or missing docstrings in motion_manager

• init has no parameter "player"
• to_player_angle_offset has no parameter "q"
• to_player_angle_offset missing parameter "angles"
• from_player_angle_offset missing parameter "angles"
• setters and getters, wait, torque_on/off, and advance_timestep have no official docstrings, just comments

Enable streaming commands in vrep_interface

Using blocking commands tends to take a really long time, with the benefit of always having up-to-date data. Try enabling streaming commands to make this easier.

test_single_joint.py throws an error in certain conditions

I was able to run the vrep test_single_joint.py just fine when clicking run or debug directly in pycharm. It also works fine when I run it from my command prompt. But when I run it through the pycharm terminal, it throws the error below

Traceback (most recent call last):
  File "tests\test_single_joint.py", line 11, in <module>
    print(mm.get_all_joint_effort())
IOError: [Errno 0] Error

This is very strange behavior.