new web: http://bdml.stanford.edu/pmwiki

TWiki > HSR Web>HumanSafeRobot>ControlAndDynamicModeling (28 Feb 2008, BarrettHeyneman)

- IreneSardellitti?
- BrianHachtmann?
- JasonReid?
- DanAukes
- SeokchangRyu
- BarrettHeyneman
- JohnUlmen

Basic Joint Control

- Stability and performance

Responsive Control

- Bone and Skin Sensor Response Modeling
- Estimation of expected Bone and Skin sensor inputs
- Safe Response

-- BrianHachtmann? - 30 Jan 2008

Irene's thought was: perhaps we are hitting the torque limits of the **Mini**, and as a result we are seeing this undesirable behavior. So, what happens if we include a saturating element in series with the **Mini**? And how can that inform the design of the controller; both the outer, **DM2**, controller as well as the inner **Macro** or **Mini** controllers. The block diagram of the system with the saturation is shown below (the transfer functions in the blocks are just place-holders from simulink).

The basic assumptions are:

- The
**Macro**can provide large enough torques that we assume no saturation. It will have a low bandwidth relative to the desired arm trajectories, so the closed loop**Macro**is assumed to act like a low-pass filter. - The
**Mini**has a much higher bandwidth; high enough relative to the desired arm trajectories that we can consider it a unitary gain. The torque limits are captured in the series saturating element. - The
**Macro**and**Mini**are connected in the parallel**DM2**scheme (captured in the block diagram structure).

After some playing around with a model including the saturation, we found that it does predict instability above certain amplitude/frequency combinations of the input signal (though it doesn't seem to say anything about the lower than expected bandwidth). The next question was; given this model can we say anything interesting about how to design the controller(s). We think the answer is ** YES**.

If we assume **N(a) = 1**, then the whole **DM2** block becomes unity gain, and we can design an aggressive, high performance controller based on **G_link** alone. Unfortunately, the system becomes unstable for certain inputs, because for those inputs **N(a) < 1**.

It turns out, if you plot Root Loci and explore how the value of **N(a)** affects the stability, smaller values cause more aggressive controllers to become unstable (at least for a second order **G_link** and a lead controller). One way to address this is to shape our input trajectories, so that they never cause the mini to saturate (i.e. **N(a) = 1** always).

On the other hand, if you design a controller for the worst case, when **N(a) = 0**, the system will ** NEVER** be unstable, and we don't have to do any input shaping. But when

We would like to have a way of predicting what inputs will cause the system to be unstable, for a given controller. Moreover, we would like to be able to use that information to help design the controller. One way we've come up with is to trade off between having the least restrictive input shaping and having an aggressive, high-performance controller. This tradeoff is partly motivated by the assumption that the majority of the arm's trajectories will not saturate the **Mini** (**N(a) ~= 1**), and we would like to have the best performance possible for these trajectories. At the same time, a few trajectories may cause the **Mini** to saturate, and the arm cannot become unstable in those cases.

Once we have the value of **K_min**, we perform two steps; designing the controller and characterizing the required input shaping.

One method which looks promising is to:

- "Break" the system by removing the
**Mini**and saturation element. This makes the system 2-input-2-output, where the inputs are the desired trajectory,**Theta_des**, and the saturated**Mini**torque,**tau_ms**and the two outputs are the actual trajectory,**Theta**, and the unsaturated**Mini**torque,**tau_m**. - We assume that
**tau_ms**is saturated and therefore specify the amplitude.- The easy but less accurate saturation amplitude is simply
*tau_sat*. - A more complicated (and not yet explored) saturation amplitude would be a function of
*tau_sat*and the amplitude of**tau_m**.

- The easy but less accurate saturation amplitude is simply
- We then find the transfer function from
**Theta_des**and**tau_ms**to**tau_m**(the transfer function for**Theta**doesn't help us here). - Because the saturating element that we removed is a pure gain, i.e. no phase change, we know that the phase of
**tau_m**and**tau_ms**must be the same. - We then use this transfer function and the equal phase restriction to set up two equations relating the amplitude and phase of
**tau_m**to the amplitude and frequency of**Theta_des**and the saturation torque,*tau_sat*. - Once we solve for the amplitude of
**tau_m**, we can either use the describing function,**N(a)**, directly or (to be more consistent with the choice is step 2) the ratio of**|tau_ms|**to**|tau_m|**to get**N(a)**as a function of the amplitude and frequency of**Theta_des**and*tau_sat*.

With this function we can restrict all desired trajectories so that our original assumption of **N(a) >= K_min** is true for all inputs, and therefore the controller we designed in the first step will always be stable.

-- BarrettHeyneman - 28 Feb 2008

Copyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.

Ideas, requests, problems regarding TWiki? Send feedback

Ideas, requests, problems regarding TWiki? Send feedback