pydrake.multibody.multibody_tree.multibody_plant¶
Multibody plant functionality.
Warning
This module will soon be deprecated. Please use pydrake.multibody.plant
instead.
-
pydrake.multibody.multibody_tree.multibody_plant.
AddMultibodyPlantSceneGraph
(builder: pydrake.systems.framework.DiagramBuilder_[float], plant: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant = None, scene_graph: pydrake.geometry.SceneGraph = None) → tuple¶ Adds a MultibodyPlant and a SceneGraph instance to a diagram builder, connecting the geometry ports.
- Parameter
builder
: - Builder to add to.
- Parameter
plant
: - (optional) Constructed plant (e.g. for using a discrete plant). By default, a continuous plant is used.
- Parameter
scene_graph
: - (optional) Constructed scene graph. If none is provided, one will be created and used.
Returns: Pair of the registered plant and scene graph. - Precondition:
builder
must be non-null.
Recommended usages:
Assign to a MultibodyPlant reference (ignoring the SceneGraph):
MultibodyPlant<double>& plant = AddMultibodyPlantSceneGraph(&builder); plant.DoFoo(...);
This flavor is the simplest, when the SceneGraph is not explicitly needed. (It can always be retrieved later via GetSubsystemByName(“scene_graph”).)
Assign to auto, and use the named public fields:
auto items = AddMultibodyPlantSceneGraph(&builder); items.plant.DoFoo(...); items.scene_graph.DoBar(...);
or
auto items = AddMultibodyPlantSceneGraph(&builder); MultibodyPlant<double>& plant = items.plant; SceneGraph<double>& scene_graph = items.scene_graph; ... plant.DoFoo(...); scene_graph.DoBar(...);
This is the easiest way to use both the plant and scene_graph.
Assign to already-declared pointer variables:
MultibodyPlant<double>* plant{}; SceneGraph<double>* scene_graph{}; std::tie(plant, scene_graph) = AddMultibodyPlantSceneGraph(&builder); plant->DoFoo(...); scene_graph->DoBar(...);
This flavor is most useful when the pointers are class member fields (and so perhaps cannot be references).
- Parameter
-
class
pydrake.multibody.multibody_tree.multibody_plant.
ContactResults
¶ -
AddContactInfo
(self: pydrake.multibody.multibody_tree.multibody_plant.ContactResults, point_pair_info: pydrake.multibody.multibody_tree.multibody_plant.PointPairContactInfo) → None¶
-
__init__
(self: pydrake.multibody.multibody_tree.multibody_plant.ContactResults) → None¶
-
contact_info
(self: pydrake.multibody.multibody_tree.multibody_plant.ContactResults, i: int) → pydrake.multibody.multibody_tree.multibody_plant.PointPairContactInfo¶
-
num_contacts
(self: pydrake.multibody.multibody_tree.multibody_plant.ContactResults) → int¶
-
-
class
pydrake.multibody.multibody_tree.multibody_plant.
MultibodyPlant
¶ Bases:
pydrake.systems.framework.LeafSystem_[float]
%MultibodyPlant is a Drake system framework representation (see systems::System) for the model of a physical system consisting of a collection of interconnected bodies. See multibody for an overview of concepts/notation.
MultibodyPlant provides a user-facing API to:
- add bodies, joints, force elements, and constraints,
- register geometries to a provided SceneGraph instance,
- create and manipulate its Context,
- perform Context-dependent computational queries.
The state of a multibody system
x = [q; v]
is given by its generalized positions vector q, of sizenq
(see num_positions()), and by its generalized velocities vector v, of sizenv
(see num_velocities()). As a Drake System, MultibodyPlant implements the governing equations for a multibody dynamical system in the formẋ = f(t, x, u)
with t being the time and u the input vector of actuation forces. The governing equations for the dynamics of a multibody system modeled with MultibodyPlant are [Featherstone 2008, Jain 2010]:q̇ = N(q)v (1) M(q)v̇ + C(q, v)v = tau
where
M(q)
is the mass matrix of the multibody system,C(q, v)v
corresponds to the bias term containing Coriolis and gyroscopic effects andN(q)
is the kinematic coupling matrix describing the relationship between the rate of change of the generalized coordinates and the generalized velocities, [Seth 2010]. N(q) is annq x nv
matrix. The vectortau ∈ ℝⁿᵛ
on the right hand side of Eq. (1) corresponds to generalized forces applied on the system. These can include externally applied body forces, constraint forces, and contact forces.Drake has the capability of loading multibody models from SDF and URDF files. Consider the example below which loads an acrobot model:
MultibodyPlant<T> acrobot; SceneGraph<T> scene_graph; Parser parser(&acrobot, &scene_graph); const std::string relative_name = "drake/multibody/benchmarks/acrobot/acrobot.sdf"; const std::string full_name = FindResourceOrThrow(relative_name); parser.AddModelFromFile(full_name);
As in the example above, for models including visual geometry, collision geometry or both, the user must specify a SceneGraph for geometry handling. You can find a full example of the LQR controlled acrobot in examples/multibody/acrobot/run_lqr.cc.
AddModelFromFile() can be invoked multiple times on the same plant in order to load multiple model instances. Other methods are available on Parser such as AddAllModelsFromFile() which allows creating model instances per each
<model>
tag found in the file. Please refer to each of these methods’ documentation for further details.Clients of a MultibodyPlant can add multibody elements with the following methods:
- Bodies: AddRigidBody().
- Joints: AddJoint().
All modeling elements must be added pre-finalize.
MultibodyPlant users can register geometry with a SceneGraph for essentially two purposes; a) visualization and, b) contact modeling.
Before any geometry registration takes place, a user must first make a call to RegisterAsSourceForSceneGraph() in order to register the MultibodyPlant as a client of a SceneGraph instance, point at which the plant will have assigned a valid geometry::SourceId. At Finalize(), MultibodyPlant will declare input/output ports as appropriate to communicate with the SceneGraph instance on which registrations took place. All geometry registration must be performed pre-finalize.
If MultibodyPlant registers geometry with a SceneGraph via calls to RegisterCollisionGeometry(), an input port for geometric queries will be declared at Finalize() time, see get_geometry_query_input_port(). Users must connect this input port to the output port for geometric queries of the SceneGraph used for registration, which can be obtained with SceneGraph::get_query_output_port(). In summary, if MultibodyPlant registers collision geometry, the setup process will include:
- Call to RegisterAsSourceForSceneGraph().
- Calls to RegisterCollisionGeometry(), as many as needed.
- Call to Finalize(), user is done specifying the model.
- Connect SceneGraph::get_query_output_port() to get_geometry_query_input_port().
Refer to the documentation provided in each of the methods above for further details.
Once the user is done adding modeling elements and registering geometry, a call to Finalize() must be performed. This call will:
- Build the underlying MultibodyTree topology, see MultibodyTree::Finalize() for details,
- declare the plant’s state,
- declare the plant’s input and output ports,
- declare input and output ports for communication with a SceneGraph.
** References **
- [Featherstone 2008] Featherstone, R., 2008.
- Rigid body dynamics algorithms. Springer.
- [Jain 2010] Jain, A., 2010.
- Robot and multibody dynamics: analysis and algorithms. Springer Science & Business Media.
- [Seth 2010] Seth, A., Sherman, M., Eastman, P. and Delp, S., 2010.
- Minimal formulation of joint motion for biomechanisms. Nonlinear dynamics, 62(1), pp.291-303.
- Template parameter
T
: - The scalar type. Must be a valid Eigen scalar.
Instantiated templates for the following kinds of T’s are provided:
- double
- AutoDiffXd
They are already available to link against in the containing library. No other values for T are currently supported.
-
AddForceElement
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, force_element: pydrake.multibody.multibody_tree.ForceElement) → pydrake.multibody.multibody_tree.ForceElement¶ Adds a new force element model of type
ForceElementType
tothis
MultibodyPlant. The arguments to this methodargs
are forwarded to ``ForceElementType`’s constructor.- Parameter
args
: - Zero or more parameters provided to the constructor of the new force element. It must be the case that JointType<T>(args)` is a valid constructor.
- Template parameter
ForceElementType
: - The type of the ForceElement to add. This method can only be called once for elements of type UniformGravityFieldElement. That is, gravity can only be specified once.
Returns: A constant reference to the new ForceElement just added, of type ForceElementType<T>
specialized on the scalar type T ofthis
MultibodyPlant. It will remain valid for the lifetime ofthis
MultibodyPlant.See also
The ForceElement class’s documentation for further details on how a force element is defined.
- Parameter
-
AddJoint
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, joint: pydrake.multibody.multibody_tree.Joint) → pydrake.multibody.multibody_tree.Joint¶ This method adds a Joint of type
JointType
between two bodies. For more information, see the below overload ofAddJoint<>
, and the relatedMultibodyTree::AddJoint<>
method.
-
CalcBiasTerm
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) → numpy.ndarray[float64[m, 1]]¶ Computes the bias term
C(q, v)v
containing Coriolis and gyroscopic effects of the multibody equations of motion:M(q)v̇ + C(q, v)v = tau_app + ∑ J_WBᵀ(q) Fapp_Bo_W
where
M(q)
is the multibody model’s mass matrix andtau_app
consists of a vector applied generalized forces. The last term is a summation over all bodies in the model whereFapp_Bo_W
is an applied spatial force on body B atBo
which gets projected into the space of generalized forces with the geometric JacobianJ_WB(q)
which maps generalized velocities into body B spatial velocity asV_WB = J_WB(q)v
.- Parameter
context
: - The context containing the state of the model. It stores the generalized positions q and the generalized velocities v.
- Parameter
Cv
: - On output,
Cv
will contain the productC(q, v)v
. It must be a valid (non-null) pointer to a column vector inℛⁿ
with n the number of generalized velocities (num_velocities()) of the model. This method aborts if Cv is nullptr or if it does not have the proper size.
- Parameter
-
CalcConservativePower
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) → float¶ Computes and returns the power generated by conservative forces in the multibody model. This quantity is defined to be positive when the potential energy is decreasing. In other words, if
U(q)
is the potential energy as defined by CalcPotentialEnergy(), then the conservative power,Pc
, isPc = -U̇(q)
.See also
CalcPotentialEnergy()
-
CalcForceElementsContribution
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], forces: pydrake.multibody.multibody_tree.MultibodyForces) → None¶ Computes the combined force contribution of ForceElement objects in the model. A ForceElement can apply forces as a spatial force per body or as generalized forces, depending on the ForceElement model. ForceElement contributions are a function of the state and time only. The output from this method can immediately be used as input to CalcInverseDynamics() to include the effect of applied forces by force elements.
- Parameter
context
: - The context containing the state of this model.
- Parameter
forces
: - A pointer to a valid, non nullptr, multibody forces object. On
output
forces
will store the forces exerted by all the ForceElement objects in the model.
Raises: - RuntimeError if
forces
is null or not compatible with this - model, per MultibodyForces::CheckInvariants().
- Parameter
-
CalcFrameGeometricJacobianExpressedInWorld
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], frame_B: pydrake.multibody.multibody_tree.Frame, p_BoFo_B: numpy.ndarray[float64[3, 1]] = array([ 0., 0., 0.])) → numpy.ndarray[float64[m, n]]¶
-
CalcGravityGeneralizedForces
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) → numpy.ndarray[float64[m, 1]]¶ Computes the generalized forces
tau_g(q)
due to gravity as a function of the generalized positionsq
stored in the inputcontext
. The vector of generalized forces due to gravitytau_g(q)
is defined such that it appears on the right hand side of the equations of motion together with any other generalized forces, like so:Mv̇ + C(q, v)v = tau_g(q) + tau_app
where
tau_app
includes any other generalized forces applied on the system.- Parameter
context
: - The context storing the state of the model.
Returns: tau_g A vector containing the generalized forces due to gravity. The generalized forces are consistent with the vector of generalized velocities v
forthis
so that the inner productv⋅tau_g
corresponds to the power applied by the gravity forces on the mechanical system. That is,v⋅tau_g > 0
corresponds to potential energy going into the system, as either mechanical kinetic energy, some other potential energy, or heat, and therefore to a decrease of the gravitational potential energy.- Parameter
-
CalcInverseDynamics
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], known_vdot: numpy.ndarray[float64[m, 1]], external_forces: pydrake.multibody.multibody_tree.MultibodyForces) → numpy.ndarray[float64[m, 1]]¶ Given the state of this model in
context
and a known vector of generalized accelerationsvdot
, this method computes the set of generalized forcestau
that would need to be applied in order to attain the specified generalized accelerations. Mathematically, this method computes:tau = M(q)v̇ + C(q, v)v - tau_app - ∑ J_WBᵀ(q) Fapp_Bo_W
where
M(q)
is the model’s mass matrix,C(q, v)v
is the bias term containing Coriolis and gyroscopic effects andtau_app
consists of a vector applied generalized forces. The last term is a summation over all bodies in the model whereFapp_Bo_W
is an applied spatial force on body B atBo
which gets projected into the space of generalized forces with the geometric JacobianJ_WB(q)
which maps generalized velocities into body B spatial velocity asV_WB = J_WB(q)v
. This method does not compute explicit expressions for the mass matrix nor for the bias term, which would be of at leastO(n²)
complexity, but it implements anO(n)
Newton-Euler recursive algorithm, where n is the number of bodies in the model. The explicit formation of the mass matrixM(q)
would require the calculation ofO(n²)
entries while explicitly forming the productC(q, v) * v
could require up toO(n³)
operations (see [Featherstone 1987, §4]), depending on the implementation. The recursive Newton-Euler algorithm is the most efficient currently known general method for solving inverse dynamics [Featherstone 2008].- Parameter
context
: - The context containing the state of the model.
- Parameter
known_vdot
: - A vector with the known generalized accelerations
vdot
for the full model. Use the provided Joint APIs in order to access entries into this array. - Parameter
external_forces
: - A set of forces to be applied to the system either as body spatial
forces
Fapp_Bo_W
or generalized forcestau_app
, see MultibodyForces for details.
Returns: the vector of generalized forces that would need to be applied to the mechanical system in order to achieve the desired acceleration given by known_vdot
.- Parameter
-
CalcJacobianSpatialVelocity
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], with_respect_to: pydrake.multibody.multibody_tree.JacobianWrtVariable, frame_B: pydrake.multibody.multibody_tree.Frame, p_BP: numpy.ndarray[float64[3, 1]], frame_A: pydrake.multibody.multibody_tree.Frame, frame_E: pydrake.multibody.multibody_tree.Frame) → numpy.ndarray[float64[m, n]]¶ Computes the Jacobian of spatial velocity for a frame instantaneously moving with a specified frame in the model. Consider a point P instantaneously moving with a frame B with position
p_BP
in that frame. FrameBp
is the frame defined by shifting frame B with origin atBo
to a new origin at point P. The spatial velocityV_ABp_E
of frameBp
measured in a frame A and expressed in a frame E can be expressed as:V_ABp_E(q, w) = Jw_ABp_E(q)⋅w
where w represents * the time derivative of the generalized position vector q̇, if
with_respect_to
is JacobianWrtVariable::kQDot. * the generalized velocity vector v, ifwith_respect_to
is JacobianWrtVariable::kV.This method computes
Jw_ABp_E(q)
.- Parameter
context
: - The context containing the state of the model. It stores the generalized positions q.
- Parameter
with_respect_to
: - Enum indicating whether
Jw_ABp_E
converts generalized velocities or time-derivatives of generalized positions to spatial velocities. - Parameter
frame_B
: - The position
p_BP
of point P is measured and expressed in this frame. - Parameter
p_BP
: - The (fixed) position of the origin
P
of frameBp
as measured and expressed in frame B. - Parameter
frame_A
: - The second frame in which the spatial velocity
V_ABp
is measured. - Parameter
frame_E
: - Frame in which the velocity V_ABp_E, and therefore the Jacobian Jw_ABp_E is expressed.
- Parameter
Jw_ABp_E
: - The Jacobian
Jw_ABp_E(q)
, function of the generalized positions q only. This Jacobian relates to the spatial velocityV_ABp_E
of frameBp
inA
and expressed inE
by:
V_ABp_E(q, w) = Jw_ABp_E(q)⋅w
Therefore
Jw_ABp_E
is a matrix of size6 x nz
, wherenz
is the number of elements in w. On input, matrixJv_ABp_E
must have size6 x nz
or this method throws an exception. Given a6 x nz
Jacobian J, let Jr be the3 x nz
rotational part (top 3 rows) and Jt be the translational part (bottom 3 rows). These can be obtained as follows:Jr_ABp_E = Jw_ABp_E.topRows<3>(); Jt_ABp_E = Jw_ABp_E.bottomRows<3>();
This ordering is consistent with the internal storage of the SpatialVelocity class. Therefore the following operations results in a valid spatial velocity:
SpatialVelocity<double> V_ABp(Jw_ABp * w);
Raises: - RuntimeError if
Jw_ABp_E
is nullptr or if it is not of size 6 x nz
.
- Parameter
-
CalcMassMatrixViaInverseDynamics
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) → numpy.ndarray[float64[m, n]]¶
-
CalcPointsPositions
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], frame_B: pydrake.multibody.multibody_tree.Frame, p_BQi: numpy.ndarray[float64[m, n], flags.f_contiguous], frame_A: pydrake.multibody.multibody_tree.Frame) → numpy.ndarray[float64[m, n]]¶ Given the positions
p_BQi
for a set of pointsQi
measured and expressed in a frame B, this method computes the positionsp_AQi(q)
of each pointQi
in the set as measured and expressed in another frame A, as a function of the generalized positions q of the model.- Parameter
context
: - The context containing the state of the model. It stores the generalized positions q of the model.
- Parameter
frame_B
: - The frame B in which the positions
p_BQi
of a set of pointsQi
are given. - Parameter
p_BQi
: - The input positions of each point
Qi
in frame B.p_BQi ∈ ℝ³ˣⁿᵖ
withnp
the number of points in the set. Each column ofp_BQi
corresponds to a vector in ℝ³ holding the position of one of the points in the set as measured and expressed in frame B. - Parameter
frame_A
: - The frame A in which it is desired to compute the positions
p_AQi
of each pointQi
in the set. - Parameter
p_AQi
: - The output positions of each point
Qi
now computed as measured and expressed in frame A. The outputp_AQi
must have the same size as the inputp_BQi
or otherwise this method aborts. That isp_AQi
must be inℝ³ˣⁿᵖ
.
Note
Both
p_BQi
andp_AQi
must have three rows. Otherwise this method will throw a RuntimeError exception. This method also throws a RuntimeError exception ifp_BQi
andp_AQi
differ in the number of columns.- Parameter
-
CalcPotentialEnergy
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) → float¶ Computes and returns the total potential energy stored in
this
multibody model for the configuration given bycontext
.- Parameter
context
: - The context containing the state of the model.
Returns: The total potential energy stored in this
multibody model.- Parameter
-
CalcRelativeTransform
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], frame_A: pydrake.multibody.multibody_tree.Frame, frame_B: pydrake.multibody.multibody_tree.Frame) → pydrake.common.eigen_geometry.Isometry3¶ Computes the relative transform
X_AB(q)
from a frame B to a frame A, as a function of the generalized positions q of the model. That is, the positionp_AQ
of a point Q measured and expressed in frame A can be computed from the positionp_BQ
of this point measured and expressed in frame B using the transformationp_AQ = X_AB⋅p_BQ
.- Parameter
context
: - The context containing the state of the model. It stores the generalized positions q of the model.
- Parameter
frame_A
: - The target frame A in the computed relative transform
X_AB
. - Parameter
frame_B
: - The source frame B in the computed relative transform
X_AB
. - Returns
X_AB
: - The relative transform from frame B to frame A, such that
p_AQ = X_AB⋅p_BQ
.
- Parameter
-
CalcSpatialAccelerationsFromVdot
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], known_vdot: numpy.ndarray[float64[m, 1]]) → List[pydrake.multibody.multibody_tree.math.SpatialAcceleration]¶ Given the state of this model in
context
and a known vector of generalized accelerationsknown_vdot
, this method computes the spatial accelerationA_WB
for each body as measured and expressed in the world frame W.- Parameter
context
: - The context containing the state of this model.
- Parameter
known_vdot
: - A vector with the generalized accelerations for the full model.
- Parameter
A_WB_array
: - A pointer to a valid, non nullptr, vector of spatial accelerations
containing the spatial acceleration
A_WB
for each body. It must be of size equal to the number of bodies in the model. On output, entries will be ordered by BodyIndex.
Raises: RuntimeError if A_WB_array is not of size num_bodies()
.- Parameter
-
EvalBodyPoseInWorld
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], body: pydrake.multibody.multibody_tree.Body) → pydrake.common.eigen_geometry.Isometry3¶ Evaluate the pose
X_WB
of a body B in the world frame W.- Parameter
context
: - The context storing the state of the model.
- Parameter
body_B
: - The body B for which the pose is requested.
- Returns
X_WB
: - The pose of body frame B in the world frame W.
Raises: - RuntimeError if Finalize() was not called on
this
model or if body_B
does not belong to this model.
- Parameter
-
EvalBodySpatialVelocityInWorld
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], body: pydrake.multibody.multibody_tree.Body) → pydrake.multibody.multibody_tree.math.SpatialVelocity¶ Evaluate the spatial velocity
V_WB
of a body B in the world frame W.- Parameter
context
: - The context storing the state of the model.
- Parameter
body_B
: - The body B for which the spatial velocity is requested.
Returns: V_WB The spatial velocity of body frame B in the world frame W.
Raises: - RuntimeError if Finalize() was not called on
this
model or if body_B
does not belong to this model.
- Parameter
-
Finalize
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, scene_graph: pydrake.geometry.SceneGraph = None) → None¶ This method must be called after all elements in the model (joints, bodies, force elements, constraints, etc.) are added and before any computations are performed. It essentially compiles all the necessary “topological information”, i.e. how bodies, joints and, any other elements connect with each other, and performs all the required pre-processing to enable computations at a later stage.
If the finalize stage is successful, the topology of this MultibodyPlant is valid, meaning that the topology is up-to-date after this call. No more multibody elements can be added after a call to Finalize().
At Finalize(), state and input/output ports for
this
plant are declared. Ifthis
plant registered geometry with a SceneGraph, input and output ports to enable communication with that SceneGraph are declared as well.If geometry has been registered on a SceneGraph instance, that instance must be provided to the Finalize() method so that any geometric implications of the finalization process can be appropriately handled.
See also
is_finalized().
Raises: - RuntimeError if 1. the MultibodyPlant has already been finalized
- or 3. a different scene_graph instance is provided than the one
- for which this plant is a geometry source.
-
GetBodyByName
(*args, **kwargs)¶ Overloaded function.
- GetBodyByName(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, name: unicode) -> pydrake.multibody.multibody_tree.Body
Returns a constant reference to a body that is identified by the string
name
inthis
MultibodyPlant.Raises: RuntimeError if there is no body with the requested name. Raises: RuntimeError if the body name occurs in multiple model instances. See also
HasBodyNamed() to query if there exists a body in
this
MultibodyPlant with a given specified name.- GetBodyByName(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, name: unicode, model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> pydrake.multibody.multibody_tree.Body
Returns a constant reference to the body that is uniquely identified by the string
name
andmodel_instance
inthis
MultibodyPlant.Raises: RuntimeError if there is no body with the requested name. See also
HasBodyNamed() to query if there exists a body in
this
MultibodyPlant with a given specified name.
-
GetBodyFromFrameId
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, arg0: pydrake.geometry.FrameId) → pydrake.multibody.multibody_tree.Body¶ Given a geometry frame identifier, returns a pointer to the body associated with that id (nullptr if there is no such body).
-
GetBodyIndices
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex) → List[pydrake.multibody.multibody_tree.BodyIndex]¶ Returns a list of body indices associated with
model_instance
.
-
GetFrameByName
(*args, **kwargs)¶ Overloaded function.
- GetFrameByName(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, name: unicode) -> pydrake.multibody.multibody_tree.Frame
Returns a constant reference to a frame that is identified by the string
name
inthis
model.Raises: RuntimeError if there is no frame with the requested name. Raises: RuntimeError if the frame name occurs in multiple model instances. See also
HasFrameNamed() to query if there exists a frame in
this
model with a given specified name.- GetFrameByName(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, name: unicode, model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> pydrake.multibody.multibody_tree.Frame
Returns a constant reference to the frame that is uniquely identified by the string
name
inmodel_instance
.Raises: RuntimeError if there is no frame with the requested name. Raises: RuntimeError if model_instance
is not valid for this model.See also
HasFrameNamed() to query if there exists a frame in
this
model with a given specified name.
-
GetJointActuatorByName
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, name: unicode) → pydrake.multibody.multibody_tree.JointActuator¶ Returns a constant reference to an actuator that is identified by the string
name
inthis
MultibodyPlant.Raises: RuntimeError if there is no actuator with the requested name.
Raises: - RuntimeError if the actuator name occurs in multiple model
instances.
See also
HasJointActuatorNamed() to query if there exists an actuator in
this
MultibodyPlant with a given specified name.
-
GetJointByName
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, name: unicode, model_instance: Optional[pydrake.multibody.multibody_tree.ModelInstanceIndex] = None) → pydrake.multibody.multibody_tree.Joint¶ Returns a constant reference to a joint that is identified by the string
name
inthis
MultibodyPlant. If the optional template argument is supplied, then the returned value is downcast to the specifiedJointType
.- Template parameter
JointType
: - The specific type of the Joint to be retrieved. It must be a subclass of Joint.
Raises: - RuntimeError if the named joint is not of type
JointType
or if - there is no Joint with that name.
Raises: RuntimeError if
model_instance
is not valid for this model.See also
HasJointNamed() to query if there exists a joint in
this
MultibodyPlant with a given specified name.- Template parameter
-
GetModelInstanceByName
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, name: unicode) → pydrake.multibody.multibody_tree.ModelInstanceIndex¶ Returns the index to the model instance that is uniquely identified by the string
name
inthis
MultibodyPlant.Raises: RuntimeError if there is no instance with the requested name. See also
HasModelInstanceNamed() to query if there exists an instance in
this
MultibodyPlant with a given specified name.
-
GetModelInstanceName
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex) → unicode¶ Returns the name of a
model_instance
.Raises: - RuntimeError when
model_instance
does not correspond to a - model in this model.
- RuntimeError when
-
GetMutablePositions
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) → numpy.ndarray[float64[m, 1], flags.writeable]¶ (Advanced) Returns a mutable vector reference containing the vector of generalized positions (see warning).
Note
This method returns a reference to existing data, exhibits constant i.e., O(1) time complexity, and runs very quickly.
Warning
You should use SetPositions() instead of this method unless you are fully aware of the possible interactions with the caching mechanism (see dangerous_get_mutable).
Raises: - RuntimeError if the
context
is nullptr or if it does not - correspond to the context for a multibody model.
- RuntimeError if the
-
GetMutablePositionsAndVelocities
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) → numpy.ndarray[float64[m, 1], flags.writeable]¶ (Advanced) Returns a mutable vector containing the vector
[q; v]
of the model withq
the vector of generalized positions andv
the vector of generalized velocities (see warning).Warning
You should use SetPositionsAndVelocities() instead of this method unless you are fully aware of the interactions with the caching mechanism (see dangerous_get_mutable).
Raises: - RuntimeError if the
context
is nullptr or if it does not - correspond to the context for a multibody model.
- RuntimeError if the
-
GetMutableVelocities
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) → numpy.ndarray[float64[m, 1], flags.writeable]¶ See GetMutableVelocities() method above.
-
GetPositions
(*args, **kwargs)¶ Overloaded function.
- GetPositions(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) -> object
Returns a const vector reference containing the vector of generalized positions.
Note
This method returns a reference to existing data, exhibits constant i.e., O(1) time complexity, and runs very quickly.
Raises: - RuntimeError if the
context
does not correspond to the context - for a multibody model.
- GetPositions(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> numpy.ndarray[float64[m, 1]]
Returns an vector containing the generalized positions (
q
) for the given model instance.Raises: - RuntimeError if the
context
does not correspond to the context - for a multibody model.
Note
returns a dense vector of dimension
q.size()
associated withmodel_instance
in O(q.size()
) time.- GetPositions(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) -> numpy.ndarray[float64[m, 1]]
Returns a const vector reference containing the vector of generalized positions.
Note
This method returns a reference to existing data, exhibits constant i.e., O(1) time complexity, and runs very quickly.
Raises: - RuntimeError if the
context
does not correspond to the context - for a multibody model.
- GetPositions(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> numpy.ndarray[float64[m, 1]]
Returns an vector containing the generalized positions (
q
) for the given model instance.Raises: - RuntimeError if the
context
does not correspond to the context - for a multibody model.
Note
returns a dense vector of dimension
q.size()
associated withmodel_instance
in O(q.size()
) time.
-
GetPositionsAndVelocities
(*args, **kwargs)¶ Overloaded function.
- GetPositionsAndVelocities(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) -> numpy.ndarray[float64[m, 1]]
Returns a const vector reference containing the vector
[q; v]
withq
the vector of generalized positions andv
the vector of generalized velocities.Note
This method returns a reference to existing data, exhibits constant i.e., O(1) time complexity, and runs very quickly.
Raises: - RuntimeError if the
context
does not correspond to the context - for a multibody model.
- GetPositionsAndVelocities(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> numpy.ndarray[float64[m, 1]]
Returns the vector
[q; v]
of the model withq
the vector of generalized positions andv
the vector of generalized velocities for model instancemodel_instance
.Raises: - RuntimeError if the
context
does not correspond to the context - for a multibody model or
model_instance
is invalid.
Note
returns a dense vector of dimension
q.size() + v.size()
associated withmodel_instance
in O(q.size()
) time.
-
GetPositionsFromArray
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex, q: numpy.ndarray[float64[m, 1]]) → numpy.ndarray[float64[m, 1]]¶ Returns a vector of generalized positions for
model_instance
from a vectorq_array
of generalized positions for the entire model model. This method throws an exception ifq
is not of size MultibodyPlant::num_positions().
-
GetVelocities
(*args, **kwargs)¶ Overloaded function.
- GetVelocities(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) -> object
Returns a const vector reference containing the generalized velocities.
Note
This method returns a reference to existing data, exhibits constant i.e., O(1) time complexity, and runs very quickly.
- GetVelocities(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> numpy.ndarray[float64[m, 1]]
Returns a vector containing the generalized velocities (
v
) for the given model instance.Raises: - RuntimeError if the
context
does not correspond to the context - for a multibody model.
Note
returns a dense vector of dimension
v.size()
associated withmodel_instance
in O(v.size()
) time.- GetVelocities(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float]) -> numpy.ndarray[float64[m, 1]]
Returns a const vector reference containing the generalized velocities.
Note
This method returns a reference to existing data, exhibits constant i.e., O(1) time complexity, and runs very quickly.
- GetVelocities(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> numpy.ndarray[float64[m, 1]]
Returns a vector containing the generalized velocities (
v
) for the given model instance.Raises: - RuntimeError if the
context
does not correspond to the context - for a multibody model.
Note
returns a dense vector of dimension
v.size()
associated withmodel_instance
in O(v.size()
) time.
-
GetVelocitiesFromArray
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex, q: numpy.ndarray[float64[m, 1]]) → numpy.ndarray[float64[m, 1]]¶ Returns a vector of generalized positions for
model_instance
from a vectorq_array
of generalized positions for the entire model model. This method throws an exception ifq
is not of size MultibodyPlant::num_positions().
-
HasBodyNamed
(*args, **kwargs)¶ Overloaded function.
- HasBodyNamed(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, name: unicode) -> bool
Returns: True
if a body namedname
was added to the MultibodyPlant.See also
AddRigidBody().
Raises: RuntimeError if the body name occurs in multiple model instances. - HasBodyNamed(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, name: unicode, model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> bool
Returns: True
if a body namedname
was added to the MultibodyPlant inmodel_instance
.See also
AddRigidBody().
Raises: RuntimeError if model_instance
is not valid for this model.
-
HasJointNamed
(*args, **kwargs)¶ Overloaded function.
- HasJointNamed(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, name: unicode) -> bool
Returns: True
if a joint namedname
was added to this model.See also
AddJoint().
Raises: RuntimeError if the joint name occurs in multiple model instances. - HasJointNamed(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, name: unicode, model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> bool
Returns: True
if a joint namedname
was added tomodel_instance
.See also
AddJoint().
Raises: RuntimeError if model_instance
is not valid for this model.
-
MapQDotToVelocity
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], qdot: numpy.ndarray[float64[m, 1]]) → numpy.ndarray[float64[m, 1]]¶ Transforms the time derivative
qdot
of the generalized positions vectorq
(stored incontext
) to generalized velocitiesv
. v andq̇
are related linearly byq̇ = N(q)⋅v
. AlthoughN(q)
is not necessarily square, its left pseudo-inverseN⁺(q)
can be used to invert that relationship without residual error, provided thatqdot
is in the range space ofN(q)
(that is, if it could have been produced asq̇ = N(q)⋅v
for somev
). Using the configurationq
stored in the givencontext
this method calculatesv = N⁺(q)⋅q̇
.- Parameter
context
: - The context containing the state of the model.
- Parameter
qdot
: - A vector containing the time derivatives of the generalized
positions. This method aborts if
qdot
is not of size num_positions(). - Parameter
v
: - A valid (non-null) pointer to a vector in
ℛⁿ
with n the number of generalized velocities. This method aborts if v is nullptr or if it is not of size num_velocities().
See also
MapVelocityToQDot()
See also
Mobilizer::MapQDotToVelocity()
- Parameter
-
MapVelocityToQDot
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], v: numpy.ndarray[float64[m, 1]]) → numpy.ndarray[float64[m, 1]]¶ Transforms generalized velocities v to time derivatives
qdot
of the generalized positions vectorq
(stored incontext
). v andqdot
are related linearly byq̇ = N(q)⋅v
. Using the configurationq
stored in the givencontext
this method calculatesq̇ = N(q)⋅v
.- Parameter
context
: - The context containing the state of the model.
- Parameter
v
: - A vector of of generalized velocities for this model. This method aborts if v is not of size num_velocities().
- Parameter
qdot
: - A valid (non-null) pointer to a vector in
ℝⁿ
with n being the number of generalized positions in this model, given bynum_positions()
. This method aborts ifqdot
is nullptr or if it is not of size num_positions().
See also
MapQDotToVelocity()
See also
Mobilizer::MapVelocityToQDot()
- Parameter
-
RegisterAsSourceForSceneGraph
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, scene_graph: pydrake.geometry.SceneGraph) → pydrake.geometry.SourceId¶ Registers
this
plant to serve as a source for an instance of SceneGraph. This registration allows MultibodyPlant to register geometry withscene_graph
for visualization and/or collision queries. Successive registration calls with SceneGraph must be performed on the same instance to which the pointer argumentscene_graph
points to. Failure to do so will result in runtime exceptions.- Parameter
scene_graph
: - A valid non nullptr to the SceneGraph instance for which
this
plant will sever as a source, see SceneGraph documentation for further details.
Returns: the SourceId of this
plant inscene_graph
. It can also later on be retrieved with get_source_id().Raises: RuntimeError if called post-finalize. Raises: RuntimeError if scene_graph
is the nullptr.Raises: RuntimeError if called more than once. - Parameter
-
SetActuationInArray
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex, u_instance: numpy.ndarray[float64[m, 1]], u: numpy.ndarray[float64[m, 1], flags.writeable]) → None¶ Given the actuation values
u_instance
for all actuators inmodel_instance
, this method sets the actuation vector u for the entire model to which this actuator belongs to. This method throws an exception if the size ofu_instance
is not equal to the number of degrees of freedom of all of the actuated joints inmodel_instance
.- Parameter
u_instance
: - Actuation values for the actuators. It must be of size equal to
the number of degrees of freedom of all of the actuated joints in
model_instance
. - Parameter
u
: - The vector containing the actuation values for the entire model.
- Parameter
-
SetDefaultState
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], state: pydrake.systems.framework.State_[float]) → None¶ Sets the state in
context
so that generalized positions and velocities are zero.Raises: RuntimeError if called pre-finalize. See Finalize().
-
SetFreeBodyPose
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], body: pydrake.multibody.multibody_tree.Body, X_WB: pydrake.common.eigen_geometry.Isometry3) → None¶ Sets
context
to store the poseX_WB
of a givenbody
B in the world frame W.Note
In general setting the pose and/or velocity of a body in the model would involve a complex inverse kinematics problem. This method allows us to simplify this process when we know the body is free in space.
Raises: RuntimeError if body
is not a free body in the model.Raises: RuntimeError if called pre-finalize.
-
SetFreeBodySpatialVelocity
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, body: pydrake.multibody.multibody_tree.Body, V_WB: pydrake.multibody.multibody_tree.math.SpatialVelocity, context: pydrake.systems.framework.Context_[float]) → None¶ Sets
context
to store the spatial velocityV_WB
of a givenbody
B in the world frame W.Note
In general setting the pose and/or velocity of a body in the model would involve a complex inverse kinematics problem. This method allows us to simplify this process when we know the body is free in space.
Raises: RuntimeError if body
is not a free body in the model.Raises: RuntimeError if called pre-finalize.
-
SetPositions
(*args, **kwargs)¶ Overloaded function.
- SetPositions(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], q: numpy.ndarray[float64[m, 1]]) -> None
Sets all generalized positions from the given vector.
Raises: - RuntimeError if the
context
is nullptr, if the context does - not correspond to the context for a multibody model, or if the
- length of
q
is not equal tonum_positions()
.
- SetPositions(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex, q: numpy.ndarray[float64[m, 1]]) -> None
Sets all generalized positions from the given vector.
Raises: - RuntimeError if the
context
is nullptr, if the context does - not correspond to the context for a multibody model, or if the
- length of
q
is not equal tonum_positions()
.
-
SetPositionsAndVelocities
(*args, **kwargs)¶ Overloaded function.
- SetPositionsAndVelocities(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], q_v: numpy.ndarray[float64[m, 1]]) -> None
Sets all generalized positions and velocities from the given vector [q; v].
Raises: - RuntimeError if the
context
is nullptr, if the context does - not correspond to the context for a multibody model, or if the
- length of
q_v
is not equal to ``num_positions() + - num_velocities()``.
- SetPositionsAndVelocities(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex, q_v: numpy.ndarray[float64[m, 1]]) -> None
Sets generalized positions and velocities from the given vector [q; v] for the specified model instance.
Raises: - RuntimeError if the
context
is nullptr, if the context does - not correspond to the context for a multibody model, if the model
- instance index is invalid, or if the length of
q_v
is not - equal to ``num_positions(model_instance) +
- num_velocities(model_instance)``.
-
SetPositionsInArray
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex, q_instance: numpy.ndarray[float64[m, 1]], q: numpy.ndarray[float64[m, 1], flags.writeable]) → None¶ Sets the vector of generalized positions for
model_instance
inq
usingq_instance
, leaving all other elements in the array untouched. This method throws an exception ifq
is not of size MultibodyPlant::num_positions() orq_instance
is not of sizeMultibodyPlant::num_positions(model_instance)
.
-
SetVelocities
(*args, **kwargs)¶ Overloaded function.
- SetVelocities(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], v: numpy.ndarray[float64[m, 1]]) -> None
Sets all generalized velocities from the given vector.
Raises: - RuntimeError if the
context
is nullptr, if the context does - not correspond to the context for a multibody model, or if the
- length of
v
is not equal tonum_velocities()
.
- SetVelocities(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, context: pydrake.systems.framework.Context_[float], model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex, v: numpy.ndarray[float64[m, 1]]) -> None
Sets the generalized velocities for a particular model instance from the given vector.
Raises: - RuntimeError if the
context
is nullptr, if the context does - not correspond to the context for a multibody model, if the model
- instance index is invalid, or if the length of
v_instance
is - not equal to
num_velocities(model_instance)
.
-
SetVelocitiesInArray
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex, v_instance: numpy.ndarray[float64[m, 1]], v: numpy.ndarray[float64[m, 1], flags.writeable]) → None¶ Sets the vector of generalized velocities for
model_instance
inv
usingv_instance
, leaving all other elements in the array untouched. This method throws an exception ifv
is not of size MultibodyPlant::num_velocities() orv_instance
is not of sizeMultibodyPlant::num_positions(model_instance)
.
-
WeldFrames
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, A: pydrake.multibody.multibody_tree.Frame, B: pydrake.multibody.multibody_tree.Frame, X_AB: pydrake.common.eigen_geometry.Isometry3 = <pydrake.common.eigen_geometry.Isometry3 object at 0x7efe8d850f70>) → pydrake.multibody.multibody_tree.WeldJoint¶ Welds frames A and B with relative pose
X_AB
. That is, the pose of frame B in frame A is fixed, with valueX_AB
. The call to this method creates and adds a new WeldJoint to the model. The new WeldJoint is named as: A.name() + “_welds_to_” + B.name().Returns: a constant reference to the WeldJoint welding frames A and B.
-
__init__
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, time_step: float = 0.0) → None¶
-
geometry_source_is_registered
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → bool¶ Returns
True
ifthis
MultibodyPlant was registered with a SceneGraph. This method can be called at any time during the lifetime ofthis
plant to query ifthis
plant has been registered with a SceneGraph, either pre- or post-finalize, see Finalize().
-
get_actuation_input_port
(*args, **kwargs)¶ Overloaded function.
- get_actuation_input_port(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) -> pydrake.systems.framework.InputPort_[float]
Returns a constant reference to the input port for external actuation for the case where only one model instance has actuated dofs. This input port is a vector valued port, which can be set with JointActuator::set_actuation_vector().
- Precondition:
- Finalize() was already called on
this
plant.
Raises: - RuntimeError if called before Finalize(), if the model does not
- contain any actuators, or if multiple model instances have
- actuated dofs.
- get_actuation_input_port(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, arg0: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> pydrake.systems.framework.InputPort_[float]
Returns a constant reference to the input port for external actuation for a specific model instance. This input port is a vector valued port, which can be set with JointActuator::set_actuation_vector().
- Precondition:
- Finalize() was already called on
this
plant.
Raises: - RuntimeError if called before Finalize() or if the model instance
- does not contain any actuators.
Raises: RuntimeError if the model instance does not exist.
-
get_body
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, body_index: pydrake.multibody.multibody_tree.BodyIndex) → pydrake.multibody.multibody_tree.Body¶ Returns a constant reference to the body with unique index
body_index
.Raises: - RuntimeError if
body_index
does not correspond to a body in - this model.
- RuntimeError if
-
get_contact_results_output_port
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → pydrake.systems.framework.OutputPort_[float]¶ Returns a constant reference to the port that outputs ContactResults.
Raises: - RuntimeError if
this
plant is not modeled as a discrete system - with periodic updates.
Raises: RuntimeError if called pre-finalize, see Finalize().
- RuntimeError if
-
get_continuous_state_output_port
(*args, **kwargs)¶ Overloaded function.
- get_continuous_state_output_port(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) -> pydrake.systems.framework.OutputPort_[float]
Returns a constant reference to the output port for the full continuous state of the model.
- Precondition:
- Finalize() was already called on
this
plant.
- get_continuous_state_output_port(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, arg0: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> pydrake.systems.framework.OutputPort_[float]
Returns a constant reference to the output port for the continuous state of a specific model instance.
- Precondition:
- Finalize() was already called on
this
plant.
Raises: - RuntimeError if called before Finalize() or if the model instance
- does not have any state.
Raises: RuntimeError if the model instance does not exist.
-
get_frame
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, frame_index: pydrake.multibody.multibody_tree.FrameIndex) → pydrake.multibody.multibody_tree.Frame¶ Returns a constant reference to the frame with unique index
frame_index
.Raises: - RuntimeError if
frame_index
does not correspond to a frame in - this plant.
- RuntimeError if
-
get_geometry_poses_output_port
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → pydrake.systems.framework.OutputPort_[float]¶ Returns the output port of frames’ poses to communicate with a SceneGraph.
Raises: RuntimeError if this system was not registered with a SceneGraph.
-
get_geometry_query_input_port
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → pydrake.systems.framework.InputPort_[float]¶ Returns a constant reference to the input port used to perform geometric queries on a SceneGraph. See SceneGraph::get_query_output_port(). Refer to section geometry_registration of this class’s documentation for further details on collision geometry registration and connection with a SceneGraph.
Raises: RuntimeError if this system was not registered with a SceneGraph.
-
get_joint
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, joint_index: pydrake.multibody.multibody_tree.JointIndex) → pydrake.multibody.multibody_tree.Joint¶ Returns a constant reference to the joint with unique index
joint_index
.Raises: - RuntimeError when
joint_index
does not correspond to a joint - in this model.
- RuntimeError when
-
get_joint_actuator
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, actuator_index: pydrake.multibody.multibody_tree.JointActuatorIndex) → pydrake.multibody.multibody_tree.JointActuator¶ Returns a constant reference to the joint actuator with unique index
actuator_index
.Raises: - RuntimeError if
actuator_index
does not correspond to a joint - actuator in this tree.
- RuntimeError if
-
get_source_id
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → Optional[pydrake.geometry.SourceId]¶ Returns the unique id identifying
this
plant as a source for a SceneGraph. Returnsnullopt
ifthis
plant did not register any geometry. This method can be called at any time during the lifetime ofthis
plant to query ifthis
plant has been registered with a SceneGraph, either pre- or post-finalize, see Finalize(). However, a geometry::SourceId is only assigned once at the first call of any of this plant’s geometry registration methods, and it does not change after that. Post-finalize calls will always return the same value.
-
is_finalized
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → bool¶ Returns
True
if this MultibodyPlant was finalized with a call to Finalize().See also
Finalize().
-
message_model
= u'Please use tree().'¶
-
model
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → pydrake.multibody.multibody_tree.MultibodyTree¶
-
num_actuated_dofs
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → int¶ Returns the total number of actuated degrees of freedom. That is, the vector of actuation values u has this size. See AddJointActuator().
-
num_actuators
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → int¶ Returns the number of joint actuators in the model.
See also
AddJointActuator().
-
num_bodies
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → int¶ Returns the number of bodies in the model, including the “world” body, which is always part of the model.
See also
AddRigidBody().
-
num_frames
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → int¶ Returns the number of Frame objects in this model. Frames include body frames associated with each of the bodies, including the world body. This means the minimum number of frames is one.
-
num_joints
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → int¶ Returns the number of joints in the model.
See also
AddJoint().
-
num_model_instances
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → int¶ Returns the number of model instances in the model.
See also
AddModelInstance().
-
num_multibody_states
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → int¶ Returns the size of the multibody system state vector
x = [q; v]
. This will be num_positions() plus num_velocities().
-
num_positions
(*args, **kwargs)¶ Overloaded function.
- num_positions(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) -> int
Returns the size of the generalized position vector
q
for this model.- num_positions(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, model_instance: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> int
Returns the size of the generalized position vector
q
for a specific model instance.
-
num_velocities
(*args, **kwargs)¶ Overloaded function.
- num_velocities(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) -> int
Returns the size of the generalized velocity vector
v
for this model.- num_velocities(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant, arg0: pydrake.multibody.multibody_tree.ModelInstanceIndex) -> int
Returns the size of the generalized velocity vector
v
for a specific model instance.
-
tree
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → pydrake.multibody.multibody_tree.MultibodyTree¶ Returns a const reference to the MultibodyTree owned by this class.
-
world_body
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → pydrake.multibody.multibody_tree.RigidBody¶ Returns a constant reference to the world body.
-
world_frame
(self: pydrake.multibody.multibody_tree.multibody_plant.MultibodyPlant) → pydrake.multibody.multibody_tree.BodyFrame¶ Returns a constant reference to the world frame.
-
class
pydrake.multibody.multibody_tree.multibody_plant.
PointPairContactInfo
¶ -
__init__
(self: pydrake.multibody.multibody_tree.multibody_plant.PointPairContactInfo, bodyA_index: pydrake.multibody.multibody_tree.BodyIndex, bodyB_index: pydrake.multibody.multibody_tree.BodyIndex, f_Bc_W: numpy.ndarray[float64[3, 1]], p_WC: numpy.ndarray[float64[3, 1]], separation_speed: float, slip_speed: float, point_pair: pydrake.geometry.PenetrationAsPointPair) → None¶
-
bodyA_index
(self: pydrake.multibody.multibody_tree.multibody_plant.PointPairContactInfo) → pydrake.multibody.multibody_tree.BodyIndex¶
-
bodyB_index
(self: pydrake.multibody.multibody_tree.multibody_plant.PointPairContactInfo) → pydrake.multibody.multibody_tree.BodyIndex¶
-
contact_force
(self: pydrake.multibody.multibody_tree.multibody_plant.PointPairContactInfo) → numpy.ndarray[float64[3, 1]]¶
-
contact_point
(self: pydrake.multibody.multibody_tree.multibody_plant.PointPairContactInfo) → numpy.ndarray[float64[3, 1]]¶
-
separation_speed
(self: pydrake.multibody.multibody_tree.multibody_plant.PointPairContactInfo) → float¶
-
slip_speed
(self: pydrake.multibody.multibody_tree.multibody_plant.PointPairContactInfo) → float¶
-


freeCodeCamp Survey Form
Thank you for taking the time to help us improve the platform
Name
Email
Age
(Optional)
Which option best describes your current role?
Student
Full Time Job
Full Time Learner
Prefer Not To Say
Other
Would you recommend freeCodeCamp to a friend?
Definitely
Maybe
Not sure
What would you like to see improved?
Front-end Projects
Back-end Projects
Full Stack Projects
Any comments or suggestions?
Submit


The goal of this document is to get you up and running with BaMORC as quickly as possible. BaMORC stands for the Bayesian Model Optimized Reference Correction (BaMORC) Method for Assigned and Unassigned Protein NMR Spectra. For a detailed explanation of the algorithm, please refer to “Automatic 13C chemical shift reference correction for unassigned protein NMR spectra”.
There are two important parts to BaMORC: the bamorc()
reference correction function for assigned 13C protein NMR spectra, and the unassigned_bamorc()
reference correction function for unassigned 13C protein NMR spectra. In the first section, you’ll learn about the basics of running both of these functions. In the second section, you will dive into the basics of input data process, and in third section, you’ll learn a little more about the functions used behind-the-scenes by the BaMORC algorithm.
To make a correction, first load BaMORC, then call bamorc()
or unassigned_bamorc()
with the correct arguments:
Here we will using the built-in data to demonstrate the arguments that will be passed into bamorc()
.
## Arguments:
sequence = paste(RefDB_data$carbonDat[[1]]$AA, collapse = "")
secondary_structure = paste(RefDB_data$carbonDat[[1]]$SS, collapse = "")
chemical_shifts_input = RefDB_data$carbonDat[[1]][, c(4, 5)]
from = -5
to = 5
## Running bamorc() function:
bamorc(sequence = sequence, secondary_structure = secondary_structure,
chemical_shifts_input = chemical_shifts_input, from = -5,
to = 5)
#> [1] 0.0142443
sequence
: secondary_structure
: chemical_shifts_input
: <data frame n by 2> the carbon 13 chemical shift of the protein.from
and to
: from
must be lower than to
.The length of the sequence
and secondary_structure
should be the same, if not please assign secondary_structure = NULL
, however, the peaklist groups number could be more or less than the length of the sequence. Often peak lists will have fewer CA/CB pairs than the length of the protein sequence.
Printing an argument object gives you some useful information: the actual format, the size, the object type, and if it’s a string.
Next, we will use the built-in data to demonstrate the arguments that will be passed in the unassigned_bamorc()
. The output will be slightly different each time it runs, due to the randomness of the optimization.
## Arguments:enerate a temperary sample NMR spectra file and
## later will be removed.
sequence = "RPAFCLEPPYAGPGKARIIRYFYNAAAGAAQAFVYGGVRAKRNNFASAADALAACAAA"
sample_data_generator(input_type = "ssc_sample")
file_path = "./bpti_HNcoCACB.txt" # temperary sample file path.
## Running unassigned_bamorc() function: unassigned_bamorc
## will take a while to run
unassigned_bamorc(peakList_file_loc = file_path, sequence = sequence,
secondary_structure = NULL, from = -5, to = 5)
## Delete the temperary sample file.
unlink("./bpti_HNcoCACB.txt")
The data passed in both above functions should be pre-processed. Luckly, we provide a variety of helper functions. See the following on how to process the data.
There are three file parsing functions within the BaMORC package: read_raw_file()
, read_nmrstar_file()
, and read_db_file()
. These functions handle a wide range of the input files. You can check the sample file using the sample_data_generator()
for a recommended format:
Delimiter of white space:
## Arguments:enerate a temperary sample NMR spectra file and
## later will be removed.
input_type = "ws"
sample_data_generator(input_type = input_type)
## Running reading function
head(read_raw_file(file_path = "sample_input_ws.txt", delim = "ws"))
#> Parsed with column specification:
#> cols(
#> X1 = col_double(),
#> X2 = col_double()
#> )
#> [[1]]
#> [1] "NHQDHNNFQTLPYVPCSTCEGNLACLSLCHIE"
#>
#> [[2]]
#> # A tibble: 32 x 2
#> X1 X2
#> <dbl> <dbl>
#> 1 NA 38.6
#> 2 NA 28.8
#> 3 56.3 30.4
#> 4 54.4 41.3
#> 5 NA 28.8
#> 6 55.1 38.9
#> 7 NA 38.8
#> 8 NA 39.3
#> 9 NA 30.3
#> 10 62.1 69.8
#> # ... with 22 more rows
unlink("sample_input_ws.txt")
Delimiter of comma:
## Arguments:enerate a temperary sample NMR spectra file and
## later will be removed.
input_type = "csv"
sample_data_generator(input_type = input_type)
## Running reading function
head(read_raw_file(file_path = "sample_input.csv", delim = "comma"))
#> Parsed with column specification:
#> cols(
#> X1 = col_double(),
#> X2 = col_double()
#> )
#> Warning in rbind(names(probs), probs_f): number of columns of result is not
#> a multiple of vector length (arg 2)
#> Warning: 1 parsing failure.
#> row # A tibble: 1 x 5 col row col expected actual file expected <int> <chr> <chr> <chr> <chr> actual 1 33 <NA> 2 columns 1 columns 'sample_input.csv' file # A tibble: 1 x 5
#> [[1]]
#> [1] "NHQDHNNFQTLPYVPCSTCEGNLACLSLCHIE"
#>
#> [[2]]
#> # A tibble: 33 x 2
#> X1 X2
#> <dbl> <dbl>
#> 1 NA 38.6
#> 2 NA 28.8
#> 3 56.3 30.4
#> 4 54.4 41.3
#> 5 NA 28.8
#> 6 55.1 38.9
#> 7 NA 38.8
#> 8 NA 39.3
#> 9 NA 30.3
#> 10 62.1 69.8
#> # ... with 23 more rows
unlink("sample_input.csv")
Delimiter of semicolon:
## Arguments:enerate a temperary sample NMR spectra file and
## later will be removed.
input_type = "sc"
sample_data_generator(input_type = input_type)
## Running reading function
head(read_raw_file(file_path = "sample_input_sc.txt", delim = "semicolon"))
#> Parsed with column specification:
#> cols(
#> X1 = col_double(),
#> X2 = col_double()
#> )
#> [[1]]
#> [1] "NHQDHNNFQTLPYVPCSTCEGNLACLSLCHIE"
#>
#> [[2]]
#> # A tibble: 32 x 2
#> X1 X2
#> <dbl> <dbl>
#> 1 NA 38.6
#> 2 NA 28.8
#> 3 56.3 30.4
#> 4 54.4 41.3
#> 5 NA 28.8
#> 6 55.1 38.9
#> 7 NA 38.8
#> 8 NA 39.3
#> 9 NA 30.3
#> 10 62.1 69.8
#> # ... with 22 more rows
unlink("sample_input_sc.txt")
read_raw_file()
: parses user-provided file in customed format as show above examples.
read_nmrstar_file()
: parses user-provided file in BMRB Star 2/3 format.
## Download a BMRB file
library(BMRBr)
bmrb_download(4020, output_dir = "./")
## Read in BMRB file and procec
file_path = "bmr4020.str"
head(read_nmrstar_file(file_path = file_path))
## Delete downloaded BMRB file
unlink("./bmr4020.str")
read_db_file()
: parses file from BMRB by a given entry ID.Secondary structure information predicted based on the protein sequence is required for the optimization. This is predicted through the JPred and jpredapi.
The BaMORC algorithm minimizes the difference between the actual relative cummulative frequency (RCF) of the protein sequence and the estimated RCF predicted from the chemical shifts information. The statistical functions used by the algorithm are shown below with examples. For detailed function descriptions, please see the reference:
calculate_aa_prob()
: returns the probability (density) for a certain type of amino acid based on a chi-squared statistics wtih 2 degrees of freedom.calculate_aa_prob(chi_squared_stat = c(0.05, 0.1, 0.5), df = 2)
#> [1] 0.4876550 0.4756147 0.3894004
calculate_chi_squared_stat()
: given a pair of alpha and beta carbons chemical shifts, this function will return a list of calculated chi-squared statistics based on the combination of amino acid typings and secondary structures. Here we illustrate with a pair of chemical shifts from alpha and beta carbon.calculate_chi_squared_stat(cacb_pair = c(54, 45))
#> AA H B C
#> 1: A 1023.16868895477<PHONE_NUMBER>75473<PHONE_NUMBER>95045
#> 2: B<PHONE_NUMBER>68627 54.4937018085712 74.2438106347521
#> 3: C 24.0426461856623 6.02618817827703 23.2477754200126
#> 4: D 14.4848786940741 2.79850128029531 10.2715883462805
#> 5: E 13.3897615181103 1.88818580572447 4.60208889084118
#> 6: F<PHONE_NUMBER>03217 77.9438324817418 62.5815610717518
#> 7: H<PHONE_NUMBER>10107 53.4257171238817 91.6072511229365
#> 8: I<PHONE_NUMBER>63356 44.4933903131377 94.8605497904786
#> 9: K<PHONE_NUMBER>25817 35.9002492383691 39.0974374716513
#> 10: L<PHONE_NUMBER>76134 19.1632752720135 22.6939781262421
#> 11: M 14.8396700069463 0.383003397426531 2.60892370474794
#> 12: N<PHONE_NUMBER>66307 34.5192736984713 53.7891077582836
#> 13: P 89.4591494720313 19.26900894692 26.5279676961367
#> 14: Q 40.3446974047416 5.81357432329253 11.1635747587969
#> 15: R<PHONE_NUMBER>22648<PHONE_NUMBER>03255<PHONE_NUMBER>03036
#> 16: S<PHONE_NUMBER>42293<PHONE_NUMBER>65393<PHONE_NUMBER>00641
#> 17: T<PHONE_NUMBER>50779<PHONE_NUMBER>97962<PHONE_NUMBER>24244
#> 18: V 58.3956321465275 6.77558973670799 13.8132678105348
#> 19: W<PHONE_NUMBER>10673 63.1703556188059 77.6629767003917
#> 20: Y<PHONE_NUMBER>18581 47.5540232633832 80.5896644421314
calculate_rcf()
: calculates the relative cummulative freqeucny of amino acid and secondary structure combination.## Arguments:
sequence = paste(RefDB_data$carbonDat[[1]]$AA, collapse = "")
secondary_structure = paste(RefDB_data$carbonDat[[1]]$SS, collapse = "")
## Function:
calculate_rcf(sequence = sequence, secondary_structure = secondary_structure)
#> [[1]]
#> [1] "S-C" "I-C" "P-C" "C-B" "L-B" "L-B" "S-B" "P-C" "W-B" "S-B" "E-B"
#> [12] "W-B" "S-B" "D-C" "C-B" "S-B" "V-B" "T-C" "C-C" "K-B" "M-B" "R-B"
#> [23] "T-B" "R-B" "Q-B" "R-B" "M-B" "L-B" "K-B" "S-C" "L-C" "A-C" "E-C"
#> [34] "L-C" "D-C" "C-C" "N-C" "E-C" "D-C" "L-B" "E-B" "Q-B" "A-B" "E-B"
#> [45] "K-B" "C-B" "M-B" "L-B" "P-B" "E-B" "C-C" "P-C"
#>
#> [[2]]
#> AA_SS Freq
#> 1 A-B 0.01923077
#> 2 A-C 0.01923077
#> 3 C-B 0.05769231
#> 4 C-C 0.05769231
#> 5 D-C 0.05769231
#> 6 E-B 0.07692308
#> 7 E-C 0.03846154
#> 8 I-C 0.01923077
#> 9 K-B 0.05769231
#> 10 L-B 0.09615385
#> 11 L-C 0.03846154
#> 12 M-B 0.05769231
#> 13 N-C 0.01923077
#> 14 P-B 0.01923077
#> 15 P-C 0.05769231
#> 16 Q-B 0.03846154
#> 17 R-B 0.05769231
#> 18 S-B 0.07692308
#> 19 S-C 0.03846154
#> 20 T-B 0.01923077
#> 21 T-C 0.01923077
#> 22 V-B 0.01923077
#> 23 W-B 0.03846154
calculate_mse()
: calculates mean squared error for each correction value (step).


In financial industry,banks rely on telemarketing to gain more term deposit,which involves bank agents calling them directly. Ideally banks wants to contact only those clients who will subscribe in order to keep the scale and cost of their marketing campaign under control.However,even though they have a lot of information about their clients and economic development,they do not know who will subcribe after being contacted.Trying to contact all the clients will be costly,unrealistic and ineffective.
A machine learning algorithm can be developed on historical client data such as:age of the client,their job type,their marital status,duration of last call with client,day and month of the call etc.This algorithm will predict which clients will likely subscribe the term deposit before agents make phone calls.It will also help the banks to decide how many clients needs to be contacted in order to meet their business target,based on which banks can plan the scope,budget and resources of marketing campaign accordingly.
What is a term deposit?
A term deposit is a cash investment held at a financial institution.Your money is invested for an agreed rate of interest
over a fixed amount of time,or term.Term deposits can be invested into a bank,building,society or credit union.
When the money is deposited,the customer understands that the money is there for the pre-determined which usually ranges from 1 month to 5 years
and the interest rate is guaranteed not to change for that nominated period of time.Typically the money can only be withdrawn at the
end of the period-or earlier with a penalty attached.


Getting new libraries into cpp-netlib.
This document outlines how we get new libraris accepted as
part of cpp-netlib
The maintainers and members of the community generally like seeing well-prepared proposals for libraries to be included. The reason for this is so that we waste as little time from everyone who's going to be involved in the process as possible. Therefore we ask that before you bring an idea to the table, please prepare the following information (even only when sending an email to the mailing list).
Once you have these things, fire off an email to the mailing list citing the above four preparation sections.
All discussions should occur in the mailing list for issues not related to the design documentation. If the design doc is a shared Google Document comments will be made on the document itself. For everything else, the discussions should be done on the mailing list.
The discussion will be considered concluded when all the maintainers of the library agree that the proposal makes sense and that it's something the community wants to have in the library. The process will be tracked by a formal survey on the mailing list run by one of the maintainers.
Once everybody's convinced that things should move forward, then maintainers and interested contributors hunker down to start collaborating on the development of the library.
The collaboration process is intended to be much simpler: all discussions on progress and questions to clarify happen on the mailing list. Matters affecting progress — developers missing in action, thorny implementation details, blockers, and style questions should be discussed all in the open. We encourage this so that everyone in the community is involved in the process where we exclude nobody's opinion and contributions.
As far as development is concerned, there are two main ways of getting the development done. Each one has its merits so we present both.
The fork process is straight-forward — whoever proposed the library and those who have pledged to contribute to the implementation shall fork the main repository and develop in parallel as the main repository. They can send progress reports to the main developer list and have the partially complete work merged into the master branch as it gets completed. All changes can be isolated to an external fork where changes are meant to be integrated before being submitted in bulk to the main repo as a single PR.
This process effectively promotes whomever is driving and owning the process as a maintainer of cpp-netlib. The downside to this is that it's a lot of responsibility and may be time consuming.
The submodule approach is much more decoupled and allows for having the implemented library be as stand-alone as possible. Some libraries in cpp-netlib are already submodules and are maintained separately by the corresponding maintainer.
The problem with this approach is that coordinating breaking changes on multiple interacting submodules will be much harder. It also makes the release/development process much more cumbersome than the fork model. It also makes it harder to enforce the style guide and development processes on the submodule.
The preferred mode of development is the fork model, where coordination is much closer and much more explicit. It also allows the maintainers to easily cut releases and maintain a single repository unto which all changes and history can be kept.
Only in rare circumstances will a submodule actually be
preferred — for instance, if the project has already been
in existence before being accepted into cpp-netlib
or if it's made sufficiently stand-alone for purposes of
inclusion into the standard library.
Inclusion entails three specific things which will
differentiate any other library from an accepted
cpp-netlib
library.
cpp-netlib
get maintainership over the library
that's accepted, and the proposer and main developers of the
library become maintainers of cpp-netlib
as well. We
usually defer library-specific issues to the main library
maintainer/developer but in case of whole-library and community
decisions all maintainers get the same responibilities.cpp-netlib
shall be distributed as part of the main
distribution.
On the note about maintainership — once someone is promoted to maintainer of cpp-netlib, that person gets administrative rights to the project repository. In the event that someone becomes inactive or relinquishes the role, only then will that person be considered an ex-maintainer.
This means, once someone is deemed a maintainer, he'll always be considered a maintainer unless he becomes inactive or relinquishes that role.


Why Work with Us
Cum doctus civibus efficiantur in imperdiet deterruisset.
Your compensation
What you earn per order depends on your experience and ratings.
Choose when to work
You’ll be self-employed and free to work to your own availability.
You will only need
Your vehicle (motorcycle, bike or car), an iPhone or Android device.
Frequent questions
Here you'll be able find answers your questions
Nihil anim keffiyeh helvetica, craft beer labore wes anderson cred nesciunt sapiente ea proident. Ad vegan excepteur butcher vice lomo. Leggings occaecat craft beer farm-to-table, raw denim aesthetic synth nesciunt you probably haven't heard of them accusamus labore sustainable VHS.
Nihil anim keffiyeh helvetica, craft beer labore wes anderson cred nesciunt sapiente ea proident. Ad vegan excepteur butcher vice lomo. Leggings occaecat craft beer farm-to-table, raw denim aesthetic synth nesciunt you probably haven't heard of them accusamus labore sustainable VHS.
Anim pariatur cliche reprehenderit, enim eiusmod high life accusamus terry richardson ad squid. 3 wolf moon officia aute, non cupidatat skateboard dolor brunch. Food truck quinoa nesciunt laborum eiusmod. Brunch 3 wolf moon tempor, sunt aliqua put a bird on it squid single-origin coffee nulla assumenda shoreditch et.
Nihil anim keffiyeh helvetica, craft beer labore wes anderson cred nesciunt sapiente ea proident. Ad vegan excepteur butcher vice lomo. Leggings occaecat craft beer farm-to-table, raw denim aesthetic synth nesciunt you probably haven't heard of them accusamus labore sustainable VHS.
Anim pariatur cliche reprehenderit, enim eiusmod high life accusamus terry richardson ad squid. 3 wolf moon officia aute, non cupidatat skateboard dolor brunch. Food truck quinoa nesciunt laborum eiusmod. Brunch 3 wolf moon tempor, sunt aliqua put a bird on it squid single-origin coffee nulla assumenda shoreditch et.
Apply Now
Note that you must be over 18 years old


The rise of machine learning in recent decades has generated a renewed interest in online decision-making, where algorithms are equipped only with partial information about the world, and must take actions in the face of uncertainty about the future.  Two of the most general models are “probability free” (aka “worst-case,” or “adversarial”), in the sense that one can measure the performance of algorithms without making distributional assumptions on the input.
Competitive analysis
One such model goes by the name of competitive analysis, and has been studied in theoretical CS since the 1970s. Imagine, for instance, that one maintains a binary search tree (BST) with key-value pairs at the nodes. At every point in time, a key is requested, and the corresponding value is looked up via binary search. Along the search path, the algorithm is allowed to modify the tree using standard tree rotation operations.
The cost of such an algorithm is the average number of binary search steps per key-lookup over a long sequence of requests. To minimize the cost, it is beneficial for the algorithm to dynamically rebalance the tree so that frequently-requested keys are near the root. Sleator and Tarjan had this model in mind when they invented the Splay Tree data structure. Their (still unproven) Dynamic Optimality Conjecture asserts that, for every sequence of key requests, the number of operations used by the Splay Tree is within a constant factor of the number of operations used by any binary search tree, even an offline algorithm that is allowed to see the entire sequence of key requests in advance. (This is a very strong requirement! We make no assumption on the structure of the request sequence, and have to compare our performance to an algorithm that sees the entire request sequence up front.)
In the language of competitive analysis, the conjecture states that the Splay Tree algorithm is “competitive.” In general, an $\alpha$-competitive online algorithm is one whose total cost on every input sequence is within an $\alpha$ factor of the cost incurred by the optimal offline algorithm that sees the whole input sequence in advance.
Multi-arm bandits
Another compelling model arising in online learning is the multi-armed bandit problem. Here, an agent has a set $\mathcal{A}$ of feasible actions. At time $t=1,2,3,\ldots$, the agent plays an action $a_t \in \mathcal{A}$, and only then the cost of that action is revealed. Imagine, for instance, choosing an advertisement $a_t \in \mathcal{A}$ to present to a user, and then learning afterward the probability it led to a sale. The goal of an algorithm in this model is to achieve a total cost (often called the loss) that is not too much worse than the best fixed action in hindsight. The gap between the two is called the regret.
At first blush, it may seem that these two models (multi-arm bandits and competitive analysis) are quite different. But their relationship rests on a common theme in machine learning: The intimate connection between stability and generalization. A competitive binary search tree algorithm aspires to be stable in the sense that the search tree changes little between lookups because the requested key is often near the root. A low-regret advertiser aspires for her decisions to generalize in the sense that her past observations about users are predictive of their future actions. (One can consult a more in depth look at this connection in the context of Metrical Task Systems.)
Hedging and entropic regularization
A fundamental feature of algorithms designed in both models is hedging, i.e., making decisions now that protect against the cost of uncertainty in future inputs. In the bandit model, where one only learns the cost associated to the action played, hedging involves exploring the action space (the cost protected against here is opportunity cost). In competitive analysis, one can think of hedging as maintaining a state that avoids exploitation by an adversary. For instance, if there are 10 keys that are very frequently requested in a BST, hedging might involve a preference for a configuration in which all 10 keys are within distance 100 of the root, rather than a configuration in which 9 keys are within distance 3 and the 10th key is at distance 1000. This might be preferable even if those 9 keys are requested twice as often as the 10th.
In these settings, hedging is a tradeoff between cost (or utility) and entropy. In modern play of no-limit Texas hold ‘em, this tradeoff is now explicit in the vernacular: Professional players talk of “balancing their range.” For instance, it generally makes sense to bet with strong hands, and even to bet more as a hand gets stronger. But a player has to weigh this against their loss in entropy (from the perspective of an observer who does not know their hole cards): If I only go all-in before the flop with aces, my opponent will be able to play optimally against me whenever that occurs.
The idea of adding an entropic regularizer to the cost function has played a central (and rather explicit) role in online learning. The possible application of these ideas to competitive analysis was already suggested in work of Blum and Burch (2000) and more recently in a paper conceived at Berkeley by Abernethy, Barlett, Buchbinder, and Stanton (2010). Those early attempts, while prescient, were not able to yield better general approaches for the classical problems in online algorithms.
But a collaboration seeded at the Simons Institute, and spanning from the Algorithmic Spectral Graph Theory program (Fall 2014) to the Continuous and Discrete Optimization program three years later was key in developing a theory of entropic regularization strong enough to attack some of the long-standing open problems in the field.
The randomized $k$-server conjecture
The $k$-server problem has been referred to as the “holy grail” of online algorithms, largely because of the central role it has played in the development of the field. Fix an integer $k \geq 1$ and let $(X,d)$ denote a metric space. The input is a sequence $\left\langle \rho_1,\rho_2, \ldots \right\rangle$ of requests $\rho_t \in X$ that arrive online. The algorithm maintain a configuration of $k$ servers at points of $X$, and at time $t=1,2,\ldots$, must move one of the servers to $\rho_t$ to service the request. The cost incurred is the total server movement of the algorithm (in the metric $d$).
Koutsoupias and Papadimitriou famously established that the deterministic Work Function Algorithm is $2k-1$ competitive. It has long been conjectured that randomized online algorithms should be capable of achieving a $(\log k)^{O(1)}$ competitive ratio (a strong version of the conjecture asserts that the competitive ratio is $\Theta(\log k)$ for every metric space on more than $k$ points). Over the course of a decade, primal-dual algorithms were the weapon of choice, culminating in a result of Bansal, Buchbinder, Mądry, and Naor that established a $\mathrm{poly}(\log n)$-competitive algorithm for the case when the underlying metric space has $n$ points.
From Berkeley, to Seattle, to Cambridge, and back
During the reunion workshop for the ASGT program, I spoke about joint work that Prasad Raghavendra, David Steurer, and I had completed a year earlier establishing lower bounds on the size of semidefinite programming relaxations. A major theme in that work is the use of quantum entropy maximization. After my talk extoling the virtues of entropy maximizers, Olek Mądry (MIT) suggested that recent work on weighted paging (a special case of the $k$-server problem) seemed to match the narrative.
I returned to UW and taught a course on entropy optimality; Seb Bubeck (Microsoft Research) sat in on the lectures, and we began discussing the theory of mirror descent and its recent applications in online learning. One thing that became clear early on is that the classical exponential weights approach is too conservative to be competitive for $k$-server and related problems. While exponential weights is very effective in the bandit setting, there one generally competes against the optimal fixed strategy.
A solution to this problem (for the special case of weighted paging) lies in the paper of Bansal, Buchbinder, and Naor, where the authors consider an algorithm that can be interpreted in the following way: Run exponential weights, but never let the algorithm become too confident about its server placement. If the algorithm asserts “I am 99.9% sure there should be a server here,” we cap this confidence at 95% (more formally, at $1-1/2k$). One can consult these lecture notes where this is referred to as the “exploration shift.”
Since the work of Bartal (1996), it has been understood that solving $k$-server on hierarchically separated tree (HST) metrics is a fundamental first step in designing an algorithm for general metric spaces. Problematically, even with the above understanding for weighted paging, the HST case is far more daunting because one cannot write down the dynamics of the algorithm explicitly. This is where a general theory of mirror descent becomes crucial, though the correct notion of multiscale entropy (suitable for hedging simultaneously at many scales) requires a detailed understanding of the associated polytope.
Fortunately, Olek recruited an ambitious young graduate student named Michael Cohen, and they understood well the structure of the allocation polytope underlying previous work on HSTs. At the same time, Yin Tat Lee had joined us in Seattle (as a postdoc at MSR, and then as faculty at UW), and we continued to study the dark side of the exploration shift: When the confidence of the algorithm is artificially reduced, it becomes more willing to move servers, and one has to control the corresponding increase in movement cost. (The resulting analytic mess is enough to make “inverse Hessian” start to sound like foul language.)
With a little help from 0.1 friends
A rather ingenious observation of Michael is that the cost of the exploration shift can be controlled almost effortlessly if we just have a little extra help: Instead of $k$ servers, $k+0.1$ servers. (This requires passing to a fractional relaxation of the $k$-server problem, which we had already done implicitly five paragraphs and 10+ years ago.) Moreover, on HSTs one can show that $k+0.1$ fractional servers can always be simulated by $k$ fractional servers while increasing the movement costs by only a constant factor.
Seb, Michael, Yin Tat, Olek, and I were all long-term partipants in the Optimization program (Olek was an organizer) this past fall. Our work culminated in an $O((\log k)^2)$-competitive randomized algorithm for the $k$-server problem on HSTs: $k$-server via multiscale entropic regularization. In followup work, I show how this can be utilized to obtain a $\mathrm{poly}(\log k)$-competitive algorithm for any metric space.
Tragically, Michael passed away unexpectedly during the program. The memorial symposium held in his honor offers a glimpse of the brilliance and impact of his short time with us.
Additional references
- The book Competitive Analysis by Borodin and El-Yaniv.
- Algorithms and Uncertainty program (Fall 2016) at the Simons Institute.
- The course Competitive analysis via convex optimization (Spring 2018), taught at UW, jointly with Sebastien Bubeck.


Correspondence:
Regina C. Figueiredo Castro
Coordenação de Comunicação Científica em
Saúde
BIREME/OPAS/OMS
Rua Botucatu, 862
04023-901 São Paulo, SP, Brasil
E-mail<EMAIL_ADDRESS>Received: 4/17/2006
1
The Virtual Health Library (http://www.bvsalud.org)
was launched in 1998 by BIREME - Latin American and Caribbeant Center on Health
Sciences Information
2
Lemos AAB. Presente e futuro do periódico científico. Correio
Brasiliense, 1968. Available from http://www.briquetdelemos.com.br/briquet/briquet_lemos6.htm
[access in 2006 Mar 30]
3
National Institutes of Health. Department of Health and Human Services. Policy
on enhancing public access to archived publications resulting from NIH-funded
research. Estados Unidos, 2005. Available from http://grants.nih.gov/grants/guide/notice-files/NOT-OD-05-022.html
[access in 2006 Mar 15]
4
PubMed Central. Available from http://www.pubmedcentral.org
5
SciELO (http://www.scielo.org)
is an initiative of BIREME and the Fundação de Apoio à
Pesquisa do Estado de São Paulo (Fapesp), in Brazil, with collections
of about 300 Iberoamerican journals.
6
Salvador Declaration. Available from http://www.icml9.org/channel.php?lang=en&channel=91&content=439
7
Directory of Open Access Journals. Available from http://www.doaj.org
8
LILACS - Latin American and Caribbean Health Sciences, coordinated by BIREME.
Available from http://www.bvsalud.org
9
SciELO Public Health. Available from http://www.scielosp.org
10
Lemos AAB. Presente e futuro do periódico científico. Correio
Brasiliense, 1968. Available from http://www.briquetdelemos.com.br/briquet/briquet_lemos6.htm
[access in 2006 Mar 30]
11
Science Digital Edition: http://www.sciencemag.org/subscriptions/indiv_digitalscience_index.dtl


A Follow-up to My Pledge
###Github
I continue to use this but even more with a few projects just in the past few weeks. Can't say how much I love this product. It has so much to offer. Colaboration, project management, to-dos and of course git versioning.
###Sublime Text 2
I enjoy this editor greatly. It's the simple but I still am learning to get more use out of it's features. My next move is to start making code snippets as well as a good boilplate/framework.
###SCSS/SASS
I can't go forward on any project without implementing this. Such a better way of writting CSS. I did use SCSS for about 6 months with Compass. It was a nice addition but I don't think it's for me. Cody has turned me onto Bourbon. It's a great mixin library with less overhead then Compass.
New to the list is a few other techniques. Grunt, ruby and node.js. I'm really new with these, 4 weeks new, but from my short use I see huge benefits with them.
- Previous: Taking Chances with No Regrets
- Next: Excuse the mess


This is a short paragraph with the attribute `class="blue-text"`.
This is another short paragraph with the attribute `id="special-element"`.
This is another short paragraph with the attribute `class="blue-text"`. Classes can be applied to multiple elements.
This is a short paragraph in Section 2.
This is another short paragraph in Section 2.
This is a short paragraph in Section 2.1. Note that Section 2.1 is an H2 element and is logically nested underneath the nearest H1 ("Section 2").


Co-Prime Numbers Theory
‘Co’ refers to a ‘pair’. So, we can define a pair of integers,
let's say a and b, as coprime or primes to each other or
mutually prime or relatively prime if:
p>
* the only positive integer that divides both
of them to give a remainder zero is 1
* In other words, the HCF of the two numbers is
1
* Coprime numbers are denoted as gcd(a, b)=1 or
(a, b)=1 or as “a is prime to b”
How to find Coprime numbers?
Let's understand it with the help of an example:
Let's consider two numbers 6 and 15.
Now find out the factors of 6 and 15. We get the factors of 6 as 1, 2, 3, 6 and factors of 15 as 1,
3, 5, 15.On
comparing the factors of these two numbers 6 and 15, we see that both these numbers have factors 1
and 3 in common.
The HCF for this pair is 3. Therefore the pair is not coprime.
Properties of Coprime numbers
1) Numbers that are coprime may not necessarily
be prime numbers themselves. For eg: (10,21), the numbers are not prime numbers if taken
individually but they are coprime if considered as a pair. This concludes that composite numbers can
be coprime numbers too.
2) Prime numbers are coprime by default. For
eg: (2,3), (5,11), (19,23) and so on. Every prime number has only two factors i.e. 1 and the number
itself. Therefore, the only common factor of a pair of two prime numbers will be 1.
3) Unity is considered coprime with everything
else.
4) The concept of coprime is meaningful only
with natural numbers.
5) Two successive integers are always coprime.
For eg: (2,3), (11,12), (99,100) and so on; they have 1 as their HCF.
6) The sum of any two coprime numbers is always
coprime with the product of the same two coprime numbers. For eg: The sum of 2 and 3 is 5 and the
product of 2 and 3 is 6. Hence, 5 and 6 are coprime numbers.
7) If p and q are coprime numbers then p2 and
q2 are also coprime numbers. For example, the squares of 5 and 6 i.e. 25 and 36 are also coprime to
each other.


