Perception, Planning, and Control
© Russ Tedrake, 2020-2023
Last modified .
How to cite these notes, use annotations, and give feedback.
Note: These are working notes used for a course being taught at MIT. They will be updated throughout the Fall 2023 semester.
| Previous Chapter | Table of contents | Next Chapter |
The stage is set. You have your robot. I have a little red foam brick. I'm going to put it on the table in front of your robot, and your goal is to move it to a desired position/orientation on the table. I want to defer the perception problem for one more chapter, and will let you assume that you have access to a perfect measurement of the current position/orientation of the brick. Even without perception, completing this task requires us to build up a basic toolkit for geometry and kinematics; it's a natural place to start.
First, we will establish some terminology and notation for kinematics. This is one area where careful notation can yield dividends, and sloppy notation will inevitably lead to confusion and bugs. The Drake developers have gone to great length to establish and document a consistent multibody notation, which we call "Monogram Notation". The documentation even includes some of the motivation/philosophy behind that notation. I'll use the monogram notation throughout this text.
If you'd like a more extensive background on kinematics than what I provide
here, my favorite reference is still
Please don't get overwhelmed by how much background material there is to know! I am personally of the opinion that a clear understanding of just a few basic ideas should make you very effective here. The details will come later, if you need them.
The following concepts are disarmingly subtle. I've seen incredibly smart people assume they knew them and then perpetually stumble over notation. I did it for years myself. Take a minute to read this carefully!
Perhaps the most fundamental concept in geometry is the concept of a point. Points occupy a position in space, and they can have names, e.g. point $A$, $C$, or more descriptive names like $B_{cm}$ for the center of mass of body $B$. We'll denote the position of the point by using a position vector $p^A$; that's $p$ for position, and not for point, because other geometric quantities can also have a position.
But let's be more careful. Position is actually a relative quantity. Really, we should only ever write the position of two points relative to each other. We'll use e.g. $^Ap^C$ to denote the position of $C$ measured from $A$. The left superscript looks mighty strange, but we'll see that it pays off once we start transforming points.
Every time we describe the (relative) position as a vector of numbers, we need to be explicit about the frame we are using, specifically the "expressed-in" frame. All of our frames are defined by orthogonal unit vectors that follow the "right-hand rule". We'll give a frame a name, too, like $F$. If I want to write the position of point $C$ measured from point $A$, expressed in frame $F$, I will write $^Ap^C_F$. If I ever want to get just a single component of that vector, e.g. the $x$ component, then I'll use $^Ap^C_{F_x}$. In some sense, the "expressed-in" frame is an implementation detail; it is only required once we want to represent the multibody quantity as a vector (e.g. in the computer).
That is seriously heavy notation. I don't love it myself, but it's the most durable I've got, and we'll have shorthand for when the context is clear.
There are a few very special frames. We use $W$ to denote the world frame. We think about the world frame in Drake using vehicle coordinates (positive $x$ to the front, positive $y$ to the left, and positive $z$ is up). The other particularly special frames are the body frames: every body in the multibody system has a unique frame attached to it. We'll typically use $B_i$ to denote the frame for body $i$.
Frames have a position, too -- it coincides with the frame origin. So it is perfectly valid to write $^Wp^A_W$ to denote the position of point $A$ measured from the origin of the world frame, expressed in the world frame. Here is where the shorthand comes in. If the position of a quantity is measured from a frame, and expressed in the same frame, then we can safely omit the subscript. $^Fp^A \equiv {^Fp^A_F}$. Furthermore, if the "measured from" field is omitted, then we assume that the point is measured from $W$, so $p^A \equiv {}^Wp^A_W$.
Frames also have an orientation. We'll use $R$ to denote a rotation, and follow the same notation, writing $^BR^A$ to denote the rotation of frame $A$ measured from frame $B$. Unlike vectors, pure rotations do not have an additional "expressed in" frame.
A frame $F$ can be specified completely by a position and rotation
measured from another frame. Taken together, we call the position and
rotation a
spatial pose, or just pose. A spatial transform,
or just transform, is the "verb form" of pose. In Drake we use RigidTransform
to represent a pose/transform, and denote it with the letter $X$. $^BX^A$
is the pose of frame $A$ measured from frame $B$. When we talk about the
pose of an object $O$, without mentioning a reference frame explicitly, we
mean $^WX^O$ where $O$ is the body frame of the object. We do not use the
"expressed in" frame subscript for pose; we always want the pose expressed
in the reference frame.
The Drake
documentation also discusses how to use this notation in code. In
short, $^Bp^A_C$ is written p_BA_C
, ${}^BR^A$ as
R_BA
, and ${}^BX^A$ as X_BA
. It works, I
promise.
Now that we have the notation, we can formulate our approach to the basic pick and place problem. Let us call our object, $O$, and our gripper, $G$. Our idealized perception sensor tells us $^WX^O$. Let's create a frame $O_d$ to describe the "desired" pose of the object, $^WX^{O_d}$. So pick and place manipulation is simply trying to make $X^O = X^{O_d}$.
Clearly, programming this strategy requires good tools for working with these transforms, and for relating the pose of the gripper to the joint angles of the robot.
Here is where we start to see the pay-off from our heavy notation, as we define the rules of converting positions, rotations, poses, etc. between different frames. Without the notation, this invariably involves me with my right hand in the air making the "right-hand rule", and my head twisting around in space. With the notation, it's a simple matter of lining up the symbols properly, and we're more likely to get the right answer!
In practice, transforms are implemented using homogenous coordinates, but for now I'm happy to leave that as an implementation detail.
Imagine that I have a depth camera mounted in a fixed pose in my workspace. Let's call the camera frame $C$ and denote its pose in the world with ${}^WX^C$.
A depth camera returns points in the camera frame. Therefore, we'll write this position of point $P_i$ with ${}^Cp^{P_i}$. If we want to convert the point into the world frame, we simply have $$p^{P_i} = X^C {}^Cp^{P_i}.$$
This is a work-horse operation for us. We often aim to merge points from multiple cameras (typically in the world frame), and always need to somehow relate the frames of the camera with the frames of the robot. The inverse transform, ${}^CX^W$, which projects world coordinates into the camera frame, is often called the camera "extrinsics".
In the spatial algebra above, I've written the rules for rotations using an abstract notion of rotation. But in order to implement this algebra in code, we need to decide how we are going to represent those representations with a small number of real values. There are many possible representations of 3D rotations, they are each good for different operations, and unfortunately, there is no one representation to rule them all. (This is one of the many reasons why everything is better in 2D!) Common representations include
A 3$\times$3 rotation matrix is an orthonormal matrix with columns formed by the $x-$, $y-$, and $z-$axes. Specifically, the first column of the transform ${}^GR^F$ has the $x-$axis of frame $F$ expressed in $G$ in the first column, etc.
Euler angles
specify a 3D rotation by a series of rotations around the $x$, $y$, and
$z$ axes. The order of these rotations matters; and many combinations can be used to describe any 3D rotation. This is why we use
RollPitchYaw
in the code (preferring it over the more
general term "Euler angle") and document
it carefully. Roll is a rotation around the $x$-axis, pitch is a
rotation around the $y$-axis, and yaw is a rotation around the $z$-axis;
this is also known as "extrinsic X-Y-Z" Euler angles.
Axis angles describe a 3D rotation by a scalar rotation around an
arbitrary vector axis using three numbers: the direction of the vector is
the axis, and the magnitude of the vector is the angle. You can think of
unit quaternions as a form of axis angles that have been carefully
normalized to be unit length and have magical properties. My favorite
careful description of quaternions is probably chapter 1 of
Why all of the representations? Shouldn't "roll-pitch-yaw" be enough?
Unfortunately, no. The limitation is perhaps most easily seen by looking
at the coordinate changes from roll-pitch-yaw to/from a rotation matrix.
Any roll-pitch-yaw can be converted to a rotation matrix, but the inverse
map has a singularity. In particular, when the pitch angle is
$\frac{\pi}{2}$, then roll and yaw are now indistinguishable. This is
described very nicely, along with its physical manifestation in "gimbal
lock" in this
video. Similarly, the direction of the vector in the axis-angle
representation in not uniquely defined when the rotation angle is zero.
These singularities become problematic when we start taking derivatives
of rotations, for instance when we write the equations of motion. It is
now well understood
The spatial algebra gets us pretty close to what we need for our pick and place algorithm. But remember that the interface we have with the robot reports measured joint positions, and expects commands in the form of joint positions. So our remaining task is to convert between joint angles and cartesian frames. We'll do this in steps, the first step is to go from joint positions to cartesian frames: this is known as forward kinematics.
Throughout this text, we will refer to the joint positions of the robot (also known as "configuration" of the robot) using a vector $q$. If the configuration of the scene includes objects in the environment as well as the robot, we would use $q$ for the entire configuration vector, and use e.g. $q_{robot}$ for the subset of the vector corresponding to the robot's joint positions. Therefore, the goal of forward kinematics is to produce a map: \begin{equation}X^G = f_{kin}^G(q).\end{equation} Moreover, we'd like to have forward kinematics available for any frame we have defined in the scene. Our spatial notation and spatial algebra makes this computation relatively straight-forward.
In order to facilitate kinematics and related multibody computations,
the MultibodyPlant
organizes all of the bodies in the world
into a tree topology. Every body (except the world body) has a parent,
which it is connected to via either a Joint
or a "floating
base".
Drake provides some visualization support for inspecting the kinematic tree data structure. The kinematic tree for an iiwa is more of a vine than a tree (it's a serial manipulator), but the tree for the dexterous hands are more interesting. I've added our brick to the example, too, so that you can see that a "free" body is just another branch off the world root node.
Every Joint
and "floating base" has some number of
position variables associated with it -- a subset of the configuration
vector $q$ -- and knows how to compute the configuration dependent
transform across the joint from the child joint frame $J_C$ to the parent
joint frame $J_P$: ${}^{J_P}X^{J_C}(q)$. Additionally, the kinematic tree
defines the (fixed) transforms from the joint frame to the child body
frame, ${}^CX^{J_C}$, and from the joint frame to the parent frame,
${}^PX^{J_P}$. Altogether, we can compute the configuration transform
between any one body and its parent, $${}^PX^C(q) = {}^PX^{J_P}
{}^{J_P}X^{J_C}(q) {}^{J_C}X^C.$$
You might be tempted to think that every time you add a joint to the
MultibodyPlant
, you are adding a degree of freedom. But it
actually works the other way around. Every time you add a body
to the plant, you are adding many degrees of freedom. But you can then
add joints to remove those degrees of freedom; joints are
constraints. "Welding" the robot's base to the world frame removes all of
the floating degrees of freedom of the base. Adding a rotational joint
between a child body and a parent body removes all but one degree of
freedom, etc.
In order to compute the pose of the gripper in the world, $X^G$, we simply query the parent of the gripper frame in the kinematic tree, and recursively compose the transforms until we get to the world frame.
Let's evaluate the pose of the gripper in the world frame: $X^G$.
We know that it will be a function of configuration of the robot, which
is just a part of the total state of the MultibodyPlant
(and so is stored in the Context
). The following example
shows you how it works.
The key lines are
Behind the scenes, the
gripper = plant.GetBodyByName("body", wsg)
pose = plant.EvalBodyPoseInWorld(context, gripper)
MultibodyPlant
is doing all of the
spatial algebra we described above to return the pose (and also some
clever caching because you can reuse much of the computation when you
want to evaluate the pose of another frame on the same robot).
Consider the special case of having a MultibodyPlant
with exactly one body added, and no joints. The kinematic tree is
simply the world frame, the body frame, and they are connected by the
"floating base". What does the forward kinematics function: $$X^B =
f_{kin}^B(q),$$ look like in that case? If $q$ is already representing
the floating-base configuration, is $f^B_{kin}$ just the identity
function?
This gets into the subtle points of how we represent transforms, and
how we represent 3D rotations in particular. Although we use rotation matrices in our RigidTransform
class, in order to make the spatial algebra efficient, we actually use unit quaternions in the Context
in order to have a more compact vector representation.
As a result, for this example, the software implementation of the function $f_{kin}^B$ is precisely the function that converts the position $\times$ unit quaternion representation into the position $\times$ rotation matrix representation.
The forward kinematics machinery gives us the ability to compute the pose of the gripper and the pose of the object, both in the world frame. But if our goal is to move the gripper to the object, then we should understand how changes in the joint angles relate to changes in the gripper pose. This is traditionally referred to as "differential kinematics".
At first blush, this is straightforward. The change in pose is related to a change in joint positions by the (partial) derivative of the forward kinematics: \begin{equation}dX^B = \pd{f_{kin}^B(q)}{q} dq = J^B(q)dq. \label{eq:jacobian}\end{equation} Partial derivatives of a function are referred to as "Jacobians" in many fields; in robotics it's rare to refer to derivatives of the kinematics as anything else.
Differentiating $${}^Ap^C = {}^AX^B {}^Bp^C = {}^Ap^B + {}^AR^B {}^Bp^C,$$ yields \begin{align} {}^A\text{v}^C =& {}^A\text{v}^B + {}^A\dot{R}^B {}^Bp^C + {}^AR^B {}^B\text{v}^C \nonumber \\ =& {}^A\text{v}^B_A + {}^A\dot{R}^B {}^BR^A {}^Bp^C_A + {}^B\text{v}^C_A.\end{align} Allow me to write $\dot{R}R^{-1}$ for ${}^A\dot{R}^B {}^BR^A$ (dropping the frames for a moment). It turns out that $\dot{R}R^{-1}$, is always a skew-symmetric matrix. To see this, differentiate $RR^T = I$ to get $$\dot{R}R^T + R\dot{R}^T = 0 \Rightarrow \dot{R}R^T = - R\dot{R}^T \Rightarrow \dot{R} R^T = - (\dot{R} R^T)^T,$$ which is the definition of a skew-symmetric matrix. Any 3$\times$3 skew-symmetric matrix can be parameterized by three numbers (we'll use the three-element vector $\omega$), and can be written as a cross product, so $\dot{R}R^Tp = \omega \times p.$
Multiply the right and left sides by ${}^FR^A$ to change the expressed-in frame, and we have our result.
Screw theory (as used in, e.g.
There is one more velocity to be aware of: I'll use $v$ to denote the generalized velocity vector of the plant. While a spatial velocity $^AV^B$ is six components, a translational or angular velocity, $^B\text{v}^C$ or $^B\omega^C$, is three components, the generalized velocity vector is whatever size it needs to be to encode the time derivatives of the configuration variables, $q$. For the iiwa welded to the world frame, that means it has seven components. I've tried to be careful to typeset each of these v's differently throughout the notes. Almost always the distinction is also clear from the context.
The unit quaternion representation is four components, but these must form a "unit vector" of length 1. Rotation matrices are 9 components, but they must form an orthonormal matrix with $\det(R)=1$. It's pretty great that for changes in rotation, we can use an unconstrained three component vector, what we've called the angular velocity vector, $\omega$. And you really should use it; getting rid of that constraint makes both the math and the numerics better.
But there is one minor nuisance that this causes. We tend to want to
think of the generalized velocity as the time derivative of the
generalized positions. This works when we have only our iiwa in the
model, and it is welded to the world frame. But we cannot assume this in
general; not when floating-base rotations are concerned. As evidence,
here is a simple example that loads exactly one rigid body into the
MultibodyPlant
, and then prints its
Context
.
The output looks like this:
Context
--------
Time: 0
States:
13 continuous states
1 0 0 0 0 0 0 0 0 0 0 0 0
plant.num_positions() = 7
plant.num_velocities() = 6
You can see that this system has 13 total state variables. 7 of them are positions, $q$; we use unit quaternions in the position vector. But we have just 6 velocities, $v$; we use angular velocities in the velocity vector. Clearly, if the length of the vectors don't even match, we do not have $\dot{q} = v$.
It's not really any harder; Drake provides the
MultibodyPlant
methods MapQDotToVelocity
and
MapVelocityToQDot
to go back and forth between them. But you
have to remember to use them!
Due to the multiple possible representations of 3D rotation, and the
potential difference between $\dot{q}$ and $v$, there are actually
many different kinematic Jacobians possible. You may hear the terms
"analytic Jacobian", which refers to the explicit partial derivative of the
forward kinematics (as written in \eqref{eq:jacobian}), and "geometric
Jacobian" which replaces 3D rotations on the left-hand side with spatial
velocities. In Drake's MultibodyPlant
, we currently offer the geometric Jacobian versions via
CalcJacobianAngularVelocity
,CalcJacobianTranslationalVelocity
, andCalcJacobianSpatialVelocity
,Let's repeat the setup from above, but we'll print out the Jacobian of the gripper frame, measured from the world frame, expressed in the world frame.
There is important structure in Eq \eqref{eq:jacobian}. Make sure you didn't miss it. The relationship between joint velocities and end-effector velocities is (configuration-dependent) linear: \begin{equation}V^G = J^G(q)v.\end{equation} Maybe this gives us what we need to produce changes in gripper frame $G$? If I have a desired gripper frame velocity $V^{G_d}$, then how about commanding a joint velocity $v = \left[J^G(q)\right]^{-1} V^{G_d}$?
Any time you write a matrix inverse, it's important to check that the matrix is actually invertible. As a first sanity check: what are the dimensions of $J^G(q)$? We know the spatial velocity has six components. Our gripper frame is welded directly on the last link of the iiwa, and the iiwa has seven positions, so we have $J^G(q_{iiwa}) \in \Re^{6 \times 7}.$ The matrix is not square, so does not have an inverse. But having more degrees of freedom than the desired spatial velocity requires (more columns than rows) is actually the good case, in the sense that we might have many solutions for $v$ that can achieve a desired spatial velocity. To choose one of them (the minimum-norm solution), we can consider using the Moore-Penrose pseudo-inverse, $J^+$, instead: \begin{equation}v = [J^G(q)]^+V^{G_d}.\end{equation}
The pseudo-inverse is a beautiful mathematical concept. When the $J$ is square and full-rank, the pseudo-inverse returns the true inverse of the system. When there are many solutions (here many joint velocities that accomplish the same end-effector spatial velocity), then it returns the minimum-norm solution (the joint velocities that produce the desired spatial velocity which are closest to zero in the least-squares sense). When there is no exact solution, it returns the joint velocities that produce an spatial velocity which is as close to the desired end-effector velocity as possible, again in the least-squares sense. So good!
Let's write a simple controller using the pseudo-inverse of the
Jacobian. First, we'll write a new LeafSystem
that defines
one input port (for the iiwa measured position), and one output port
(for the iiwa joint velocity command). Inside that system, we'll ask
MultibodyPlant for the gripper Jacobian, and compute the joint
velocities that will implement a desired gripper spatial velocity.
To keep things simple for this first example, we'll just command a constant gripper spatial velocity, and only run the simulation for a few seconds.
Note that we do have to add one additional system into the diagram. The output of our controller is a desired joint velocity, but the input that the iiwa controller is expecting is a desired joint position. So we will insert an integrator in between.
I don't expect you to understand every line in this example, but it's worth finding the important lines and making sure you can change them and see what happens!
Congratulations! Things are really moving now.
There is a simple check to understand when the pseudo-inverse can give an exact solution for any spatial velocity (achieving exactly the desired spatial velocity): the Jacobian must be full row-rank. In this case, we need $\rank(J) = 6$. But assigning an integer rank to a matrix doesn't tell the entire story; for a real robot with (noisy) floating-point joint positions, as the matrix gets close to losing rank, the (pseudo-)inverse starts to "blow-up". A better metric, then, is to watch the smallest singular value; as this approaches zero, the norm of the pseudo-inverse will approach infinity.
You might have noticed that I printed out the smallest singular value of $J^G$ in one of the previous examples. Take it for another spin. See if you can find configurations where the smallest singular value gets close to zero.
Here's a hint: try some configurations where the arm is very straight, (e.g. driving joint 2 and 4 close to zero).
Another good way to find the singularities are to use your pseudo-inverse controller to send gripper spatial velocity commands that drive the gripper to the limits of the robot's workspace. Try it and see! In fact, this is the common case, and one that we will work hard to avoid.
Configurations $q$ for which $\rank(J(q_{iiwa})) < 6$ for a frame of interest (like our gripper frame $G$) are called kinematic singularities. Try to avoid going near them if you can! The iiwa has many virtues, but admittedly its kinematic workspace is not one of them. Trust me, if you try to get a big Kuka to reach into a little kitchen sink all day, every day, then you will spend a non-trivial amount of time thinking about avoiding singularities.
In practice, things can get a lot better if we stop bolting our robot base to a fixed location in the world. Mobile bases add complexity, but they are wonderful for improving the kinematic workspace of a robot.
A natural question when discussing singularities is whether they are somehow real, or whether they are somehow an artifact of the analysis. Perhaps it is useful to look at an extremely simple case.
Imagine a two-link arm, where each link has length one. Then the kinematics reduce to $$p^G = \begin{bmatrix} c_0 + c_{0+1} \\ s_0 + s_{0 + 1} \end{bmatrix},$$ where I've used the (very common) shorthard $s_0$ for $\sin(q_0)$ and $s_{0+1}$ for $\sin(q_0+q_1)$, etc. The translational Jacobian is $$J^G(q) = \begin{bmatrix} -s_0 - s_{0+1} & -s_{0 + 1} \\ c_0 + c_{0 + 1} & c_{0 + 1} \end{bmatrix},$$ and as expected, it loses rank when the arm is at full extension (e.g. when $q_0 = q_1 = 0$ which implies the first row is zero).
Let's move the robot along the $x$-axis, by taking $q_0(t) = 1-t,$ and $q_1(t) = -2 + 2t$. This clearly visits the singularity $q_0 = q_1 = 0$ at time 1, and then leaves again without trouble. In fact, it does all this with a constant joint velocity ($\dot{q}_0=-1, \dot{q}_1=2$)! The resulting trajectory is $$p^G(t) = \begin{bmatrix} 2\cos(1-t) \\ 0 \end{bmatrix}.$$
There are a few things to understand. At the singularity, there is nothing that the robot can do to move its gripper farther in positive $x$ -- that singularity is real. But it is also true that there is no way for the robot to move instantaneously back in the direction of $-x.$ The Jacobian analysis is not an approximation, it is a perfect description of the relationship between joint velocities and gripper velocities. However, just because you cannot achieve an instantaneous velocity in the backwards direction, it does not mean you cannot get there! At $t=1$, even though the joint velocities are constant, and the translational Jacobian is singular, the robot is accelerating in $-x$, $\ddot{p}^G_{W_x}(t) = -2\cos(1-t).$
For the cases when the Jacobian does not have a unique inverse, there
is an interesting subtlety to be aware of regarding integrability.
Let's start our robot in at time zero in a joint configuration, $q(0)$
with a corresponding in an end-effector pose $X^G(0)$. Now let us execute
an end-effector trajectory using the pseudo-inverse controller that moves
along a closed-path in the task space, coming back to the original
end-effector pose at time one: $X^G(1) = X^G(0)$. Unfortunately, there is
no guarantee that $q(1) = q(0)$; this is not simply due to numerical
errors in our numerical implementation, it is well known that the
pseudo-inverse does not in general produce an integrable function.
I'm going to put my red foam brick on the table. Its geometry is defined as a 7.5cm x 5cm x 5cm box. For reference, the distance between the fingers on our gripper in the default "open" position is 10.7cm. The "palm" of the gripper is 3.625cm from the body origin, and the fingers are 8.2cm long.
To make things easy to start, I'll promise to set the object down on the table with the object frame's $z$-axis pointing up (aligned with the world $z$ axis), and you can assume it is resting on the table safely within the workspace of the robot. But I reserve the right to give the object arbitrary initial yaw. Don't worry, you might have noticed that the seventh joint of the iiwa will let you rotate your gripper around quite nicely (well beyond what my human wrist can do).
Observe that visually the box has rotational symmetry -- I could always rotate the box 90 degrees around its $x$-axis and you wouldn't be able to tell the difference. We'll think about the consequences of that more in the next chapter when we start using perception. But for now, we are ok using the omniscient "cheat port" from the simulator which gives us the unambiguous pose of the brick.
Take a careful look at the gripper frame in the figure above, using the colors to understand the axes. Here is my thinking: Given the size of the hand and the object, I want the desired position (in meters) of the object in the gripper frame, $${}^{G_{grasp}}p^O = \begin{bmatrix} 0 \\ 0.11 \\ 0 \end{bmatrix}, \qquad {}^{G_{pregrasp}}p^O = \begin{bmatrix} 0 \\ 0.2 \\ 0 \end{bmatrix}.$$ Recall that the logic behind a pregrasp pose is to first move to safely above the object, if our only gripper motion that is very close to the object is a straight translation from the pregrasp pose to the grasp pose and back, then it allows us to mostly avoid having to think about collisions (for now). I want the orientation of my gripper to be set so that the positive $z$ axis of the object aligns with the negative $y$ axis of the gripper frame, and the positive $x$ axis of the object aligns with the positive $z$ axis of the gripper. We can accomplish that with $${}^{G_{grasp}}R^O = \text{MakeXRotation}\left(\frac{\pi}{2}\right) \text{MakeZRotation} \left(\frac{\pi}{2}\right).$$ I admit I had my right hand in the air for that one! Our pregrasp pose will have the same orientation as our grasp pose.
Here is a simple example of loading a floating Schunk gripper and a brick, computing the grasp / pregrasp pose (drawing out each transformation clearly), and rendering the hand relative to the object.
I hope you can see the value of having good notation at work here. My right hand was in the air when I was deciding what a suitable relative pose for the object in the hand should be (when writing the notes). But once that was decided, I went to type it in and everything just worked.
We're getting close. We know how to produce desired gripper poses, and we know how to change the gripper pose instantaneously using spatial velocity commands. Now we need to specify how we want the gripper poses to change over time, so that we can convert our gripper poses into spatial velocity commands.
Let's define all of the "keyframe" poses that we'd like the gripper to travel through, and time that it should visit each one. The following example does precisely that.
How did I choose the times? I started everything at time, $t=0$, and listed the rest of our times as absolute (time from zero). That's when the robot wakes up and sees the brick. How long should we take to transition from the starting pose to the pregrasp pose? A really good answer might depend on the exact joint speed limits of the robot, but we're not trying to move fast yet. Instead I chose a conservative time that is proportional to the total Euclidean distance that the hand will travel, say $k=10~s/m$ (aka $10~cm/s$): $$t_{pregrasp} = k \left\|{}^{G_0}p^{G_{pregrasp}}\right\|_2.$$ I just chose a fixed duration of 2 seconds for the transitions from pregrasp to grasp and back, and also left 2 seconds with the gripper stationary for the segments where the fingers needs to open/close.
There are a number of ways one might represent a trajectory computationally. We have a pretty good collection of trajectory classes available in Drake. Many of them are implemented as splines -- piecewise polynomial functions of time. Interpolating between orientations requires some care, but for positions we can do a simple linear interpolation between each of our keyframes. That would be called a "first-order hold", and it's implemented in Drake's PiecewisePolynomial class. For rotations, we'll use something called "spherical linear interpolation" or slerp, which is implemented in Drake's PiecewiseQuaternionSlerp, and which you can explore in this exercise. The PiecewisePose class makes it convenient to construct and work with the position and orientation trajectories together.
There are a number of ways to visualize the trajectory when it's connected to 3D. I've plotted the position trajectory as a function of time below.
With 3D data, you can plot it in 3D. But my favorite approach is as an animation in our 3D renderer! Make sure you try the "Open controls>Animation" interface. You can pause it and then scrub through the trajectory using the time slider.
For a super interesting discussion on how we might visualize the 4D quaternions as creatures trapped in 3D, you might enjoy this series of "explorable" videos.
One final detail -- we also need a trajectory of gripper commands (to open and close the gripper). We'll use a first-order hold for that, as well.
We can slightly generalize our PseudoInverseController to have additional input ports for the desired gripper spatial velocity, ${}^WV^G$ (in our first version, this was just hard-coded in the controller).
The trajectory we have constructed is a pose trajectory, but our
controller needs spatial velocity commands. Fortunately, the trajectory
classes we have used support differentiating the trajectories. In fact,
the PiecewiseQuaternionSlerp
is clever enough to return the
derivative of the 4-component quaternion trajectory as a 3-component
angular velocity trajectory, and taking the derivative of a
PiecewisePose
trajectory returns a spatial velocity
trajectory. The rest is just a matter of wiring up the system diagram.
The next few cells of the notebook should get you a pretty satisfying result. Click here to watch it without doing the work.
It's worth scrutinizing the result. For instance, if you examine the context at the final time, how close did it come to the desired final gripper position? Are you happy with the joint positions? If you ran that same trajectory in reverse, then back and forth (as an industrial robot might), would you expect errors to accumulate?
Our solution above works in many cases. We could potentially move on. But with just a little more work, we can get a much more robust solution... one that we will be happy with for many chapters to come.
So what's wrong with the pseudo-inverse controller? You won't be surprised when I say that it does not perform well around singularities. When the minimum singular value of the Jacobian gets small, that means that some values in the inverse get very large. If you ask our controller to track a seemingly reasonable end-effector spatial velocity, then you might have extremely large velocity commands that result.
There are other important limitations, though, which are perhaps more subtle. The real robot has constraints, very real constraints on the joint angles, velocities, accelerations, and torques. If you, for instance, send a velocity command to the iiwa controller that cannot be followed, that velocity will be clipped. In the mode we are running the iiwa (joint-impedance mode), the iiwa doesn't know anything about your end-effector goals. So it will very likely simply saturate your velocity commands independently joint by joint. The result, I'm afraid, will not be as convenient as a slower end-effector trajectory. Your end-effector could run wildly off course.
Since we know the limits of the iiwa, a better approach is to take these constraints into account at the level of our controller. It's relatively straight-forward to take position, velocity, and acceleration constraints into account; torques would require a full dynamics model so we won't worry about them yet here.
I introduced the pseudo-inverse as having almost magical properties: it returns an exact solution when one is available, or the best possible solution (in the least-squares norm) when one is not. These properties can all be understood by realizing that the pseudo-inverse is just the optimal solution to a least-squares optimization problem: \begin{equation} \min_v \left|J^G(q)v - V^{G_d}\right|^2_2. \end{equation} When I write an optimization of this form, I will refer to $v$ as the decision variable(s), and I will use $v^*$ to denote the optimal solution (the value of the decision variables that minimizes the cost). Here we have $$v^* = \left[ J^G(q) \right]^+V^{G_d}.$$
Optimization is an incredibly rich topic, and we will put many tools
from optimization theory to use over the course of this text. For a
beautiful rigorous but accessible treatment of convex optimization, I
highly recommend
Once we understand our existing solution through the lens of optimization, we have a natural route to generalizing our approach to explicitly reason about the constraints. The velocity constraints are the most straight-forward to add. \begin{align} \min_v && \left|J^G(q)v - V^{G_d}\right|^2_2, \\ \subjto && v_{min} \le v \le v_{max}. \nonumber \end{align} You can read this as "find me the joint velocities that achieve my desired gripper spatial velocity as closely as possible, but satisfy my joint velocity constraints." The solution to this can be much better than what you would get from solving the unconstrained optimization and then simply trimming any velocities to respect the constraints after the fact.
This is, admittedly, a harder problem to solve in general. The solution cannot be described using only the pseudo-inverse of the Jacobian. Rather, we are going to solve this (small) optimization problem directly in our controller every time it is evaluated. This problem has a convex quadratic objective and linear constraints, so it falls into the class of convex Quadratic Programming (QP). This is a particularly nice class of optimization problems where we have very strong numerical tools.
To help think about the differential inverse kinematics problem as an optimization, I've put together a visualization of the optimization landscape of the quadratic program. In the notebook below, you will see the constraints visualized as in red, and the objective function visualized as a function in green.
We can easily add more constraints to our QP, without significantly increasing the complexity, as long as they are linear in the decision variables. So how should we add constraints on the joint position and acceleration?
The natural approach is to make a first-order approximation of these constraints. To do that, the controller needs some characteristic time step / timescale to relate its velocity decisions to positions and accelerations. We'll denote that time step as $h$.
The controller already accepts the current measured joint positions $q$ as an input; let us now also take the current measured joint velocities $v$ as a second input. And we'll use $v_n$ for our decision variable -- the next velocity to command. Using a simple Euler approximation of position and first-order derivative for acceleration gives us the following optimization problem: \begin{align} \min_{v_n} \quad & \left|J^G(q)v_n - V^{G_d}\right|^2_2, \\ \subjto \quad & v_{min} \le v_n \le v_{max}, \nonumber \\ & q_{min} \le q + h v_n \le q_{max}, \nonumber \\ & \dot{v}_{min} \le \frac{v_n - v}{h} \le \dot{v}_{max}. \nonumber \end{align}
Our Jacobian is $6 \times 7$, so we actually have more degrees of freedom than end-effector goals. This is not only an opportunity, but a responsibility. When the rank of $J^G$ is less than the number of columns / number of degrees of freedom, then we have specified an optimization problem that has an infinite number of solutions; and we've left it up to the solver to choose one. Typically a convex optimization solver does choose something reasonable, like taking the "analytic center" of the constraints, or a minimum-norm solution for an unconstrained problem. But why leave this to chance? It's much better for us to completely specify the problem so that there is a unique global optima.
In the rich history of Jacobian-based control for robotics, there is a very elegant idea of implementing a "secondary" control, guaranteed (in some cases) not to interfere with our primary end-effector spatial velocity controller, by projecting it into the nullspace of $J^G$. So in order to fully specify the problem, we will provide a secondary controller that attempts to control all of the joints. We'll do that here with a simple joint-space controller $v = K(q_0 - q)$; this is a proportional controller that drives the robot to its nominal configuration.
Denote $P(q)$ as an orthonormal basis for the kernel of a Jacobian $J$. Traditionally in robotics we implemented this using the pseudo-inverse: $P = (I - J^+J)$, but many linear algebra packages now provide methods to obtain one more directly. Adding $Pv \approx Pk(q_0 - q)$ as a secondary objective can be accomplished with \begin{align}\min_{v_n} \quad & \left|J^G(q)v_n - V^{G_d}\right|^2_2 + \epsilon \left|P(q)\left(v_n - K(q_0 - q)\right)\right|^2_2, \\ \subjto \quad & \text{constraints}.\nonumber\end{align} Note the scalar $\epsilon$ that we've placed in front of the secondary objective. There is something important to understand here. If we do not have any constraints, then we can remove $\epsilon$ completely -- the secondary task will in no way interfere with the primary task of tracking the spatial velocity. However, if there are constraints, then these constraints can cause the two objectives to clash (Exercise). So we pick $\epsilon \ll 1$ to give the primary objective relatively more weight. But don't make it too small, because that might make the numerics bad for your solver. I'd say $\epsilon ~= 0.01$ is just about right.
There are more sophisticated methods if one wishes to establish a
strict task prioritization in the presence of constraints (e.g.
Once we have embraced the idea of solving a small optimization problem in our control loop, many other formulations are possible, too. You will find many in the literature. Minimizing the least-squares distance between the commanded spatial velocity and the resulting velocity might not actually be the best solution. The formulation we have been using heavily in Drake adds an additional constraint that our solution must move in the same direction as the commanded spatial velocity. If we are up against constraints, then we may slow down, but we will not deviate (instantaneously) from the commanded path. It would be a pity to spend a long time carefully planning collision-free paths for your end-effector, only to have your controller treat the path as merely a suggestion. Note, however, that your plan playback system still needs to be smart enough to realize that the slow-down occurred (open-loop velocity commands are not enough).
\begin{align} \max_{v_n, \alpha} \quad & \alpha, \\ \subjto \quad & J^G(q)v_n = \alpha V^{G_d}, \nonumber \\ & 0 \le \alpha \le 1, \nonumber \\ & \text{additional constraints}. \nonumber \end{align} You should immediately ask yourself: is it reasonable to scale a spatial velocity by a scalar? That's another great exercise.
What happens in this formulation when the Jacobian drops row rank? Observe that $v_n = 0, \alpha = 0$ is always a feasible solution for this problem. So if it's not possible to move in the commanded direction, then the robot will just stop.
We will use this implementation of differential inverse kinematics whenever we need to command the end-effector in the next few chapters.
TODO(russt): Fill this in.
For positions, we can linearly interpolate between points, i.e. a "first-order hold". When dealing with rotations, we cannot simply linearly interpolate and must instead use spherical linear interpolation (slerp). The goal of this problem is to dig into the details of slerp.
To do so we will consider the simpler case where our rotations are in $\Re^{2}$ and can be represented with complex numbers. Here are the rules of the game: a 2D vector (x,y) will be represented as a complex number $z = x + yi$. To rotate this vector by $\theta$, we will multiply by $e^{i\theta} = \cos(\theta) + i\sin(\theta).$
Take a minute to convince yourself that this recipe (going from a 2D vector to a complex number, multiply by $e^{i\theta}$, and converting back to a 2D vector) is mathematically equivalent to multiplying the original number by the 2D rotation matrix: $$R(\theta) = \begin{bmatrix} \cos\theta & -\sin\theta \\ \sin\theta & \cos\theta \end{bmatrix}.$$
A frame $F$ has an orientation. We can represent that orientation using the rotation from the world frame, e.g. $^WR^F$. We've just verified that you can represent that rotation using a complex number, $e^{i\theta}$. Now assume we want to interpolate between two orientations, represented by frames $F$ and $G$. How should we smoothly interpolate between the two frames, e.g. using $t\in [0,1]$? You'll explore this in parts (b) and (c).
Quaternions simply are a generalization of this idea to 3D. In 2D, it might seem inefficient to use two numbers and a constraint that $a^2 + b^2 = 1$ to represent a single rotation (why not just $\theta$!?), but we've seen that it works. In 3D we can use 4 numbers $x,y,z,w$ plus the constraint that $x^2+y^2+z^2+w^2 = 1$ to represent a 3D rotation. In 2D, using just $\theta$ can work fine, but in 3D using only three numbers leads to problems like the famous gimbal lock. The 4 numbers forming a unit quaternion provides a non-degenerate mapping of all 3D rotations.
Just like we saw in 2D, one cannot simply linearly interpolate the 4 numbers of the quaternion to interpolate orientations. Instead, we linearly interpolate the angle between two orientations, using the quaternion slerp. The details involve some quaternion notation, but the concept is the same as in 2D.
TODO(russt): Fill this in. Until then, here's a little code that might convince you it's reasonable.
For this exercise you will derive the translational forward kinematics ${^A}p{^C}=f(q)$ and the translational Jacobian $J(q)$ of a planar two-link manipulator. You will work exclusively in . You will be asked to complete the following steps:
Exercise 3.5 asked you to derived the translational Jacobian for the planar two-link manipulator. In this problem we will explore the translational Jacobian in more detail, both in the context of a planar two-link manipulator and in the context of a planar three-link manipulator. For the planar three-link manipulator, the joint angles are $(q_{0}, q_{1}, q_{2})$ and the planar end-effector position is described by $(x, y)$.
For this exercise you will apply your knowledge on spatial algebra to write poses of frames in different reference frames, and design a grasp pose yourself. You will work exclusively in . You will be asked to complete the following steps:
For this exercise you will design interesting trajectories for the robot to follow, and observe the robot virtually painting in the air! You will work exclusively in . You will be asked to complete the following steps:
For this exercise you will practice the syntax of solving Quadratic Programs (QPs) via Drake's MathematicalProgram interface. You will work exclusively in .
For this exercise you will implement a virtual wall for a robot manipulator, using an optimization-based approach to differential inverse kinematics. You will work exclusively in . You will be asked to complete the following steps:
In the section on joint centering, I claimed that an secondary objective might compete with a primary objective if they are linked through constraints. To see this, consider the following optimization problem \begin{align*}\min_{x,y} \quad (x-5)^2 + (y+3)^2.\end{align*} Clearly, the optimal solution is given by $x^*=5, y^*=-3$. Moreover, the objective are separable. The addition of the second objective, $(y+3)^2$, did not in any way impact the solution of the first.
Now consider the constrained optimization \begin{align*}\min_{x,y} \quad& (x-5)^2 + (y+3)^2 \\ \subjto \quad& x - y \le 6. \end{align*} If the second objective was removed, then we would still have $x^*=5$. What is the result of the optimization as written (it's only a few lines of code, if you want to do it that way)? I think you'll find that these "orthogonal" objectives actually compete!
What happens if you change the problem to \begin{align*}\min_{x,y} \quad& (x-5)^2 + \frac{1}{100}(y+3)^2 \\ \subjto \quad& x - y \le 6? \end{align*} I think you'll find that solution is quite close to $x^*=5$, but also that $y^*$ is quite different than that $y^*=0$ one would obtain if the "secondary" objective was omitted completely.
Note that if the constraint was not active at the optimal solution (e.g. $x=5, y=-3$ satisfied the constraints), then the objectives do not compete.
This seems like an overly simple example. But I think you'll find that it is actually quite similar to what is happening in the nullspace objective formulation above.
A manipulator with one joint is shown above. The joint is rotating over time, with its angle as a function of time, $\theta(t)$. When $t=0, \theta(t)=0$ and the link(arm) is aligned with y-axis of frame A and that of frame B. For this exercise, we will explore the spatial velocity of the end-effector.
| Previous Chapter | Table of contents | Next Chapter |


| Attacker | |
| Base Damage multiplier | x |
| Damage dealt | x |
| KB dealt | x |
| Target | |
| Damage taken | x |
| KB received | x |
| Weight | |
| Gravity | |
| Fall speed | |
| DamageFlyTop Gravity | |
| DamageFlyTop Fall speed | |
| Traction | |
| Ink |
| Damage | ||
| Charge frames | ||
| Charge max multiplier | ||
| {{Calculator.SelectedMove.MoveRef.ChargeData.label ? Calculator.SelectedMove.MoveRef.ChargeData.label : "Charge frames"}} | ||
| Hitlag | ||
| Angle | ||
| BKB | ||
| FKB | ||
| KBG | ||
| Shield Damage | ||
| Shield stun | ||
| Add. Hitstun | ||
| Effect | ||
| Hit frame | ||
| FAF |
| Landing frame | |
| Landing Lag |
| Controller | |
| Input |
| X | |
| Y | |
| Angle |
| Number of players: | |
| Stock difference: | |
| Launch Rate: |
| Hitstun constant | |
| Tumble hitstun threshold |
| DI angle change |
| Upwards multiplier | |
| Downwards multiplier |
| Multiplier | |
| Decay |
| Multiplier | |
| Constant |
| Multiplier | |
| Constant | |
| Projectile multiplier | |
| Perfect Shield multiplier |
| Multiplier | |
| Constant |
| Frames | |
| Max launch speed |
| Frames | |
| Max launch speed |
| Multiplier | |
| Constant |
| Buried KB resistance threshold |
| {{ x.name }} | {{x.value}} |
| {{ x.name }} | {{x.value}} |
| {{ x.name }} | {{x.value}} |
| X | |
| Y |
| {{ x.name }} | {{ x.value }} |


System backups must be transferred silently. Silent transfers can only be done between a computer and a calculator, and require that the computer make the request or request-to-send.
The protocol for silently sending the special block is shown below:
| Step | Direction | Packet | ||
|---|---|---|---|---|
|
|
|
|
|
VAR with send-style backup header. |
|
|
|
ACK | ||
|
|
|
CTS | ||
|
|
|
ACK | ||
|
|
|
EOT | ||
|
|
|
ACK |
Next, all variables are sent according to the 'Sending a variable' operation
with one important exception: the type field is equal to either 1Dh (none),
26h (locked) or 27h (archived), independantly of the variable type.
| Step | Direction | Packet | ||
|---|---|---|---|---|
|
|
|
|
|
RTS (specifing the size with the extra four bytes) and with a particular type (1Dh, 26h or 27h) |
|
|
|
ACK | ||
|
|
|
CTS or SKIP/EXIT (see note below) | ||
|
|
|
ACK | ||
|
|
|
DATA | ||
|
|
|
ACK | ||
|
|
|
EOT - if there are several variables to transmit, steps 7 and 8 can be skipped until the last variable. | ||
|
|
|
ACK |
Example (PC sending backup from TI):
| PC: | 08 06 0A 00 00 00 00 00 00 1D 04 6D 61 69 6E C6 01 | Variable header: Backup ("main") |
| TI: | 98 56 00 00 | Acknowledgement of header |
| 98 09 00 00 | Clear To Send | |
| PC: | 08 56 00 00 | Acknowledgement of CTS |
| 08 92 00 00 | End of transmission | |
| TI: | 98 56 00 00 | Acknowledgement of data |
|
|
|
|
| PC: | 09 C9 0D 00 0F 00 00 00 1D 06 6D 61 69 6E 5C 66 01 9A 02 | Variable header: "main/f" (none) |
| TI: | 98 56 00 00 | Acknowledgement of header |
| 98 09 00 00 | Clear To Send | |
| PC: | 08 56 00 00 | Acknowledgement of CTS |
| 08 15 13 00 00 00 00 00 00 0D E9 02 01 1F 08 F0 93 E5 08 00 00 00 DC 6C 04 | Variable content | |
| TI: | 98 56 00 00 | Acknowledgement of data |
| PC: | 08 92 00 00 | End of transmission |
| TI: | 98 56 00 00 | Acknowledgement of EOT |
|
|
|
|
| PC: | 08 C9 10 00 06 00 00 00 1D 09 6D 79 5F 64 69 72 5C 73 31 00 B0 03 | Variable header: "my_dir/s1" |
|
|
|
Silent transfers |
Table of Contents |
FLASH transfers |


The secret to getting ahead is getting started.
Since the first day my senior year of high school, I have been documenting a second (or two) of my life every day. I am over two years into this journey, and have absolutely no regrets. I have noticed that I am able to remember my days more clearly, and strive to make life more interesting. I do not plan to stop recording the little moments in everyday life, and encourage you to try this out as well. Take out your phone right now, and record a quick second. You'll wish you had started sooner.
Cornell University: Freshman Year 2017-2018
Allen High School: Senior Year Highlights 2016-2017


200 CIGARETTES A film review by Steve Rhodes Copyright 1999 Steve Rhodes RATING (0 TO ****): *
Attention moviegoers: you are about to enter a meaning-free zone. Should the sound system malfunction during your viewing of 200 CIGARETTES, do not panic. The film will work just as well as a silent movie.
Chronicling the meaningless lives of vain, yuppie types, the movie covers the same ground as the Wilt Stillman films (LAST DAYS OF DISCO, BARCELONA and METROPOLITAN) but without any of his acerbic wit and the inviting style of his writing. First-time writer Shana Larsen makes the mistake of creating a couple of dozen characters and not giving any of them any depth. There isn't one of these characters worth caring about.
The movie features such a cornucopia of hot young stars that it looks like a celluloid version of "People Magazine." Among others, the movie features: Ben Affleck, Casey Affleck, David Chappelle, Janeane Garofalo, Gaby Hoffmann, Catherine Kellner, Courtney Love, Jay Mohr, Martha Plimpton, Christina Ricci and Paul Rudd. And unlike People Magazine, the people speak, not that they have anything interesting to say.
It's New Year's Eve in 1981, and Monica (Martha Plimpton) is preparing her big party. Structured as a series of relatively unrelated stories about her guests on the way to the party, director Risa Bramon Garcia flits back and forth among her stars. Monica's apartment is in "NoHo," an area that one of the guests describes as "so cool, all of the poor people live there."
Typical of the shallow couples in the movie are Kevin (Paul Rudd) and his friend and would-be sexual partner Lucy (Courtney Love). They argue about whether Lucy is a slut or not since she sleeps with everyone, except him, of course.
The movie gets its title from the carton of cigarettes that Lucy gives Kevin for his New Year's Eve birthday. "Cigarettes are a shield against emotional interaction with other people," Kevin later tells Lucy in a snippet of dialog that sounds profound only outside the context of the movie.
Another character, played by Jay Mohr, has a problem with his sexual triumphs. Every woman he beds falls deeply in love with him by the next morning. When his latest conquest tells him of her affection for him, his response is "I like a lot of people."
As the movie finally draws to a close, the characters awaken from their post-party game of musical beds. Some have passed out early from alcohol abuse and remember little, while others actually have some clue as to what happened. The movie itself is so forgettable that by the time you reach your car in the parking lot, all trace of the film will have vanished from your mind, which is probably the best thing that can be said about the movie.
200 CIGARETTES runs 1:40. It is rated R for profanity, sex and one dope smoking scene and would be acceptable for older teenagers.
Email<EMAIL_ADDRESS>Web: www.InternetReviews.com
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Preparation time
less than 30 mins
Cooking time
10 to 30 mins
Serves
Makes 6
This Reblochon tartiflette is a cheesy potato gratin, traditionally quite a heavy winter staple. But made this way you can even serve it on a hot day with a side salad.
Preheat the oven to 180C/350F/Gas 4 and brush a six-hole muffin tin with the soft butter.
Peel the potatoes and use the julienne blade on a mandoline to make thin matchsticks (or slice by hand).
Put the onion, garlic, bay leaf and lardons into a large non-stick frying pan and cook until the lardons are golden-brown. Add the wine and reduce until only a couple of tablespoons of liquid remain. Remove the bay leaf.
Stir in the potato matchsticks and take off the heat, then stir in the Reblochon cubes.
Divide the potato mix between the six holes in the muffin tin and bake for 15–20 minutes or until golden-brown and bubbling. Serve hot.
You need JavaScript to view this clip.
Learning to chop: the 'julienne' technique


-Olivia Speer
Body shaming frequently takes place, especially in early teenage years and early young adult years. I personally have never been directly body shamed, but I do have friends who have been body shamed. For instance, one of my friends was told that “she would be cuter if she lost 15 pounds.” People at times can be cruel and harsh with their words. However, on a larger scale, I think body shaming takes place in the world of commercialism and social media, as I talked about earlier. Companies have the opportunity to take a stand and promote their products in their own way. For instance, as I mentioned, Aerie promotes body positivity and being confident in your own skin, whereas Victoria Secret, for instance, promotes their products by creating this perception that you must be long-legged, small-waisted, and “angelic.”
“Be proud of who you are” and “Everyone is beautiful.”
Inspiration Video
This video explains how people body shame girls off of the way they kick, run, and dance.


Live Prices
Item 1
Item 2
Item 3
Item 4
Users
Login
Limit orders
Sell
Buy
Place Order
Wallet
Asset
Available
Working
Price
Total
0.0
7
30
90
Plot
Open orders
ID
Pair
Side
Type
Price
Amount
Filled
Stop
Fee
X
Strategies
Start
Stop
Log


{% set id = 'modal-privacy' %}
The Youth Financial Capability Assessment is provided by the Consumer Financial Protection Bureau (Bureau) as a financial education resource for parents, educators, and students. No information, including personally identifiable information (PII), will be collected by the Bureau. After completing assessment questions there is an optional feature to share assessment results, with the option to include the initials of your name when sharing the assessment results. If you choose to share assessment results, with or without your initials, this information will be transmitted but the Bureau will not collect, view, or maintain any of your PII.
Using this tool and sharing assessment results is voluntary.


Defines |
| #define | HC_assertThatBool(actual, matcher) HC_assertThatBoolWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatBool HC_assertThatBool |
| | assertThatBool(actual, matcher) - Asserts that BOOL actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatChar(actual, matcher) HC_assertThatCharWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatChar HC_assertThatChar |
| | assertThatChar(actual, matcher) - Asserts that char actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatDouble(actual, matcher) HC_assertThatDoubleWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatDouble HC_assertThatDouble |
| | HC_assertThatDouble(actual, matcher) - Asserts that double actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatFloat(actual, matcher) HC_assertThatFloatWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatFloat HC_assertThatFloat |
| | assertThatFloat(actual, matcher) - Asserts that float actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatInt(actual, matcher) HC_assertThatIntWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatInt HC_assertThatInt |
| | assertThatInt(actual, matcher) - Asserts that int actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatLong(actual, matcher) HC_assertThatLongWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatLong HC_assertThatLong |
| | assertThatLong(actual, matcher) - Asserts that long actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatLongLong(actual, matcher) HC_assertThatLongLongWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatLongLong HC_assertThatLongLong |
| | assertThatLongLong(actual, matcher) - Asserts that long long actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatShort(actual, matcher) HC_assertThatShortWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatShort HC_assertThatShort |
| | assertThatShort(actual, matcher) - Asserts that short actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatUnsignedChar(actual, matcher) HC_assertThatUnsignedCharWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatUnsignedChar HC_assertThatUnsignedChar |
| | assertThatUnsignedChar(actual, matcher) - Asserts that unsigned char actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatUnsignedInt(actual, matcher) HC_assertThatUnsignedIntWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatUnsignedInt HC_assertThatUnsignedInt |
| | assertThatUnsignedInt(actual, matcher) - Asserts that unsigned int actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatUnsignedLong(actual, matcher) HC_assertThatUnsignedLongWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatUnsignedLong HC_assertThatUnsignedLong |
| | assertThatUnsignedLong(actual, matcher) - Asserts that unsigned long actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatUnsignedLongLong(actual, matcher) HC_assertThatUnsignedLongLongWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatUnsignedLongLong HC_assertThatUnsignedLongLong |
| | assertThatUnsignedLongLong(actual, matcher) - Asserts that unsigned long long actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatUnsignedShort(actual, matcher) HC_assertThatUnsignedShortWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatUnsignedShort HC_assertThatUnsignedShort |
| | assertThatUnsignedShort(actual, matcher) - Asserts that unsigned short actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatInteger(actual, matcher) HC_assertThatIntegerWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatInteger HC_assertThatInteger |
| | assertThatInteger(actual, matcher) - Asserts that NSInteger actual value, converted to an NSNumber , satisfies matcher.
|
| #define | HC_assertThatUnsignedInteger(actual, matcher) HC_assertThatUnsignedIntegerWithLocation(self, actual, matcher, __FILE__, __LINE__) |
| #define | assertThatUnsignedInteger HC_assertThatUnsignedInteger |
| | assertThatUnsignedInteger(actual, matcher) - Asserts that NSUInteger actual value, converted to an NSNumber , satisfies matcher.
|
Functions |
| void | HC_assertThatBoolWithLocation (id testCase, BOOL actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatCharWithLocation (id testCase, char actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatDoubleWithLocation (id testCase, double actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatFloatWithLocation (id testCase, float actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatIntWithLocation (id testCase, int actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatLongWithLocation (id testCase, long actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatLongLongWithLocation (id testCase, long long actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatShortWithLocation (id testCase, short actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatUnsignedCharWithLocation (id testCase, unsigned char actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatUnsignedIntWithLocation (id testCase, unsigned int actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatUnsignedLongWithLocation (id testCase, unsigned long actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatUnsignedLongLongWithLocation (id testCase, unsigned long long actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatUnsignedShortWithLocation (id testCase, unsigned short actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatIntegerWithLocation (id testCase, NSInteger actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |
| void | HC_assertThatUnsignedIntegerWithLocation (id testCase, NSUInteger actual, id< HCMatcher > matcher, const char *fileName, int lineNumber) |


Scrum Gathering is an annual conference where software professionals and Agile enthusiasts meet to uncover better ways of working and developing software. You will get the chance to hear leading international and local speakers and more importantly, interact with professionals from various software development communities.


Eclipse SDK's Greatest Hits:
The First Ten Years
John Arthorne
March, 2012
Disclaimer
-
This is a semi-random, subjective list
-
Just some deep Eclipse implementation details that I think are cool, from my perspective
-
This presentation contains code
Source: http://www.flickr.com/photos/cara_vsangel/
What we're going to look at
-
Workspace tree representation
-
Incremental Java build
-
RCP refactoring
-
Command framework
-
p2 resolver
Workspace tree representation
It's ElementTree my dear Watson, ElementTree
ElementTree.java, line 75
ElementTree motivation
-
Typical edit/compile/deploy cycle for a developer focuses on a small segment of a potentially very large code base
-
Want to aggressively optimize for this common cycle: make performance cost proportional to the change, rather than to the size of the workspace
-
Create and manipulate “units of change” that are passed around to interested parties
Data flow
Additional observations
- Clients want a delta of the workspace state between two moments in time
- Different clients may want deltas with different start and/or end points
- May need to keep track of hundreds of tree states at once
- How to efficiently represent all these different deltas in memory?
- How to compute these deltas without traversing entire workspaces?
Representing two tree states
Representing tree states as deltas
More details
- Have only one complete tree, and represent all others as deltas
- Only one delta is mutable - representing current operation
- Immutability allows trees to share common parent and nodes to share children
- Each tree seems complete when traversing using API, but internal structure quite different
- Computing deltas is nearly free for most common operations
Lessons learned
- Not all optimization is a speed-space tradeoff. Here we greatly reduced space required to represent states, and made delta calculation very fast
- Textbook data structures work very well in most programming situations, but sometimes
a very specialized structure is called for
- Internal representation of a data structure can be radically different from external appearance
Incremental Java build
Conducts a trial on a single compilation unit. Returns true if the unit
is guilty. The sentence is compilation without possibility of parole.
IncrementalImageBuilder.java v_146, line 1570
Starting assumptions
- Compilation is expensive
- Compiling a single file can create a ripple effect where many more files need compiling
(picture of ripples)
Eclipse 1.0 Java builder
- Used a trial metaphor
- When a file was compiled it produced evidence (e.g., class B is a subclass of A)
- When A is changed, all files that refer to it are put on trial (e.g., method foo() removed from A)
- All the corner cases are considered: does B refer to foo(), does it also declare foo() and invoke super?
- Compile guilty files; repeat
Revisiting assumptions
- Meanwhile JDT compiler was rewritten to be blazingly fast
- You only need to recompile dependents when there are structural changes
- Structural changes have little or no ripple effect
- Keeping all the evidence around is expensive and slows down compilation
Builder 2.0
- When a file is compiled, check for structural changes by comparing signatures with previous .class file
- If no structural changes, we are done
- If there are structural changes, recompile all dependents
- Faster on average and vastly more memory efficient than Eclipse 1.0 builder
Lessons learned
- Sometimes you need to revisit your starting assumptions
- Sometimes the optimal solution is not the best!
- A simpler solution is often easier to maintain (unnecessary compilation no longer a bug)
Performs arbitrary actions when the event loop crashes.
WorkbenchAdvisor.java, line 297
RCP history
- As an integration platform, Eclipse focus was on seamless integration
- Plugins by design had little or no control over general appearance
- Plugins could only add; not remove
- But some people wanted to be able to build applications that looked very different
- Wanted to remove some of the built in functionality
RCP refactoring
- Mechanical part was scrubbing "tool" artifacts from API
- Harder part: decoupling workbench from the application so other applications could use it
- Required inversion of control - separating policy from mechanism
- IDE-specific behavior and functionality separated from the workbench
- Can't just create preferences - must be under application control
Policy vs mechanism
|
Mechanism
|
Policy
|
|
Error handling
|
Show error dialog, log, exit
|
|
Menus
|
What menus appear, what do they contain
|
|
Toolbars
|
Decide what commands appear in toolbar
|
|
Default perspective
|
Select default perspective
|
|
Startup
|
Restore settings, welcome screen, login
|
|
Window trim
|
Progress, status line, title
|
Workbench advisor
- Application in charge of creating a workbench if desired:
PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor)
WorkbenchAdvisor
is consulted on aspects of window appearance, and has
"hooks" that are run on startup, window open, shutdown, etc.
- Advisor has complete control over default set of commands in menu and toolbars
- Plugins can still contribute their own extra commands if the menu/toolbar exists
Many ways to offer extensibility
|
Mechanism
|
Arity
|
User Control
|
App Control
|
Plugin Control
|
|
Extension points
|
Many
|
No
|
Transforms
|
Yes
|
|
Services
|
Many
|
No
|
No
|
Yes
|
|
Preferences
|
Many
|
Maybe
|
Yes
|
Yes
|
|
System prop
|
One
|
Yes
|
Yes
|
Yes
|
|
Advisor
|
One
|
No
|
Yes
|
No
|
Lessons learned
- The "policy" vs "mechanism" distinction burned into committer minds
- When designing functionality, always have to ask if someone else might want to do it differently
- Is it something any plugin should be able to control? Or only application? Only user?
- There are many ways to offer extensibility with various tradeoffs
Okay. Have a seat. Relax a while. This is going to be a bumpy ride.
WidgetMethodHandler.java, line 81
Key bindings history
- Eclipse 1.0: hard-coded, unmodifiable
- Eclipse 2.0: plugins can contribute bindings, only editor bindings can be customized
- Eclipse 2.1: user contributed key bindings, concept of scopes but limited (global vs editor)
- Eclipse 3.0: key bindings in dialogs, expanded concept of scopes
- Eclipse 3.1: Introduced command framework.. views can override global commands
Challenges
- Every time user hits keyboard need to calculate what to do
- Switching to another view, editor, or dialog changes behaviour of key bindings
- Multiple commands can have same key binding - Ctrl+B could be Build or Bold
- When action has multiple bindings need to decide what to show in menu
- Even within a part the same key binding might have different effect - F2 in Package Explorer
- Incrementally bolting on functionality to original design starting to become untenable
Command framework
- Introduced separation between command and handler
- Key bindings are bound to commands, command get bound to handlers
- Relationship between binding and command is fairly stable
- Keybinding information is almost always served from cache in regular usage
- Relationship between command and handler still needs updating on each part activation
- Only need to process commands that have a handler specific to that part
Lessons learned
- Incrementally adding functionality over time can reach a breaking point where
you need a fundamental rethink
- Creating a pure "model" layer between user inputs and resulting actions was very powerful
- Different parts of the problem could be isolated and optimized
p2 resolver
The fix is to avoid the workaround.
Control.java (Motif), 4076
p2 Background
- Update manager only resolved dependencies at the feature level
- Features that were already installed would never be reconsidered when installing something else
- This could lead to some feature you didn't really care about blocking install of something you really wanted
- Resolving dependencies could sometimes be slow but was generally usable
- Redundant expression of dependencies at feature and plugin level was a source of bugs
Observations
- Observation: some installed things are "roots" that the user chose to install,
other things are installed only to satisfy dependencies
- In p2 we wanted to ensure all dependencies were satisfied - feature, bundle, and package level
- This is an NP hard constraint satisfaction problem, and our hand-crafted resolver wasn't good enough
Boolean satisfaction problem
- A series of boolean expressions (made up of AND, OR, and NOT)
- Is there a set of variable assignments that will satisfy all expressions
- Or, what set of values satisfies the most expressions (MAX-SAT)
1: x & !y
2: x | y
Solution: x=true, y=false
Mapping install to SAT (Projector)
a := Plugin A 1.0 - requires B [1.0,2.0)
b := Plugin A 2.0
c := Plugin B 1.0
d := Plugin B 1.1
(a & c) | (a & d)
(a & !b) | (!a & b)
(c & !d) | (!c & d)
Solution: a=false, b=true, c=false, d=true
- Also assign weights to expressions to cause higher plugin version to be favoured
Lessons learned
- Need to recognize when you have an NP hard problem
- These kinds of problems are big in the academic world and there is a lot of existing work available
- There are probably others who have solved this problem more efficiently
- Those things you learned in school about algorithm complexity and isomorphism sometimes come in handy!
Thank you!


Godlike Planes
The plane you'll travel in are some of the most powerful and aerodynamic planes ever built. The body is made with Aerospace Grade Aluminium & Titanium, materials which are used in making space shuttles, reason why they can withstand an emergency landing on ground.
And it's bleeding edge design cuts through air like a Diamond Blade giving you quiet & smooth flying experience.


<EMAIL_ADDRESS>We kindly remind you that your test assignment should be submitted as a link to github/bitbucket repository.


What is Underwater Hockey (UWH)?
Where it All Began
Underwater Hockey was invented in 1954 by the Southsea Sub-Aquatic Club in Portsmouth, England.  Most countries around the world who have adopted the sport refer to it as “Underwater Hockey” but it is still referred to as “Octopush” in the United Kingdom. Underwater Hockey is very popular in the United Kingdom, Australia, Canada, New Zeeland, and South Africa.
Governing Bodies
There are two world governing bodies for Underwater Hockey: Confederation Mondiale Activities Sub-aquatics (CMAS) which is the European governing body. CMAS organizes international competitions known as the World Games which also include fin swimming and free-diving. The first World Games were held in Bari, Italy in 2007. The World governing body is the World AquaChallenge Association (WAA) which organizes the official World Championships; it was held in Eger, Hungary in 2013 where the USA Women’s team took 6th place. The next World Championships will be held in South Africa in August, 2016.
Underwater Society of America (USOA)
The official governing body of Underwater Hockey in the United States is the Underwater Society of America (USOA). They provide support and national recognition for Underwater Hockey as well as Underwater Rugby, Fin Swimming, and other underwater diving sports. More information on USOA can be found here and further information about upcoming tournaments and Underwater Hockey news in the United States can be found here.
Equipment
Underwater Hockey is a fast paced game played on the bottom of a 6’-8’ pool. Each team has 6 players and the players wear fins, a mask, snorkel, cap with ear guards, and a glove. The sticks that are used are very short, about 1 foot long, and the puck is around 3 pounds and covered in a hard plastic case.
Rules and Strategy
Play strategy is similar to ice hockey or soccer, there are a number of different formations and because players hold their breath while playing, team work is crucial to scoring. The rules are "non-contact", players cannot hold off other players with their free arm, making the game equal across all ages and genders. The main objective of the game is to maneuver the puck across the pool and shoot it into the opponent’s goal. The official rules can be found here.
Learning to Play
Previous swimming experience is not necessary, that's what the fins are for! Some of the best players did not swim before they joined the team. The objective of MSU Underwater Hockey is to teach anyone and everyone how to play the sport regardless of their previous swimming experience.


Bath 16-17 Ulster: John Cooney and Rob Lyttle tries help Ulster to Champions Cup win
Ulster squeezed out a vital 17-16 victory at Bath in their opening match in Pool Three of the European Champions Cup.
Tries in each half by John Cooney and Rob Lyttle helped the PRO14 side make it five straight wins against Bath in European competition. Scrum-half Cooney converted both and kicked a 70th-minute penalty to seal the win.
The Premiership side kept in touch with two penalties from Freddie Burns before replacement wing Gabriel Hamer-Webb scored their only try, converted by Burns. Rhys Priestland's 66th-minute penalty put them ahead for the first time in the match but Cooney had the final say.
England World Cup trio Sam Underhill, Jonathan Joseph and Ruaridh McConnochie were making their first Bath appearances since returning from Japan.
They opened confidently and Priestland soon had a chance to open the scoring but pulled his 45-metre penalty just wide.
Instead, it was the visitors who struck first after 13 minutes. Will Chudley had only just charged down an attempted box-kick by his opposite number Cooney when his own kick through was blocked. Cooney was quickest to the loose ball, hacked on for a kind bounce and sprinted in from 40 metres.
Two penalties in quick succession from Burns, briefly taking over the place-kicking as Priestland nursed a knock to his leg, cut the lead to a single point on the half-hour.
Bath's midfield passing lacked the precision of Ulster's, for whom full-back Will Addison was a particularly creative influence.
The former Sale man, capped by twice by Ireland, was involved in a prolonged series of attacks at the end of the half which finally yielded a penalty in front of the Bath posts but Cooney somehow pushed his kick wide.
On their return from the half-time break, Ulster showed signs of wilting - missing tackles on Semesa Rokoduguni and Will Stuart and having a narrow escape when Charlie Ewels' offload deep into the visitors' 22 found Stuart McCloskey rather than Bath hands.
But it then took a try-saving tackle by Priestland to deny centre Luke Marshall at the other end before Ulster increased their lead on the hour with a try by right wing Lyttle, chasing Addison's kick down the touchline.
Cooney converted to make it 14-6 but Bath hit back straight away as rookie left wing Hamer-Webb rounded Addison with ease to score in the corner, with Burns adding the conversion.
A high tackle by Alan O'Connor on Underhill allowed Priestland to give Bath the lead, but the advantage was short-lived as Cooney kicked a simple penalty in reply.


This extension removes sponsored posts (ads) from user's Facebook news feed.
Based on Facebook Ad Highlighter Chrome Extension by Grant Storey.
Icon made by OCHA from www.flaticon.com.
This extension removes sponsored posts (ads) from user's Facebook news feed.
Based on Facebook Ad Highlighter Chrome Extension by Grant Storey.
Icon made by OCHA from www.flaticon.com.


/** * @author Ed Spencer * @private * * Represents a single action as {@link Ext.app.Application#dispatch dispatched} by an Application. This is typically * generated as a result of a url change being matched by a Route, triggering Application's dispatch function. * * This is a private class and its functionality and existence may change in the future. Use at your own risk. * */ Ext.define('Ext.app.Action', { config: { /** * @cfg {Object} scope The scope in which the {@link #action} should be called. */ scope: null, /** * @cfg {Ext.app.Application} application The Application that this Action is bound to. */ application: null, /** * @cfg {Ext.app.Controller} controller The {@link Ext.app.Controller controller} whose {@link #action} should * be called. */ controller: null, /** * @cfg {String} action The name of the action on the {@link #controller} that should be called. */ action: null, /** * @cfg {Array} args The set of arguments that will be passed to the controller's {@link #action}. */ args: [], /** * @cfg {String} url The url that was decoded into the controller/action/args in this Action. */ url: undefined, data: {}, title: null, /** * @cfg {Array} beforeFilters The (optional) set of functions to call before the {@link #action} is called. * This is usually handled directly by the Controller or Application when an Ext.app.Action instance is * created, but is alterable before {@link #resume} is called. * @accessor */ beforeFilters: [], /** * @private * Keeps track of which before filter is currently being executed by {@link #resume} */ currentFilterIndex: -1 }, constructor: function(config) { this.initConfig(config); this.getUrl(); }, applyBeforeFilters: function(filters) { return filters || []; }, /** * Starts execution of this Action by calling each of the {@link #beforeFilters} in turn (if any are specified), * before calling the Controller {@link #action}. Same as calling {@link #resume}. */ execute: function() { this.resume(); }, /** * Resumes the execution of this Action (or starts it if it had not been started already). This iterates over all * of the configured {@link #beforeFilters} and calls them. Each before filter is called with this Action as the * sole argument, and is expected to call `action.resume()` in order to allow the next filter to be called, or if * this is the final filter, the original {@link Ext.app.Controller Controller} function. */ resume: function() { var index = this.getCurrentFilterIndex() + 1, filters = this.getBeforeFilters(), controller = this.getController(), nextFilter = filters[index]; if (nextFilter) { this.setCurrentFilterIndex(index); nextFilter.call(controller, this); } else { controller[this.getAction()].apply(controller, this.getArgs()); } }, /** * @private */ applyUrl: function(url) { if (url === null || url === undefined) { url = this.urlEncode(); } return url; }, /** * @private * If the controller config is a string, swap it for a reference to the actual controller instance. * @param {String} controller The controller name. */ applyController: function(controller) { var app = this.getApplication(), profile = app.getCurrentProfile(); if (Ext.isString(controller)) { controller = app.getController(controller, profile ? profile.getNamespace() : null); } return controller; }, /** * @private */ urlEncode: function() { var controller = this.getController(), splits; if (controller instanceof Ext.app.Controller) { splits = controller.$className.split('.'); controller = splits[splits.length - 1]; } return controller + "/" + this.getAction(); } });


she reconnects the theoretical threads of the languages of art to project zero. nice recap of LA and insights into P0.
Languages of Art is a theory of symbols.
Only a non-insular conception of art can dissolve the dichotomy between the cognitive and the emotiv that makes it impossible to seize “the modes and means of reference and their varied and pervasive use in the operations of the understanding” (Goodman, 1968: XI)
Referential practices developed by Goodman:
Requirements of a notational system:
art builds a certain vision of the world: that makes ways of worldmaking quite relevant (with implications to poetics)
In the aesthetic experience, the emotion functions cognitively (goodman)
Symptoms of the aesthetic:
The question of programming languages is: are there symbol systems which perform better than others? Under what standards?
She mentions Goodman’s 1972 report on Project Zero:
realization, whether in physics or painting, in medicine or music, is normally an arduous process, straining skill and pertinacity (goodman)
Production and understanding in the arts involve human activities that, though they differ in specific ways among themselves and from other activities, are nevertheless generically related to perception, scientific inquiry, and other cognitive activity (goodman)
The emphasis placed on the symbolic, cognitive, planning aspects of the arts leads us to give value to the role played by problem-solving, seeing there a model in terms of which the moment-to-moment artist’s behavior at work can be described. “An analysis of behavior as a sequence of problem- solving and planning activities seems to be most promising […]” (goodman)
In terms of worldmaking:
The arts make world-versions using various means of reference: - statement - description - representation - exemplification - expression
and they are then jugded by the general notion of rightness of fit.
A bit elaborate is “seeing the world in terms of the artwork/specific arrangement of the symbol system we are presented with”. Peering into the machine’s world.


Try out our Premium Member services: Virtual Legal Assistant, Query Alert Service and an ad-free experience. Free for one month and pay only if you like it.
:: 1 : MCrC.No.3562/2018 HIGH COURT OF MADHYA PRADESH PRINCIPAL SEAT AT JABALPUR MCrC No.3562/2018 (Amritlal Singh vs. State of M.P.) Jabalpur, Dated : 02.07.2018 Shri Vivek Shukla, learned counsel for the petitioner. Shri Manish Awasthi, learned Government Advocate for respondent/State.
Heard.
Perused the case diary.
The petitioner has filed this petition under Section 482 of CrPC being aggrieved by order dated 11.01.2018 passed by II ASJ Sidhi, District Sidhi, in Criminal Revision No.215/2017 arising out of order dated 20.11.2017 passed by Judicial Magistrate First Class, Churhat, District Sidhi in Crime No.501/2017. whereby, the application filed under Section 457 of CrPC has been dismissed.
Prosecution case, in short, is that on 09.11.2017 Police Station Churhat, District Sidhi received information from the informer that owner of vehicle Tractor bearing No.M.P. 53 A.A. 6454 is transporting illegal sand. On such information, Police apprehended the said vehicle and registered offence punishable under Section 379, 414/34 of IPC; Section 27, 29, 39, 41 & 51 of Wild Life Protection Act; Section 2, 41, 52 of India Forest Act; Section 4 & 21 of Mines Act and Section 15 of Pollution Control Act, 1986 vide crime No.501/2017 against the owner and driver of the vehicle.
The petitioner filed an application under Section 457 of CrPC for "Supurdginama" of the seized vehicle. The application was :: 2 :
MCrC.No.3562/2018 rejected by the JMFC, Churhat, District Sidhi vide order dated 20.11.2017 and order of rejection was affirmed by the ASJ, District Sidhi vide order dated 11.01.2018.
The petitioner has filed Registration certificate, Certificate of Insurance cum Policy Schedule, Permit of transportation and vehicle fitness certificate with regard to Vehicle Tractor bearing No.M.P. 53 A.A. 6454.
Learned counsel for the petitioner has submitted that impugned orders are illegal and arbitrary. It is further submitted that the vehicle is parked in open place in the police station and if is will remain in open place it will be damaged. It is also submitted that the petitioner was using said vehicle for loading and unloading of articles for work which was going on in nearby villages. On these grounds prayer is made to release the vehicle on "Supurdginama."
Per contra, learned counsel for the State has opposed the petition.
At this stage, learned counsel for the petitioner has relied upon Madhukar Rao Vs. State of M.P. 2000 (1) MPLJ (FB) 289 in which it has been held that, the property including the vehicle seized on accusation or suspicion of commission of an offence under the Act can, or relevant grounds and circumstances, be released by the Magistrate pending trial in accordance with Section 50(4) of the Act and Section 451 of Cr.P.C. Mere seizure if any property including vehicle on the charge of commission of an offence would not make the property to be of the State Government under Section 39(1) (d) of the Act.
In similar facts in the case of Sunderbhai Ambalal Desai Vs. :: 3 :
MCrC.No.3562/2018 State of Gujarat, (2002) 10 SCC 290 Hon'ble the Apex Court has clearly and unambiguously has held that the vehicle or equipment seized shall be released within a period of 15 days as far as practicable for keeping the vehicle in open would caused damaged to the vehicle.
On the other hand learned counsel for the State relied on Ramniwas Vs. Game Range Chambal Sanctuary Bhind Headquarter, Ambah District Morena 2012 CRI. L.J. 1747.
Keeping in view taken by the Hon'ble Supreme Court in case of Madhukar Rao (supra) and Sunderbhai Ambalal Desai (supra), petition is allowed. Impugned order dated 11.01.2018 passed by II ASJ Sidhi, District Sidhi, in Criminal Revision No.215/2017 arising out of order dated 20.11.2017 passed by Judicial Magistrate First Class, Churhat, District Sidhi in Crime No.501/2017 is hereby, set aside.
It is directed that the vehicle Tractor bearing No.M.P. 53 A.A. 6454 be given to the petitioner on "Supurdginama" subject to production of the original registration certificate and insurance certificate. Accordingly, it is ordered that the vehicle Tractor bearing No.M.P. 53 A.A. 6454 seized in connection with Crime No.501/2017 be given to the petitioner till the disposal of the case or the final disposal of the confiscation proceeding, if any, before the Forest Department, whichever is earlier on the following terms and conditions:-
(i) That, the petitioner shall furnish a personal bond in the sum of Rs.5,00,000/- (Rupees Five Lakhs Only) with one solvent surety in the like amount to the satisfaction of the trial Court on an undertaking to produce the said vehicle before the trial Court as and when required.
(ii) That, the petitioner shall get the vehicle photographed :: 4 :
MCrC.No.3562/2018 showing the registration number as well as the chassis number of the motorcycle. Such photographs shall be taken in the presence of the responsible officer, who will be deputed by the trial Court and to be kept in the file of the case.
(iii) That the personal bond of the petitioner as well as surety shall carry the photographs of both and the bond of surety shall further carry the photograph of person identifying him before the Court which would be with full residential proof of the surety and the person in defying him.
(iv) The petitioner shall undertake not to transfer the ownership of the vehicle and shall not lease it to anyone and not make or allow any changes in it to be made so as to make unidentifiable.
(v) The petitioner will not allow the vehicle to be used any antisocial activities.
(vi) In the event of confiscation order by the Court competent, the petitioner shall keep the vehicle present positively for confiscation.
(vii) The petitioner is also directed to produce the Bank Guarantee of Rs.2,00,000/-(Rs. Two lakhs only) for two years before the concerned trial Court for the aforesaid purpose. The petition is allowed in above terms.
A copy of this order be sent to the learned trial Court for necessary compliance.
Certified copy as per rules.
(Smt. Anjuli Palo) Judge shabana Digitally signed by SHABANA ANSARI Date: 2018.07.03 14:04:17 +05'30'


They help define who someone is and what they truly believe in. When you understand your values, you can understand what you want out of something and what you expect from those around you. This allows you to make clearer and smarter decisions.
How the brain functions and how we learn. I think I’m a slow learner and I use to label this as failing, which is why I struggled at school, and hence probably a big factor why I never went to university. I was scared to attempt ‘study’ as I was afraid I would be a failure. Learning about things like neuroplasticity and a growth mindset has taught me that I can learn new skills and that struggling isn’t necessarily a bad thing, you’re just not there ‘yet’.
Evaluating myself. I don’t usually stop to think about myself and how I operate and learn best. It was challenging to write that down and think “yeah, this is me, this is how I work, think” etc.
I think learning Core skills from the start is good as it teaches people valuable skills that will help them not only in their career, but also bootcamp. Bootcamp and the real world can be extremely challenging and stressful so knowing how you work and learn best and how to navigate this I’m important.
I don’t believe it was a waste of time, no. I think it teaches important skills necessary to succeed in the tech industry. However, I feel like for some people, like myself, who feel like they haven’t quite grasped JavaScript and feel like they aren’t quite prepared for the start of Bootcamp, it would be good to feel a little more confident in myself and with my knowledge of JavaScript going into bootcamp. I feel like Core could have been reduced slightly and more could have been put into teaching tech. That said, I really enjoyed this Core section as I believe it has taught me some valuable skills that will serve me greatly.


{% extends 'layouts/layout.html' %} {% from 'button/macro.njk' import button %} {% from 'back-link/macro.njk' import backLink %} {% block pageTitle %} Enter your NHS number {% endblock %} {% block content %}
We still cannot match you to an NHS record using the details you have given.
We may be able to match you to an NHS record if you can prove your identity.
You can enter your details again, or try another way and prove who you are.


DENV dengue ELISA virus samples serum detection using Dengue capture Platelia serotype-specific clinical positive serotype MAbs viral DENV, serotypes specificity {border-style antibodies infection patients IgM/IgG px;} #ffffff;} results serotyping disease infected proteins sensitivity used assay negative severe Trop antibody cells diagnosis infections RT-PCR antigen fever virus-specific MAb-., early ELISA, Kaohsiung MAb MAb-. Vero cases determined diagnostic infection. obtained test Clin ELISA. Med NS. cell methods paired tested (–). CI, Infect RT-PCR, SYBR [/( analysis antigens green hemorrhagic incubated monoclonal performed px; rapid risk serotypes. study {font-family μl (). Armed City, DENVs Forces General Hyg:–. Taiwan Taiwan, commercial cross-reactivity development different font-size non-dengue one-step second (.–.) (/) (/), . ng/ml, DENV. Dis:e. Dis:–. Immunol:–. KalayanaroojS, NS, Negl RNA TABLE achieved assays differentiate disease. doi:./journal.pntd.. double; enzyme-linked however, identify immunosorbent million multiple plates protein real-time regions supernatant testing tests .GuzmanMG, CI]) Hospital, Institute Microbiol National Preventive Rev Table Zika able accordance accuracy acute anti-NS available border-color border-width develop developed doi:./ajtmh.... flow following follows: generated global high human infections. lateral management medical method onset patient purified solid; specific stages subsequently total {font-style {font-weight (.–) (DENV), (Table Aedes BalmasedaA, Branch Centers Clinical Conformational DENVa Disease ELISAs Early IgG Japanese JarmanRG, MAb-.) MAbs. Moreover, NisalakA, No. RT-PCR. ability acute-phase analysis. antibodies) application bold buffer capable caused collected commercially confirmed courier; cross-reactive culture detect em; encephalitis epidemics expensive facilitate fever, form forms illness immunoaffinity-purified involved levels mice no. number outbreaks overall pairing predictive presence pt;} rates resources samples, samples. selected sera serotype-cross-reactive severity soluble step supernatants terms time value various days min.