robotlocomotion / drake Goto Github PK

Hello Russ,

I have a problem during the getting started/installation process of drake on my mac book retina running mavericks 10.9.2 and matlab 2014a, I hope you can help me with. In short:

running ‘make' in the 'drake-distro' folder compiles fine until ‘drake’ itself has to be compiled - this is the console error output for the drake portion:

-- drake

BUILD_PREFIX: /Users/rkk/drake-distro/build

CMake Error at cmake/mex.cmake:11 (string):
string sub-command STRIP requires two arguments.
Call Stack (most recent call first):
cmake/mex.cmake:56 (get_mex_option)
cmake/mex.cmake:199 (mex_setup)
CMakeLists.txt:38 (include)

-- compiler1 version string:

-- compiler2 version string:
4.2.1
CMake Error at cmake/mex.cmake:203 (message):
Your cmake C compiler is: /usr/bin/cc but your mex options use: . Consider
rerunning 'mex -setup' in Matlab.
Call Stack (most recent call first):
CMakeLists.txt:38 (include)

-- Configuring incomplete, errors occurred!
See also "/Users/rkk/drake-distro/drake/pod-build/CMakeFiles/CMakeOutput.log".
make[2]: *** [configure] Error 1
make[1]: *** [pod-build/Makefile] Error 2
make: *** [all] Error 2

——

I ran 'mex -setup' in Matlab, also for C++ and FORTRAN, but it does not fix the problem,.

In long, these are the steps I did before:
I followed the guide on: https://github.com/RobotLocomotion/drake/wiki/Installation-and-Quickstart

