RussTedrake
commented
9 years ago Daniel,
You shouldn't be using the terrain objects for this. As you say, they are intended for 2.5 "terrains" only. You can simply be adding geometries to the RigidBodyManipulator / TSRBM which have collision geometries. You should take a look at the quadrotor folder for an example. Most of the code there tries to avoid collisions, but here is a quick version that will show you that the collision dynamics work just fine:
function testCollisions
tmp = addpathTemporary(fullfile(pwd,'..'));
r = Quadrotor();
r = r.setTerrain([]);
r = addTrees(r, 25);
% The important trees to create swerving path
r = addTree(r, [.8,.45,1.25], [.20;2.5], pi/4);
r = addTree(r, [.5,.35,1.65], [-.25;5], -pi/6);
r = addTree(r, [.55,.65,1.5], [.25;7.5], pi/4);
r = addTree(r, [.55,.85,1.6], [-1.35;8.5], pi/3.7);
r = addTree(r, [.85,.95,1.65], [-1.85;5.2], -pi/3.7);
r = addTree(r, [.75,.9,1.75], [2;4.4], -pi/5);
x0 = Point(getStateFrame(r)); % initial conditions: all-zeros
x0.base_y = -1.5;
x0.base_z = .8;
x0.base_ydot = 5;
u0 = double(nominalThrust(r));
v = constructVisualizer(r);%,struct('use_collision_geometry',true));
v.draw(0,double(x0));
utraj = setOutputFrame(ConstantTrajectory(u0),r.getInputFrame);
xtraj = simulate(cascade(utraj,TimeSteppingRigidBodyManipulator(r,.01)),[0 5],x0);
v.playback(xtraj);Sadly, although the different coefficient of frictions are very easy to implement, we haven't actually done it yet. See the discussion / recommendations in issue #57 .
- Russ
On Dec 15, 2014, at 3:32 AM, DJGCrusader notifications@github.com wrote:
Hi all,
I am a student in 6.832 and am working on planning for a quadruped climbing robot, climbing up a shaft for my final project.
I am trying to generate a vertical shaft to use as my environment for my quadruped climber robot, but the RigidBodyManipulator framework only supports a single terrain polygon. It'd be great to simply have a custom terrain object contain a list of RigidBodyBox objects for the terrain, but that can't work either. I already have the URDF with collisions all working (the urdf tag contact_coefficients, which contains friction coeffs and collision compliance/impedance, seems to do nothing, though) with a planar simulation and self-collisions, collisions with the RigidBodyFlatTerrain, etc.
I have code that creates a random cave environment that I've plotted below, which now just outputs a list of line segment lengths, endpoints, the centroids, and the angles, with which I can use the RigidBodyBox geometry to create terrain, but I'd first like to test my system with two simple straight parallel walls, 20m high, 1m thick, 4m apart. Pictured above is the current situation, with collisions, \only one wall. This was made by modifying the width, depth, and T in the constructRigidBodyGeometry function of the RigidBodyFlatTerrain object. It collides with the wall due to the geometry, and collides with the "ground" because I've left the getHeight() function is untouched.
The issue is, it seems, that the RigidBodyManipulator assumes only a single RigidBodyTerrain object, and the terrain objects only assume a single polygon. Digging deeper into RigidBodyGeometry objects, multiple polygons will only be combined because it keeps only the convex hull of the points rather than custom mazes and cavesetc. Am I on the right track in trying to make my own custom "options.terrain" within the Drake RigidBodyManipulator framework? Should I be making something other than terrain, like just including another dummy object? I'd like to randomly generate my vertical shaft rather than have a single URDF that represents the environment. The closest example simulation with objects I could find was Airplane2D, but it follows a completely different and much simpler model framework than the RigidBodyManipulator. Right now I'm leaning towards making a custom copy of RigidBodyBox and hacking it to have multiple floating polygons in the geometry. I'm using the latest rigid-body build of Drake on Ubuntu with mosek installed.
I've looked into the rt.getManipulator().setTerrain() and .addTerrainGeometries, but it all only seems to be written for only a single terrain object, and terrain objects seem to be only written for a single geometry object. I tried creating my own RigidBodySimpleShaftTerrain.m and RigidBodySimpleShaft geometry. The output of geometry.getPoints() is:
pts =
2 3 3 2 2 3 3 2 -3 -2 -2 -3 -3 -2 -2 -3 1 1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1 20 20 0 0 0 0 20 20 20 20 0 0 0 0 20 20 Which are the 3D corner points of both the left and the right box. And the resultant playback looks like:
Here it is peeking out through the left wall after dropping it with an initial leftward x velocity. If it were simulating correctly but drawing incorrectly, it would still be hidden. The right side definitely contacts the wall, I've verified it by dropping it with a rightward x velocity plotting the xy trajectory and noting a "bounce". Perhaps TSRBM.getTerrain.getRigidBodyContactGeometry() and the associated RigidBodyGeometry objects isn't the best way to go for anything but the ground.
I tried modifying the URDF to have two additional links which are the walls (since robot self-collisions are woking for me), no frills, but the URDF won't load.
Anywhere I can look next?
Also, I would really like to specify custom coefficients of friction between objects, but the urdf tag contact_coefficients, which contains friction coeffs and collision compliance/impedance, seems to do nothing in drake when it loads the urdf. Does the LCP solver called during TSRBM.update(t,x,u) support static and kinetic friction?
Thanks so much!
-Daniel J. Gonzalez dgonz@mit.edu
— Reply to this email directly or view it on GitHub.
avalenzu
DJGCrusader
Hi all,
I am a student in 6.832 and am working on planning for a quadruped climbing robot, climbing up a shaft for my final project.
I am trying to generate a vertical shaft to use as my environment for my quadruped climber robot, but the RigidBodyManipulator framework only supports a single terrain polygon. It'd be great to simply have a custom terrain object contain a list of RigidBodyBox objects for the terrain, but that can't work either. I already have the URDF with collisions all working (the urdf tag contact_coefficients, which contains friction coeffs and collision compliance/impedance, seems to do nothing, though) with a planar simulation and self-collisions, collisions with the RigidBodyFlatTerrain, etc.
I have code that creates a random cave environment that I've plotted below, which now just outputs a list of line segment lengths, endpoints, the centroids, and the angles, with which I can use the RigidBodyBox geometry to create terrain, but I'd first like to test my system with two simple straight parallel walls, 20m high, 1m thick, 4m apart. Pictured above is the current situation, with collisions, \only one wall. This was made by modifying the width, depth, and T in the constructRigidBodyGeometry function of the RigidBodyFlatTerrain object. It collides with the wall due to the geometry, and collides with the "ground" because I've left the getHeight() function is untouched.
The issue is, it seems, that the RigidBodyManipulator assumes only a single RigidBodyTerrain object, and the terrain objects only assume a single polygon. Digging deeper into RigidBodyGeometry objects, multiple polygons will only be combined because it keeps only the convex hull of the points rather than custom mazes and cavesetc. Am I on the right track in trying to make my own custom "options.terrain" within the Drake RigidBodyManipulator framework? Should I be making something other than terrain, like just including another dummy object? I'd like to randomly generate my vertical shaft rather than have a single URDF that represents the environment. The closest example simulation with objects I could find was Airplane2D, but it follows a completely different and much simpler model framework than the RigidBodyManipulator. Right now I'm leaning towards making a custom copy of RigidBodyBox and hacking it to have multiple floating polygons in the geometry. I'm using the latest rigid-body build of Drake on Ubuntu with mosek installed.
I've looked into the rt.getManipulator().setTerrain() and .addTerrainGeometries, but it all only seems to be written for only a single terrain object, and terrain objects seem to be only written for a single geometry object. I tried creating my own RigidBodySimpleShaftTerrain.m and RigidBodySimpleShaft geometry. The output of geometry.getPoints() is:
pts =
Which are the 3D corner points of both the left and the right box. And the resultant playback looks like:
Here it is peeking out through the left wall after dropping it with an initial leftward x velocity. If it were simulating correctly but drawing incorrectly, it would still be hidden. The right side definitely contacts the wall, I've verified it by dropping it with a rightward x velocity plotting the xy trajectory and noting a "bounce". Perhaps TSRBM.getTerrain.getRigidBodyContactGeometry() and the associated RigidBodyGeometry objects isn't the best way to go for anything but the ground.
I tried modifying the URDF to have two additional links which are the walls (since robot self-collisions are woking for me), no frills, but the URDF won't load.
Anywhere I can look next?
Also, I would really like to specify custom coefficients of friction between objects, but the urdf tag contact_coefficients, which contains friction coeffs and collision compliance/impedance, seems to do nothing in drake when it loads the urdf. Does the LCP solver called during TSRBM.update(t,x,u) support static and kinetic friction?
Thanks so much!
-Daniel J. Gonzalez dgonz@mit.edu