robotlocomotion / drake Goto Github PK
View Code? Open in Web Editor NEWModel-based design and verification for robotics.
Home Page: https://drake.mit.edu
License: Other
Model-based design and verification for robotics.
Home Page: https://drake.mit.edu
License: Other
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);
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');
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);
Cylinders render as tubes.
Using add_mex for all three is not good for readability
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!
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
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:
<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>
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.
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?
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
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
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
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
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?
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.
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.
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 )
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.
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.
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);
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?
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:
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
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 target
install_prereqs_homebrew'. Stop.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.
MATLAB Version: 8.3.0.532 (R2014a)
MATLAB License Number: 650667
Operating System: Mac OS X Version: 10.9.2 Build: 13C64
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)
Thank you for your help,
Is there a bug tracking page I should add this request to?
Bye
Robert Katzschmann
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));
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));
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:
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.
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
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?
Not sure how to reopen it, but I left a comment on the issue for:
TimeSteppingRigidBodyManipulator frame handling causes errors for sensorless manipulators
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
How can I change the friction coefficient between the ground and the object in floating base models described by a urdf file?
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!
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.
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
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
------------------------------------------------------------------------
This is due to changes in the input arguments of the ContactForceTorqueSensor
introduced during the upgrade of RigidBodyFrames
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!
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.
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 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.
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.
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:
Javad
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?
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.
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.
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);
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.