• cloned the 'rigid body' distro version from git
• using homebrew (already installed
• updated home-brew
• running ‘make install_prereqs_homebrew’ inside drake-distro folder, I get these warnings:
  30-6-159:drake-distro rkk$ make install_prereqs_homebrew
  Warning: cmake-2.8.12.2 already installed
  Warning: gtk+-2.24.22 already installed
  Warning: glib-2.38.2 already installed
  Warning: coreutils-8.22 already installed
  Warning: cmake-2.8.12.2 already installed
  Warning: gtk+-2.24.22 already installed
  make[1]: *** No rule to make target install_prereqs_homebrew'. Stop. Warning: gnu-sed-4.2.2 already installed Warning: gfortran-4.8.2 already installed Warning: gfortran-4.8.2 already installed make[2]: *** No rule to make targetinstall_prereqs_homebrew'. Stop.
  make[1]: *** [install_prereqs_homebrew] Error 2
  Warning: boost-1.55.0 already installed
  Warning: graphviz-2.36.0 already installed

alright I moved on, I am using bash, so my '~/.profile' looks like this:
export MATLAB_JAVA=/Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
export PKG_CONFIG_PATH=:/opt/X11/lib/pkgconfig:/opt/X11/lib/pkgconfig:/opt/X11/lib/pkgconfig

I added the second line is according to your guide. The first line is needed so that my matlab R2014a displays correctly on my retina mac book (using newer JRE - mine is version 7 update 51). Matlab uses an older builtin java version, which does not support the retina resolution.

My matlab version is:

MATLAB Version: 8.3.0.532 (R2014a)
MATLAB License Number: 650667
Operating System: Mac OS X Version: 10.9.2 Build: 13C64

Java Version: Java 1.7.0_11-b21 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode

MATLAB Version 8.3 (R2014a)
Simulink Version 8.3 (R2014a)
Aerospace Blockset Version 3.13 (R2014a)
Aerospace Toolbox Version 2.13 (R2014a)
Bioinformatics Toolbox Version 4.4 (R2014a)
Communications System Toolbox Version 5.6 (R2014a)
Computer Vision System Toolbox Version 6.0 (R2014a)
Control System Toolbox Version 9.7 (R2014a)
Curve Fitting Toolbox Version 3.4.1 (R2014a)
DSP System Toolbox Version 8.6 (R2014a)
Database Toolbox Version 5.1 (R2014a)
Datafeed Toolbox Version 4.7 (R2014a)
Econometrics Toolbox Version 3.0 (R2014a)
Embedded Coder Version 6.6 (R2014a)
Filter Design HDL Coder Version 2.9.5 (R2014a)
Financial Instruments Toolbox Version 1.3 (R2014a)
Financial Toolbox Version 5.3 (R2014a)
Fixed-Point Designer Version 4.2 (R2014a)
Fuzzy Logic Toolbox Version 2.2.19 (R2014a)
Global Optimization Toolbox Version 3.2.5 (R2014a)
Image Acquisition Toolbox Version 4.7 (R2014a)
Image Processing Toolbox Version 9.0 (R2014a)
Instrument Control Toolbox Version 3.5 (R2014a)
LTE System Toolbox Version 1.1 (R2014a)
MATLAB Builder JA Version 2.3.1 (R2014a)
MATLAB Coder Version 2.6 (R2014a)
MATLAB Compiler Version 5.1 (R2014a)
MATLAB Report Generator Version 3.16 (R2014a)
Mapping Toolbox Version 4.0.1 (R2014a)
Model Predictive Control Toolbox Version 4.2 (R2014a)
Neural Network Toolbox Version 8.2 (R2014a)
Optimization Toolbox Version 7.0 (R2014a)
Parallel Computing Toolbox Version 6.4 (R2014a)
Partial Differential Equation Toolbox Version 1.4 (R2014a)
RF Toolbox Version 2.14 (R2014a)
Robust Control Toolbox Version 5.1 (R2014a)
Signal Processing Toolbox Version 6.21 (R2014a)
SimBiology Version 5.0 (R2014a)
SimDriveline Version 2.6 (R2014a)
SimElectronics Version 2.5 (R2014a)
SimEvents Version 4.3.2 (R2014a)
SimHydraulics Version 1.14 (R2014a)
SimMechanics Version 4.4 (R2014a)
SimPowerSystems Version 6.1 (R2014a)
Simscape Version 3.11 (R2014a)
Simulink 3D Animation Version 7.1 (R2014a)
Simulink Coder Version 8.6 (R2014a)
Simulink Control Design Version 4.0 (R2014a)
Simulink Design Optimization Version 2.5 (R2014a)
Simulink Report Generator Version 3.16 (R2014a)
Simulink Verification and Validation Version 3.7 (R2014a)
Stateflow Version 8.3 (R2014a)
Statistics Toolbox Version 9.0 (R2014a)
Symbolic Math Toolbox Version 6.0 (R2014a)
System Identification Toolbox Version 9.0 (R2014a)
Wavelet Toolbox Version 4.13 (R2014a)

• I added matlab to the path by setting up:
  sudo ln -s /Applications/MATLAB_R2014a.app/bin/matlab /usr/bin
• When I then cd into the collection and run make, the error I described in the beginning occurs.

Thank you for your help,

Is there a bug tracking page I should add this request to?

Bye
Robert Katzschmann

When creating the rigid body object from a URDF file, drake replaces a sphere with a point-mass at its center. This causes two problems at other stages:

• The drake's built-in 2D visualizer does not show the sphere.
• Collision does not occur until the sphere's center reaches the ground (sphere penetrates to the ground)

Javad

this has been on our todo list for a while, but my mind wandered on my run in this morning, and I think i figured out the right interface:

in RBM, we should have a method

function v = flowField(obj, t, x, u)
v = zeros(3,1);
% and eventually, something like:
% for i=1:length(obj.additive_flow_generators)
% v = v + flowField(obj.additive_flow_generator{i},t,x,u);
end

The rigid body wing class should call flowField at the aerodynamic center, and add the contribution to the body speed before calculating the aoa.

As forecasted above we could add an additional interface for RigidBodyAdditiveFlowGenerators. For example, a RigidBodyPropellor would derive from RigidBodyThrust and RigidBodyAdditiveFlowGenerator, and be able to add terms for backwash.

I like this interface because in general the flow could be part of the state, or not; it could be an external input (e.g. in a wind tunnel), or it could even be a disturbance. It would also be easy to implement more complex things by implementing this method in a derived class.

A position-controlled control surface that is massless could be supported in the URDF the same way we do wings with a force_element. Instead of a wing inner tag, the force_element would have a control_surface inner tag. The control_surface would have the same attribute as the wing (chord,nominal_speed,profile,span, stall_angle). The main difference is that the parent link of the force_element would not be the link corresponding to the control surface itself, but of its actual parent (for example the parent of an aileron would be the wing link).

Then in the parser, instead of creating a RigidBodyWing, we create a RigidBodyControlSurface which is a child class of RigidBodyWing. RigidBodyControlSurface inherits all of the methods of RigidBodyWing and only needs to override computeSpatialForce. computeSpatialForce does the following:

-Forward kinematics of the RBM (which doesn't include any control surface)
-Forward kinematics of the control surface only
-Compute aerodynamic force on the control surface
-Returns the force as an external force

Now the problem with this approach is in computing the forward kinematic of the control surface. This depends on the input, which we don't have access to from inside computeSpatialForce (we only have access to the state). Any suggestions?

Dear Authors,

After building Drake out of source in Ubuntu 12.04, I tried to run some example scripts such as runLQR.m under \Quadrotor2D. However it complained about some errors as below. Do you know what's the problem?

regards,
Lei
Email: [email protected]

runLQR

SeDuMi not found. SeDuMi support will be disabled.
To re-enable, add SeDuMi to your matlab path and rerun addpath_drake.
SeDuMi can be downloaded for free from http://sedumi.ie.lehigh.edu/

Undefined function 'lqr' for input arguments of type 'double'.

Error in DynamicalSystem/tilqr (line 94)
[K,S] = lqr(full(A),full(B),Q,R,options.N);

Error in PlanarQuadPlant/hoverLQR (line 52)
c = tilqr(obj,x0,u0,Q,R);

Error in runLQR (line 35)
c = hoverLQR(p);

When cloning the repo as suggested:

git clone https://github.com/RobotLocomotion/drake-distro.git --recursive -b rigidbody

I got this error message (when cloning the spotless repo):

Cloning into 'spotless'...
remote: Reusing existing pack: 1253, done.
remote: Total 1253 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (1253/1253), 766.05 KiB | 540 KiB/s, done.
Resolving deltas: 100% (458/458), done.
fatal: reference is not a tree: 1c0097d58bd92aec62438cc88e3b5ef60b0b5cca
Unable to checkout '1c0097d58bd92aec62438cc88e3b5ef60b0b5cca' in submodule path 'spotless'
Cloning into 'xfoil'...
remote: Reusing existing pack: 281, done.
remote: Total 281 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (281/281), 3.85 MiB | 1.40 MiB/s, done.
Resolving deltas: 100% (41/41), done.
Submodule path 'xfoil': checked out '328a3c2a7410174c2b3863adaf0694d66894a817'
Failed to recurse into submodule path 'spotless'

Any ideas about how to solve this?

Thanks!

The URDF file is being stored in https://svn.csail.mit.edu/locomotion/robots/LittleDog/trunk/littledog.urdf

r = RigidBodyManipulator('/Users/shafi/Desktop/Robot Locomotion/littledog.urdf')

r =

RigidBodyManipulator with properties:

                    name: {''}
                    urdf: {[1x52 char]}
                    body: [1x13 RigidBody]
                actuator: []
                param_db: {}
                    loop: []
                  sensor: {}
                   force: {}
                 gravity: [3x1 double]
                     dim: 3
                 terrain: [1x1 RigidBodyTerrain]
                   frame: []
            featherstone: [1x1 struct]
                       B: [12x0 double]
           mex_model_ptr: 0
                   dirty: 0
 collision_filter_groups: [2x1 containers.Map]
num_position_constraints: 0
num_velocity_constraints: 0
         joint_limit_min: [12x1 double]
         joint_limit_max: [12x1 double]
            num_contacts: 0
                   num_q: 12
                    umin: [0x1 double]
                    umax: [0x1 double]

v = constructVisualizer(r)
Warning: can't find drake_viewer executable. you might need to run make
(from the shell). note: BotVisualizer is not supported on windows yet
In RigidBodyManipulator.RigidBodyManipulator>RigidBodyManipulator.constructVisualizer at 864

v =

RigidBodyWRLVisualizer with properties:

    display_dt: 0
playback_speed: 1
     draw_axes: 0
  display_time: 0
          axis: []
        fignum: 25
          umin: [24x1 double]
          umax: [24x1 double]

v.inspector
Error using horzcat
Dimensions of matrices being concatenated are not consistent.

Error in Visualizer/inspector (line 209)
label{i} =
uicontrol('Style','text','String',getCoordinateName(fr,state_dims(i)),
...

Error in RigidBodyWRLVisualizer/inspector (line 92)
inspector@Visualizer(obj,x0,state_dims,minrange,maxrange);

The changes made to the output method of TimeStepingRigidBodyManipulator in d25aeea break that method for manipulators that don't have MultiCoordinateFrame objects for their state frames. Running output for these manipulators yields errors that complain about splitCoordinates not being a method of the state frame.

FYI - I am looking into this. Most things appear to work via cygwin, but the windows version of matlab appears to not support the "-n" command line option, which I was relying on to extract the mex configuration for building directly from cmake. I have contacted mathworks to see if there is a reasonable alternative.

Note that I did have to manually install java's jdk and manually add the matlab/bin directory and jdk directories to my path. I also manually installed the Microsoft SDK 7.1 since I didn't have another matlab supported compiler installed yet.

Note: do not install cmake from cygwin. install it separately (see below).
Note: do install git from cygwin, not separately.

Cylinders render as tubes.

When using time stepping mode to simulate a fixed-base model that includes collision properties (model is defined by a urdf file) Drake crashes. This problem does not occur when switching to floating-base or removing the collision field in the urdf file. Note: I use the Windows distribution. A sample minimal code is provided below.

The first few lines of the error message:

DrakeSystem S-Function: error when calling ''getInitialState'' with the following arguments:
TimeSteppingRigidBodyManipulator with properties:

        timestep: 1.000000000000000e-03
            twoD: 0
position_control: 0
            umin: [0x1 double]
            umax: [0x1 double]

Minimal urdf file:

<?xml version="1.0"?>

<robot name="SimplePendulum">
  <material name="red">
    <color rgba=".9 .1 0 1" />
  </material>
  <link name="world">
  </link>
  <link name="upper_link">
    <inertial> 
      <origin xyz="0 0 -0.5" rpy="0 0 0" />
      <mass value="1" />
      <inertia ixx="0.083" ixy="0" ixz="0" iyy="0.083" iyz="0" izz="0.0001"/> 
    </inertial>
    <visual>
      <origin xyz="0 0 -.5" rpy="0 0 0" />
      <geometry>
         <cylinder length="1" radius=".01" />
      </geometry>
      <material name="red" />
    </visual> 
    <collision>
      <origin xyz="0 0 -0.5" rpy="0 0 0" />
      <geometry>
         <cylinder length="1" radius=".01" />
      </geometry>
    </collision>
  </link>
  <joint name="shoulder" type="continuous">
    <origin xyz="0 0 0" />
    <parent link="world"/>
    <child link="upper_link" />
    <axis xyz="0 1 0" />
    <dynamics damping="0.1" />
  </joint>
</robot>

MATLAB code:

    clc;
    close all;

    options = [];
    r = TimeSteppingRigidBodyManipulator('SimplePendulum.urdf', 0.001,options);        
    TimeSpan = [0 1];
    x0 = [ 0; 0 ];        
    xtraj = simulate(r,TimeSpan,x0);        
    v = r.constructVisualizer();
    v.playback(xtraj,struct('slider',true));

When using URDFRigidBodyManipulator, there is a warning printed to the terminal at least a hundred times for certain urdf files:

Warning: mesh collision elements are not supported in URDFRigidBodyManipulator yet.

The warning is printed from URDFRigidBodyManipulator.cpp line 341. Would it be ok to comment out this warning for now?

Using Ubuntu 12.04 with Matlab r2014A
In mex.cmake:get_cmake_option, when cutting from the mex -v output, the equal sign "=" is replaced by colon ":" under this setup. EX.

Options file details

Compiler location: /usr/bin/gcc
Options file: /home/ac/.matlab/R2014a/mex_C_glnxa64.xml
CMDLINE1 : /usr/bin/gcc -c -DMX_COMPAT_32   -D_GNU_SOURCE -DMATLAB_MEX_FILE  -I"/usr/local/MATLAB/R2014a/extern/include" -I"/usr/local/MATLAB/R2014a/simulink/include" -ansi -fexceptions -fPIC -fno-omit-frame-pointer -pthread -O -DNDEBUG /home/ac/Desktop/TedrakeChallenge/drake-distro/drake/yprime.c -o /tmp/mex_90406700164_27736/yprime.o
CMDLINE2 : /usr/bin/gcc -pthread -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2014a/bin/glnxa64 -shared  -O -Wl,--version-script,"/usr/local/MATLAB/R2014a/extern/lib/glnxa64/mexFunction.map" /tmp/mex_90406700164_27736/yprime.o   -L"/usr/local/MATLAB/R2014a/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++ -o yprime.mexa64
CMDLINE3 : rm -f /tmp/mex_90406700164_27736/yprime.o
CC : /usr/bin/gcc
DEFINES : -DMX_COMPAT_32   -D_GNU_SOURCE -DMATLAB_MEX_FILE 
MATLABMEX : -DMATLAB_MEX_FILE 
CFLAGS : -ansi -fexceptions -fPIC -fno-omit-frame-pointer -pthread
INCLUDE : -I"/usr/local/MATLAB/R2014a/extern/include" -I"/usr/local/MATLAB/R2014a/simulink/include"
COPTIMFLAGS : -O -DNDEBUG
CDEBUGFLAGS : -g
LD : /usr/bin/gcc
LDFLAGS : -pthread -Wl,--no-undefined -Wl,-rpath-link,/usr/local/MATLAB/R2014a/bin/glnxa64
LDTYPE : -shared 
LINKEXPORT : -Wl,--version-script,"/usr/local/MATLAB/R2014a/extern/lib/glnxa64/mexFunction.map"
LINKLIBS : -L"/usr/local/MATLAB/R2014a/bin/glnxa64" -lmx -lmex -lmat -lm -lstdc++
LDOPTIMFLAGS : -O
LDDEBUGFLAGS : -g
OBJEXT : .o
LDEXT : .mexa64
GCC : /usr/bin/gcc
CPPLIBS : /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.so
MATLABROOT : /usr/local/MATLAB/R2014a
ARCH : glnxa64
SRC : /home/ac/Desktop/TedrakeChallenge/drake-distro/drake/yprime.c
OBJ : /tmp/mex_90406700164_27736/yprime.o
OBJS : /tmp/mex_90406700164_27736/yprime.o 
SRCROOT : /home/ac/Desktop/TedrakeChallenge/drake-distro/drake/yprime
DEF : /tmp/mex_90406700164_27736/yprime.def
EXP : yprime.exp
LIB : yprime.lib
EXE : yprime.mexa64
ILK : yprime.ilk
MANIFEST : yprime.mexa64.manifest
TEMPNAME : yprime
EXEDIR : 
EXENAME : yprime
OPTIM : -O -DNDEBUG
LINKOPTIM : -O

http://kobol.csail.mit.edu/cd/testDetails.php?test=73995&build=5486

How can I change the friction coefficient between the ground and the object in floating base models described by a urdf file?

When I run any of the Hubo examples provided with the drake distributions I get the following error:

File Hubo_description/urdf/jaemiHubo_minimalcontact.urdf not found

Javad

If I use the "setSimulinkParam" method to set the ode solver in TimeStepping mode to anything other than ode1 (e.g. ode5), does Drake take that into effect or still uses the first order integration scheme?

Running testQP on a machine with Gurobi installed works under MATLAB R2012b, but yields the following under R2013b:

>> version

ans =

8.2.0.701 (R2013b)

>> addpath_drake
 Calling addpath_spotless
 Added the lcm jar to your javaclasspath (found via cmake)
>> checkDependency('gurobi')
 Calling addpath_gurobi

ans =

     1

>> cd solvers/test/
>> testQP
****************************************
 min_x (.5*x'*A*x + x)
****************************************
    solver        objval        exitflag   execution time
-------------------------------------------------------------
Warning: Your current settings will run a different algorithm (interior-point-convex) in a future release. 
> In quadprog at 375
  In QuadraticProgram>QuadraticProgram.solve at 61
  In NonlinearProgram>NonlinearProgram.compareSolvers at 199
  In QuadraticProgram>QuadraticProgram.compareSolvers at 98
  In testQP>testSolvers at 31
  In testQP at 10 
    quadprog      -0.141           1           0.2537

------------------------------------------------------------------------
       Segmentation violation detected at Tue Apr  1 09:59:09 2014
------------------------------------------------------------------------

using drake a8609e6

In the following test code, note the dim property changing.

>> p = PPTrajectory(spline(1:4,ones(4)));
>> p_indexed = p(:);
>> p

p = 

  PPTrajectory

  Properties:
         pp: [1x1 struct]
    mex_ptr: [1x1 SharedDataHandle]
        dim: 4
      tspan: [1 4]
       umin: []
       umax: []

>> p_indexed

p_indexed = 

  PPTrajectory

  Properties:
         pp: [1x1 struct]
    mex_ptr: [1x1 SharedDataHandle]
        dim: [4 1]
      tspan: [1 4]
       umin: []
       umax: []

>> size(eval(p, [0, 1]))

ans =

     4     2

>> size(eval(p_indexed, [0, 1]))

ans =

     4     1     2

findJointInd returns the index of the body that has the queried joint, not the index in the robot.getStateFrame.coordinates. @kuindersma and I misused this function last time by mistaken its usage for the latter. Maybe we should create a separate function findDoFInd to return the index in the robot.getStateFrame.coordinate? And add some documentation to findJointInd to clarify its usage?

In the final installation step, running make from the drake-distro directory, I am told that lcm is being downloaded, then the following error is thrown:

make[2]: wget: No such file or directory make[2]: *** [lcm-1.0.0/configure] Error 1 make[1]: *** [lcm-1.0.0/Makefile] Error 2 make: *** [all] Error 2

Thanks for the help!

Not sure how to reopen it, but I left a comment on the issue for:

TimeSteppingRigidBodyManipulator frame handling causes errors for sensorless manipulators

Russ,

I have tried a few simple examples and compared the results with MuJoCo. I have to say that I am very impressed by the accuracy of the results produced by Drake.

The only issue (within the capabilities of Drake) is the simulation time, especially when there are (potential) collisions. Is there any way to increase the speed without writing your dynamics in C?

• Javad

The solution, of course, is to implement the floating base with a non-degenerate coordinate system (e.g. quaternions). But this is painful for a number of reasons:

• it's not a minimal coordinate system, so all of the dependent analysis and feedback design methods have to reason about the extra constraint.
• it means that rigid body systems are not second order systems anymore. (and num_states ~= 2*num_dof). unfortunately this assumption is baked into a lot of places, so the change will have be applied carefully.

<matlab_test> (strcmp(error_id,'PathLCP:FailedToSolve') || ...
    (strcmp(error_id,'Simulink:SFunctions:SFcnErrorStatus') && (~isempty(strfind(test_output,'Path fails')) || ~isempty(strfind(test_output,'not finite')))) ...
  && any(strcmp(test_name,{'systems/plants/test/fallingBrickLCP', ...
          'systems/plants/test/fallingCapsulesTest',...
          'systems/plants/test/multiRobotTest', ...
          'systems/plants/test/momentumTest', ...
          'systems/plants/test/terrainTest', ...
          'systems/plants/test/terrainInterpTest', ...
          'systems/plants/test/testFloatingBaseDynamics', ...
          'examples/PR2/runPassive',...
          'examples/Quadrotor/Quadrotor.runOpenLoop', ...
          'examples/Quadrotor/test/testCollisions', ...
          'examples/ZMP/CartTable.run'})))</matlab_test>

This is due to changes in the input arguments of the ContactForceTorqueSensor introduced during the upgrade of RigidBodyFrames

I am simulating the motion of an object using TimeSteppingRigidBodyManipulator and I would like to see/calculate the ground reaction forces without calculating the accelerations by myself. It seems that the "ContactForceTorqueSensor" class and the "addSensor" method should give me the thing I need, but I could not fully interpret the output after using them. Could you provide some comments on this?

Furthermore, why the number of initial conditions should be increased when using "ContactForceTorqueSensor" class and the "addSensor" method (e.g. in the following piece of code, x0 should have 9 elements instead of 6=number of states, otherwise I get errors)

Here is the code I am using:

options = [];
options.floating = true;
options.twoD = true;
r = TimeSteppingRigidBodyManipulator('TopplingPencil.urdf', 1e-3, options);

r = addSensor(r,FullStateFeedbackSensor());
body = findLinkInd(r,'pencil');
frame = RigidBodyFrame(body,zeros(3,1),zeros(3,1),'FT_frame');
r = addFrame(r,frame);
r = addSensor(r,ContactForceTorqueSensor(r,frame));
r = compile(r);

tspan = [0 3];
x0 = [ 0;0;-theta0; 0;0;0; 0;0;0 ];
xtraj = simulate(r,tspan,x0);

Ani has an application which is the most recent that would benefit from the ability to change the root link of a urdf. The basic use case here is to take a floating base urdf which has made contact with the ground, and replace it with a new minimal model -- with the floating base severed and a new pin joint attaching the foot to the ground. Here is my proposed interface. Comments welcome.

function new_rbm = changeRootLink(rbm, link, xzy, rpy, options)
% Changes the root link of the kinematic tree. Note that the root link is static in the world.
%
% param rbm a RigidBodyManipulator object
% param link the name or index of the link that will become the root link
% param xyz location on link (in the link frame) for the new origin
% param rpy orientation on link (in the link frame) for the new origin
% option floating_base (default false)
%
% As always, any leaf nodes with zero inertia will be automatically removed. This will
% have the intended effect of removing any vestigial floating base joints from the
% original model.
%
% Example: attach the foot of a floating base manipulator to the ground.
% (to be fleshed out with the details)
% rbm = addLink(rbm, 'ground');
% rbm = addJoint(rbm,'foot','ground', ...);
% rbm = changeRootLink(rbm,'ground');

With a mid 2012 retina macbook pro running OS X 10.9, before and after reinstalling Homebrew, the installation of prerequisites runs into an error over a missing or broken directory. The command make install_prereqs_homebrew turns up an error. The script installs the gtk+ dependency gobject-introspection, then throws an error with the text /usr/local/opt/xz not present or broken. Please reinstall xz. Sorry :(.
Xquartz and Xcode are both installed on my machine.
Thanks in advance.

There are two bugs in the LCP solver when trying to get the gradients while having position control enabled.

Line 369: Dimensions don't match.
I think this can be fixed by changing line 258 to

dtau = [zeros(num_q,1), -dC, zeros(size(B))];

Line 392: dJL undefined.
I think this can be fixed by adding this on line 393

dJL = zeros(length(phiL),num_q^2);

The way we've been implementing LCM loops using MessageMonitor frequently leads to missed incoming messages. It seems to be performance-related (e.g., it is more pronounced on laptops and it gets worse with higher rate LCM traffic and higher traffic volume). It is happening in normal operating regimes for the DRC.

I tested a few cases:

a) Matlab: echoing using a loop like:

data = getNextMessage(MessageMonitorObject,timeout)
if ~isempty(x)
  ...
  publish(...)
end

for several values of timeout.

b) Java: echoing in a loop with MessageMonitor like the above

c) Python: echoing in a message handler function

d) Java: echoing in a message handler function (directly in the messageReceived method of MessageMonitor)

With high-rate EST_ROBOT_STATE messages, the performance of the methods in terms of number of dropped messages ranks in the order a-b-c-d from worst to best.

Method (d) dropped no messages, even at a high rate > 3kHz. Method (c) drops message only at the very high rates. Methods (a) and (b) both drop messages even at normal rates (~kHz). On an alienware desktop with low processor load, the matlab loop (a) drops ~1.5% of messages when states are published at 666Hz and ~30% of messages at 1333Hz.

perhaps only with a small probability, but once the "failure" happens, then it actually crashes:

http://kobol.csail.mit.edu/cd/testDetails.php?test=85530&build=5720

Drake should have a way of modeling actuators that take position as input (like servos) directly from URDFs. This would of course be an abstraction for the controller inside the servo but most people assume those controllers to be "ideal" anyway.

A temporary workaround I found is to build a PD controller around a RigidBodyManipulator yourself.

                        +-------+         +--------+
                        |       |         |        |
        u +--------+--->|    T  +-------->|   RBM  +---+-----> x
                   ^    +-------+         +--------+   |
                   |                                   |
                   |                                   |
                   |                                   |
                   |            +---------+            |
                   |            |         |            |
                   +------------+    LS   |<-----------+
                                |         |
                                +---------+

The T is the mechanicalReduction in your URDF (which is technically inside RBM but is easier to see that way), RBM is your RigidBodyManipulator and LS is a LinearSystem (the PD controller). Here is an example:

options.floating = true;
sys1 = RigidBodyManipulator('Sbach.urdf',options);

Kp = -500;
Kd = -400;
D = zeros(5,20);
D(1,7) = Kp; 
D(2,8) = Kp;
D(3,9) = Kp;
D(4,10) = Kp;
D(5,10) = 0; % thrust
D(1,17) = Kd;
D(2,18) = Kd;
D(3,19) = Kd;
D(4,20) = Kd;
D(5,20) = 0;
sys2 = LinearSystem([],[],[],[],[],D);

t_1out_2in = AffineTransform(sys1.getOutputFrame(),sys2.getInputFrame(),eye(20),zeros(20,1));
t_2out_1in = AffineTransform(sys2.getOutputFrame(),sys1.getInputFrame(),eye(5),zeros(5,1));
sys1.getOutputFrame().addTransform(t_1out_2in);
sys2.getOutputFrame().addTransform(t_2out_1in);

p = feedback(sys1,sys2);

x0 = [0 0 3 0 0 0 -.75 -.75 -.75 0 10 0 0 0 0 0 0 0 0 0]';
tf = .5;
pts = 10;
u0 = repmat([-.75 -.75 -.75 0  0]', 1, pts);
utraj = PPTrajectory(foh(linspace(0,tf,pts),u0));
utraj = setOutputFrame(utraj, p.getInputFrame);
pp = cascade(utraj,p);
xtraj = pp.simulate([0 tf], x0);

v = sys1.constructVisualizer();
v.playback(xtraj, struct('slider', true));

Things to take into consideration when tuning your PD controller:

• P gain
• D gain
• Mechanical reduction in your URDF
• Inertia matrix of the actuated joints

Using Ubuntu 12.04 with Matlab r2014A

mex -v doesn't output the Option file details. Solution: a dummy input file is added for mex to compile.

Mex -v returns
Verbose mode is on.
Not enough input arguments.

runPD and runStandingDemo fail with the following error message:

Error using TimeSteppingRigidBodyManipulator/pdcontrol (line 595)
Cannot find 'atlasState' in the output frame of this manipulator. Consider adding a state estimator or a full-state sensor

Error in runPD (line 20)
sys = pdcontrol(r,kp,kd);

http://kobol.csail.mit.edu/cd/testDetails.php?test=55082&build=5050

somehow checkDependency('gurobi') is passing, but gurobiQPmex does not exist. Perhaps matlab is finding gurobi but cmake did not?

the load command gets to the viewer fine, the urdf loads, and lcm-spy reveals the acknowledgement message sent. but the message aggregator in matlab never seems to receive it.

it works just fine on 2012a on the same machine.

gets wedged after
Old revision of repository is: ----

and before
New revision of repository is: ----

doesn't seem to happen immediately after running tests, or anything simple like that.

After fixing mex.cmake to properly pass the mex compile flags, i'm getting a compile error on one of my 6 test machines. A quick google search only suggested -std=c++0x, but that's already in the compiler flags. Andres - it's in your code - can you have a look?

[ 58%] Building CXX object systems/plants/CMakeFiles/HandCmex.dir/HandCmex.cpp.o
cd /home/russt/locomotion/drake-distro/drake/pod-build/systems/plants && /usr/local/bin/c++   -DHandCmex_EXPORTS -Wreturn-type -Wuninitialized -Wunused-variable -std=c++0x -O3 -DNDEBUG -fPIC -I/home/russt/locomotion/drake-distro/drake/pod-build/include -I/home/russt/locomotion/drake-distro/build/include -I/home/russt/locomotion/drake-distro/drake/pod-build/lcmgen -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/home/russt/locomotion/drake-distro/build/include/eigen3 -I/usr/local/MATLAB/R2012b/extern/include -I/usr/local/MATLAB/R2012b/simulink/include -I/home/russt/locomotion/drake-distro/drake/util -I/home/russt/locomotion/drake-distro/drake/systems/plants/tinyxml -I/home/russt/locomotion/drake-distro/build/include/snopt    -DMATLAB_MEX_FILE  -ansi -D_GNU_SOURCE -fPIC -fno-omit-frame-pointer -pthread   -DMX_COMPAT_32 -o CMakeFiles/HandCmex.dir/HandCmex.cpp.o -c /home/russt/locomotion/drake-distro/drake/systems/plants/HandCmex.cpp
In file included from /home/russt/locomotion/drake-distro/drake/systems/plants/RigidBodyManipulator.h:9:0,
                 from /home/russt/locomotion/drake-distro/drake/systems/plants/HandCmex.cpp:6:
/home/russt/locomotion/drake-distro/drake/systems/plants/collision/Model.h:69:3: error: ‘shared_ptr’ in namespace ‘std’ does not name a type
/home/russt/locomotion/drake-distro/drake/systems/plants/collision/Model.h:71:3: error: ‘shared_ptr’ in namespace ‘std’ does not name a type
In file included from /home/russt/locomotion/drake-distro/drake/systems/plants/HandCmex.cpp:6:0:
/home/russt/locomotion/drake-distro/drake/systems/plants/RigidBodyManipulator.h:185:3: error: ‘shared_ptr’ in namespace ‘std’ does not name a type
make[3]: *** [systems/plants/CMakeFiles/HandCmex.dir/HandCmex.cpp.o] Error 1
make[3]: Leaving directory `/home/russt/locomotion/drake-distro/drake/pod-build'
make[2]: *** [systems/plants/CMakeFiles/HandCmex.dir/all] Error 2
make[2]: Leaving directory `/home/russt/locomotion/drake-distro/drake/pod-build'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/russt/locomotion/drake-distro/drake/pod-build'
make: *** [all] Error 2

Migrated from bugzilla bug 1937.

Russ Tedrake 2014-01-20 21:37:38 EST
on my home laptop. to reproduce: cd ~/locomotion/pods/drake; matlab -r "addpath_drake; cd systems/plants/constraint/test; AllBodiesClosestDistanceConstraintTest"
[reply] [-] Comment 1 Russ Tedrake 2014-01-21 05:35:00 EST
interestingly (and frustratingly), the crash DOES occur when I use R2014a (pre-release), until i build with debug symbols... then it goes away.
[reply] [-] Comment 2 Russ Tedrake 2014-01-21 05:38:07 EST
correction. it still fails in R2014a with debug symbols when i run it without gdb. but succeeds from within gdb. sigh.
[reply] [-] Comment 3 Russ Tedrake 2014-01-21 06:05:04 EST
after a lot of printf debugging, it seems that the code gets to RBM::closestPointsAllBodies with a non-null collision_model ptr, but then never makes it into the call in ModelTemplate.h. I also verified that it is constructing a BulletModel in the RBM constructor. i suspect this is the same ghost memory bug from 1873. (now #14 )

Had a email conversation with Russ about this. It could be that I'm not using the weldJoint function properly. But, I keep getting an error when I try to fix certain joints in a urdf and then construct a visualizer like this:

% Set up system
% p = RigidBodyManipulator('SimpleHumanoid.urdf');
p = RigidBodyManipulator('AtlasModel.urdf');
v = p.constructVisualizer;
p = p.weldJoint(7); p = p.compile(); v = p.constructVisualizer;
p = p.weldJoint(7); p = p.compile(); v = p.constructVisualizer;

Warning: Error reloading VRML file.

In RigidBodyManipulator.RigidBodyManipulator>RigidBodyManipulator.constructVisualizer at 811
In runAtlasBalance at 26

from Bugzilla (bug 1873)

Michael Posa 2013-10-28 14:50:03 EDT
On multiple machines, including a DRC laptop, I get a consistent crash of MATLAB if I type "clear all" or "megaclear" after I have constructed constraints for teh IK. This includes, at least, world position and posture constraints.

[reply] [-] Comment 1 Hongkai Dai 2013-11-15 14:41:56 EST
I create a test case to construct a constraint in c++ only, and then delete it in c++. It works fine. So I think the problem is in the deleting mechanism in MATLAB. It cannot call any virtual function right before calling "delete constraint". I suppose the VTABLE is gone. Hongkai
[reply] [-] Comment 2 Russ Tedrake 2013-11-28 06:27:28 EST
i believe that this is no longer an issue in trunk. i cleaned up a lot of potential memory issues when i was dispelling warnings a few weeks ago, and will attribute it to that. if you do see it again (or if you have seen it in the last < 1 week) then please reopen the bug. specifically, i used to see the crash also on my mac, but now can run the tests in systems/plants/constraint/test followed by megaclear, and all is well.
[reply] [-] Comment 3 Hongkai Dai 2013-11-28 12:02:18 EST
I still have this problem. I tried urdf = [getDrakePath,'/examples/Atlas/urdf/atlas_minimal_contact.urdf']; options.floating = true; robot = RigidBodyManipulator(urdf,options); kc = constructPtrWorldCoMConstraintmex(robot.getMexModelPtr,zeros(3,1),zeros(3,1)); Then 'megaclear' crashes MATLAB. If I do not construct constraints through MATLAB, but purely construct it in c++, then I can delete it.
[reply] [-] Comment 4 Russ Tedrake 2013-12-02 05:59:57 EST
i spent some time working on this yesterday, and will focus today on resolving it. it's bigger than the constraint classes, i fear. i was even able to get the crash by doing cd examples/Acrobot; r = RigidBodyManipulator('Acrobot.urdf'); megaclear; unfortunately, my mac at home, which is upgraded to mavericks, doesn't seem capable of running valgrind yet (homebrew and macports installations fail), and the gdb toolkit is a mess. will try to resolve it on my work laptop. my next step is to make sure that valgrind on the command-line only tests (e.g. urdf_kinematics_test) comes through clean. i would also like to figure out how to (gently) add a unit test that fails on this into the pile, and add the valgrind step to the ctest memcheck suite.
[reply] [-] Comment 5 Hongkai Dai 2013-12-02 09:43:35 EST
I do not have the problem of RigidBodyManipulator, I can run the constructor and then clear it.
[reply] [-] Comment 6 Russ Tedrake 2013-12-06 14:47:01 EST
valgrind on urdf_kin_test revealed a few memory leaks, which I cleaned the other day. currently valgrinding all of matlab with: matlab -nodisplay -nosplash -r "addpath_drake; cd examples/Acrobot; r = RigidBodyManipulator('Acrobot.urdf'); megaclear; exit" -D"valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --dsymutil=yes --xml=yes --xml-file=VALGRIND_OUTPUT.xml" it's been going for a while now... xml output is 170MB and counting. No RigidBodyManipulator warnings that I can see yet.

Using add_mex for all three is not good for readability

The approach we've used up to this point (resetting frames with Atlas specific ones inside compile) will clobber the changes made to those frames by the addition of the sensor.

Hello!,

I'm loading a floating robot from an urdf file. When running a runPassive controller the robot falls down from z=1.0 without simulating contact with the ground.

I notice that using the SimplePendulum robot I obtain the same behavior, so probably there is a concept that I am missing here.

I will appreciate any help you may provide.

Here, minimal code for both (runPassive.m and simpleTest.urdf)

runPassive.m

options.floating = true;
options.collision = true;
r = RigidBodyManipulator('urdf/simpleTest.urdf',options);
x0 = Point(r.getStateFrame);
v = r.constructVisualizer;
v.display_dt = .05;

if (0)
  sys = cascade(r,v);
  warning(s);
  simulate(sys,[0 10],x0);
else 
  xtraj = simulate(r,[0 10],x0);
   v.playback(xtraj);
end

simpleTest.urdf

`

Thank you!

I'm getting the following build error on my machine (Alienware Desktop, Ubuntu 12.04, MATLAB 2012b).

Linking CXX executable ../bin/drake_debug_mex
/usr/bin/ld: CMakeFiles/drake_debug_mex.dir/drakeDebugMex.cpp.o: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
/usr/bin/ld: note: 'dlclose@@GLIBC_2.2.5' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libdl.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libdl.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [bin/drake_debug_mex] Error 1
make[2]: *** [util/CMakeFiles/drake_debug_mex.dir/all] Error 2

Does drake support collisions between two objects (not between an object and the ground)?

I am simulating a double pendulum colliding with a wall, but the pendulum penetrates to the wall. Maybe I am missing something in my code (below).

URDF code:

<?xml version="1.0"?>

<robot name="SimpleDoublePendulum">
  <material name="green">
      <color rgba=".3 .6 .4 1" />
  </material>
  <material name="red">
    <color rgba=".9 .1 0 1" />
  </material>
  <material name="blue">
    <color rgba="0 0 1 1" />
  </material>
  <link name="world">
  </link>
  <link name="upper_arm">
    <inertial> 
      <origin xyz="0 0 -0.5" rpy="0 0 0" />
      <mass value="1" />
      <inertia ixx="0" ixy="0" ixz="0" iyy="0" iyz="0" izz="0"/> 
    </inertial>
    <visual>
      <origin xyz="0 0 -.5" rpy="0 0 0" />
      <geometry>
         <cylinder length="1" radius=".01" />
      </geometry>
      <material name="red" />
    </visual> 
    <collision>
      <origin xyz="0 0 -0.5" rpy="0 0 0" />
      <geometry>
         <cylinder length="1" radius=".01" />
      </geometry>
    </collision>
  </link>
  <joint name="shoulder" type="continuous">
    <origin xyz="0 0 2.5" />
    <parent link="world"/>
    <child link="upper_arm" />
    <axis xyz="0 1 0" />
    <dynamics damping="0.1" />
  </joint>
  <link name="lower_arm">
    <inertial> 
      <origin xyz="0 0 -0.5" rpy="0 0 0" />
      <mass value="1" />
      <inertia ixx="0" ixy="0" ixz="0" iyy="0" iyz="0" izz="0"/> 
    </inertial>
    <visual>
      <origin xyz="0 0 -.5" rpy="0 0 0" />
      <geometry>
         <cylinder length="1" radius=".01" />
      </geometry>
      <material name="blue" />
    </visual> 
      <collision>
      <origin xyz="0 0 -0.5" rpy="0 0 0" />
      <geometry>
         <cylinder length="1" radius=".01" />
      </geometry>
    </collision>
</link>
  <joint name="elbow" type="continuous">
    <parent link="upper_arm"/>
    <origin xyz="0 0 -1" />
    <child link="lower_arm" />
    <axis xyz="0 1 0" />
    <dynamics damping="0.1" />
  </joint>
  <link name="left_wall">
    <visual>
      <origin xyz="-0.5 0 1" rpy="0 0 0" />
      <geometry>
         <box size="0.01 0.5 2"/>
      </geometry>
      <material name="green" />
    </visual>
    <collision>
      <origin xyz="-0.5 0 1" rpy="0 0 0" />
      <geometry>
         <box size="0.01 0.5 2"/>
      </geometry>
    </collision>
  </link>
  <joint name="left_wall_weld" type="fixed">
    <parent link="world"/>
    <child link="left_wall" />
  </joint>
</robot>

MATLAB code:

    clc;
    close all;

    options = [];
    r = TimeSteppingRigidBodyManipulator('SimpleDoublePendulum.urdf', 0.001,options);

    TimeSpan = [0 4];
    x0 = [ -0.2; -0.9; 0; -1 ];        
    xtraj = simulate(r,TimeSpan,x0);        
    v = r.constructVisualizer();
    v.playback(xtraj,struct('slider',true));       

Dear Authors,

I'm using Mac OS X 10.8.5. And I also have Matlab2013a in my computer. After building drake, I'm able to successfully run all examples given in "https://github.com/RobotLocomotion/drake/wiki/FromSource", which include CartPole, Quadrotor2D,RimlessWheel, and PlanarMonopodHopper.

However, when I tried to run other example such as Atlas, I got this error in MATLAB saying that "Undefined function 'collisionDetectmex' for input arguments of type 'struct' ". Do you know the solution to this problem ?

Sincerely,
Pi Thanacha Choopojcharoen

it is causing problems for michael, where stale data from a previous matlab session interferes with checkDependency. With two minor changes (writing getDrakePath() to build/matlab in cmake, and passing some conf flags to checkDependency), we don't critically need it anymore.

the downside is that checkDependency would have to redo it's work after a matlab clear (aka megaclear).

an alternative fix for michael would be to recreate drake_config.mat from scratch in addpath_drake. maybe that's better.