Tributary
Delta
Cypress
BigFish
Fly
Curiosity
Tributary
Bar
-
Line
-
Map by @poezn
-
Avatars
v next
Illusion
-
Coffee Beans
-
Wheel
v next
Blobular by @themaninblue
-
Arc
-
Blob
v next
Delta
Simple
-
Form by @bausofthenauf
-
Text
v next
Cypress
Phylotaxis by @syntagmatic
-
Pacman by @syntagmatic
v next
Lasers
-
Weathervane by @ptvan
-
Wrap You Up by @ptvan
-
Dune by @ptvan
-
Wobble by @ptvan
-
Napkins by @ptvan
v next
BigFish
Flocks
-
Force
-
Voronoi
-
Blob
v next
Fly
More Flocks
-
SPH
v next
Curiosity
Cube by @bausofthenauf
-
Cubes by @bausofthenauf
-
Gem by @bausofthenauf


--- layout: default title: W3C WoT – Working Group group: "navigation" ---
The W3C WoT Working Group (WG) is tasked to create standards-track specifications and test suites. To ensure royalty-free Web standards, participants must be W3C and WoT WG Members and acknowledge the W3C Patent Policy.
Co-Chairs: Michael McCool (Intel) and Sebastian Käbisch (Siemens AG)
Team contacts: Kazuyuki Ashimura and Dave Raggett
The Web of Things (WoT) Working Group (WG) conducts some of its work via the following task forces.
See each task force page for details about specific work.
| Name | Deliverable | Task Force Lead |
|---|---|---|
| WoT Architecture | WoT Architecture WoT Profile |
Michael Lagally (Oracle Corp.) |
| WoT Thing Description | WoT Thing Description WoT Binding Templates |
Sebastian Käbisch (Siemens AG) |
| WoT Discovery | WoT Discovery | Michael McCool (Intel) |
| WoT Security | WoT Security | Michael McCool (Intel) |
| WoT Scripting API | WoT Scripting | Daniel Peintner (Siemens AG) |
| Web of Things (WoT) Architecture | W3C Recommendation | 9 April 2020 |
|---|---|---|
| Web of Things (WoT) Architecture 1.1 | W3C Proposed Recommendation | 11 July 2023 |
| Web of Things (WoT) Thing Description | W3C Recommendation | 9 April 2020 |
| Web of Things (WoT) Thing Description 1.1 | W3C Proposed Recommendation | 11 July 2023 |
| Web of Things (WoT) Discovery | W3C Proposed Recommendation | 11 July 2023 |
| Web of Things (WoT) Profile | W3C Second Public Working Draft | 18 January 2023 |
| Web of Things (WoT) Scripting API | 24 November 2020 |
|---|---|
| Web of Things (WoT) Binding Templates | 30 January 2020 |
| Web of Things (WoT) Security and Privacy Guidelines | 6 November 2019 |
| Web of Things (WoT) Use Cases and Requirements | 7 March 2022 |