error in testRNEA_iCub_load.m

[iron76]

I am running testRNEA_iCub_load.m using the drake-binary downloaded here. I am getting this error at opening the URDF file. A very similar error is obtained when launching testRNEA_URDF_load.m

Error using assert
Too many input arguments.

Error in DrakeSystem/addStateConstraint (line 365)
assert(con.xdim == length(xind),'DrakeSystem:InvalidStateConstraint','xdim mismatch');

Error in Manipulator/setJointLimits (line 497)
[obj,id] = addStateConstraint(obj,con,1:obj.getNumPositions);

Error in RigidBodyManipulator/setJointLimits (line 305)
obj = setJointLimits@Manipulator(obj,jl_min,jl_max);

Error in RigidBodyManipulator/compile (line 751)
model = model.setJointLimits([model.body.joint_limit_min]',[model.body.joint_limit_max]');

Error in RigidBodyManipulator/addRobotFromURDF (line 58)
model = compile(model); % ideally this would happen on entry into any function...

Error in RigidBodyManipulator (line 58)
obj = addRobotFromURDF(obj,urdf_filename,zeros(3,1),zeros(3,1),options);

Error in testRNEA_iCub_load (line 23)
R = RigidBodyManipulator([robotPath,filesep,robotName,'.urdf']);

[iron76]

The issue is related to different versions in the featherstone toolbox. Drake is using Spatial Vector and Rigid Body Dynamics Software (version 1), actually it contains a copy of the toolbox itself. Our software, bnt_time_varying, requires version 2. If both toolboxes are in the matlab path the above error occurs. If only the version 1 is in the path another error occurs:

Undefined function 'get_gravity' for input arguments of type 'struct'.

Error in model (line 42)
a.g = get_gravity(modelParams);

Error in testRNEA_iCub_load (line 51)
myModel = model(dmodel);

This second error occurs since the function get_gravity is in featherstone version 2 but not in version 1. There are different workarounds possible, I leave the implementation of a clean solution to @naveenoid.

[iron76]

cec1ddf has a workaround on this issue. The workaround is useful only if you are trying to parse the urdf of the iCub. The workaround consists in a matlab script (tests/icub_tests/iCub.m) which creates a featherstone-like model, as obtained by the drake urdf-parser. This workaround does not need to install the drake dependency, which is still needed to obtain a featherstone-like model from an urdf file.

[naveenoid]

The workaround I tried was to simply unload Drake as soon as the URDF
is loaded into the featherstone structure. This however still misses
some components such as jtype and appearence nodes that are essential.
This was implemented in the lines 36,40,41,42 of the
testRNEA_iCub_load.m file. Please verify that this form is
insufficient. This seems a temporary cleaner solution to extracting
and creating a .m

Perhaps another alternative is timedated dump of a mat file storing
the RigidBody struct from a URDF pass as opposed to a m file.

Cheers,

Naveen

Naveen Kuppuswamy, PhD
Post-doctoral Fellow,
Cognitive Humanoids Lab,
Department of Robotics, Brain and Cognitive Sciences (RBCS),
Istituto Italiano di Tecnologia, Genova, Italy

On Mon, Jan 5, 2015 at 4:38 PM, Francesco Nori notifications@github.com wrote:

cec1ddf has a workaround on this issue. The workaround is useful only if you
are trying to parse the urdf of the iCub. The workaround consists in a
matlab script (tests/icub_tests/iCub.m) which creates a featherstone-like
model, as obtained by the drake urdf-parser. This workaround does not need
to install the drake dependency, which is still needed to obtain a
featherstone-like model from an urdf file.

—
Reply to this email directly or view it on GitHub.

[iron76]

The testRNEA_iCub_load.m currently in repository is not working. The thing is, bnt_time_varying requires spatial_v2. Drake requires spatial_v1. The current code loads drake (and therefore the associated spatial_v1) by calling addpath_drake. The code either fails at line 23 (if spatial_v2 is loaded) or at line 51 (if spatial_v2 is not loaded). The only possibility I see is loading spatial_v2 just after unloading drake. However, I don't like this solution and I don't even like the current solution. The reason is: the code should not contain user dependent configurations (in this case the path to drake currently at line 6). We should find a cleaner solution.

[traversaro]

cc @claudia-lat

[naveenoid]

We could fork the loading api in drake and update that in our repo...

---

Naveen Kuppuswamy, PhD
Post-doctoral Fellow,
Cognitive Humanoids Lab,
Department of Robotics, Brain and Cognitive Sciences (RBCS),
Istituto Italiano di Tecnologia, Genova, Italy

On Fri, Jul 31, 2015 at 12:51 PM, Silvio Traversaro <
notifications@github.com> wrote:

cc @claudia-lat https://github.com/claudia-lat

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[traversaro]

👍