WebGL, a technology which exploits the power of the GPU to display high-quality 3D graphics, is not available. X3D is displayed in wireframe mode. Some elements, such as textures, aren't shown, which will deprive you of the complete observation of the virtual experiment.

We strongly recommend the use of a modern web browser compatible with WebGL, and enabling WebGL in the browser settings if this isn't done automatically.

Observe the system to get a basic understanding of its main features: the d.c. electrical motor is on the right and drives a large wheel. Straight rails are fixed on the wheel and a ball rolls freely on them between hard stops.

Observe the movements of the wheel and ball. The controller tries to move
the ball to three different rest positions.

Then interact with the system:

Drag a point not on the system to move the point of view around the system. You can revert to the initial view with the target icon , and restart the simulation with the reset icon .

Drag the wheel to make it rotate. Note that the ball remains on the rails even for extreme accelerations: that's a limitation of the simulation we deem to be appropriate.

Try to bring the ball to a rest position by moving the wheel by hand.

Drag the ball on the rails. Keep the ball still for a while and observe the movements of the wheel. What happens?

You can reduce the power consumed by your computer by unselecting the “Run” checkbox to pause the simulation.

Model

For simulation and controller design, the system is represented as a state-space model. It can be split into two subsystems: the electrical drive with the d.c. motor, and the mechanical part with the wheel, rails and ball. These subsystems have a mutual influence, not an input-output connection where causality is clearly defined.

Details

The numerical values given for the parameters correspond to the virtual experiment.

Electrical drive

System input

u (motor voltage)

Parameters

Rm = 1 Ω (motor resistance)

K = 0.1 N·m/A (motor torque/current constant)

N = 7 (reduction factor from motor to wheel)

Jw = 0.02 kg·m^{2} (moment of inertia of the load)

Auxiliary values

Mm (moment on the rotor produced by the motor)

M (moment on the wheel produced by the motor)

theta (angle of the wheel, 0 when rails are horizontal)

thetaDer (derivative of theta)

Equations

M = N Mm

M = K N (u − K N thetaDer) / Rm

Wheel and ball

Parameters

m = 0.1 kg (ball mass)

r = 27·10^{−3} m (rail contact radius of the ball)

J = 36·10^{−6} kg·m^{2} (moment of inertia of the ball)

g = 9.81 m/s^{2} (gravity acceleration constant)

Auxiliary values

thetaDDer (second derivative of theta)

phi (ball angle with respect to earth)

phiDer (derivative of phi)

phiDDer (second derivative of phi)

p (ball position along rails, 0 at wheel center)

pDer (derivative of p)

pDDer (second derivative of p)

F (tangential force applied by ball to wheel at contact point)

Equations

(Jw + m p^{2}) thetaDDer = M − m g p

m pDDer = F − m g sin theta + p thetaDer^{2}

J phiDDer = F r

phi = −p / r

State-space model

Combining these equations gives the following state-space model for the complete system.

States

theta (angle of the wheel, 0 when rails are horizontal)

thetaDer (derivative of theta)

p (ball position along rail, 0 at wheel center)

pDer (derivative of p)

Equations (non-linear model)

theta' = thetaDer

thetaDer' = (K N (u − K N thetaDer)/Rm − m g p) / (Jw + m p^{2})

p' = pDer

pDer' = (p thetaDer^{2} − m g sin theta) / (m + J/r^{2})

These equations aren't linear with respect to states and input. It isn't a problem for numerical simulation (at least not a difficult one: we're using a Runge-Kutta 4th order integration algorithm with a fixed maximum time step), but many controller design methods, such as those in frequency domain, require linearity.
Therefore we'll make approximations based on the following assumptions:

The ball mass has a negligible effect with respect to the moment of inertia of the wheel.

The centrifugal force is negligible with respect to the gravity along the rails.

The wheel angle is small, i.e. sin theta ≈ theta.

This leads to the following linear model with the same states.

Equations (linear model)

theta' = thetaDer

thetaDer' = (K N (u − K N thetaDer)/Rm − m g p) / Jw

p' = pDer

pDer' = −m g theta / (m + J/r^{2})

In the state-space models above, the ball weight applies a moment on the wheel which depends on its position. If m g p is negligible with respect to the motor torque, the linear state-space model becomes

Equations (decoupled linear model)

theta' = thetaDer

thetaDer' = K N u / (Rm Jw) − K^{2} N^{2} thetaDer / (Rm Jw)

p' = pDer

pDer' = −m g theta / (m + J/r^{2})

We have here two subsystems connected in series: the first two equations for the d.c. motor and wheel with input u and output theta, and the last two equations for the ball with input theta and output p. The controller must be robust enough to support all these approximations, in addition to other model structural assumptions, parameter uncertainties and external perturbations.

The system will be controlled with cascade controllers. The inner loop controls the wheel angle theta with a PD controller whose control signal is the motor voltage u. The rotation speed of the wheel is assumed to be measured to avoid an explicit differentiation; the controller doesn't require an additional state. The reference value is the wheel position requested by the outer loop, which is ignored in the derivator term of the controller (its derivative isn't required).

The outer loop controls the ball position; its control signal is the wheel angle, the reference value passed to the inner controller. Here again, the ball linear speed is assumed to be measured and no additional state is required for the controller. The reference value is typically 0: the purpose of the controller is to stabilize the ball at the central position and to reject perturbations. Should the reference value change, its derivative would be ignored in the derivator term of the controller.

The controller equations are given below.

Controller parameters

kp1 (proportional gain for the inner loop)

kd1 (derivator gain for the inner loop)

kp2 (proportional gain for the outer loop)

kd2 (derivator gain for the outer loop)

Independent reference value

pRef (reference ball position, typically 0)

Auxiliary value

thetaRef (reference value of the wheel angle)

Equations (cascade PD controllers)

thetaRef = kp2 (pRef − p) − kd2 pDer

u = kp1 (thetaRef − theta) − kd1 thetaDer

Controller design

The transfer function of the two subsystems and the controller parameters can be computed with Sysquake.

Sysquake js

Type assist model and press the Enter button or hit the Return key repeatedly to see how. You can also modify commands, stop the assisted mode, start again, clear the output with clc or get help with doc.

Javascript is disabled or not available.

Sysquake Mobile relies on Javascript to run in your browser. If you want to use it, please enable Javascript or choose another browser.

EnterSkipStop DemoFigure

P

B

P

P

Documentation

About Sysquake Mobile

Sysquake Mobile, a JavaScript version of Sysquake you can rely on wherever you are.

With the interactive Sysquake applications, you can experiment with different controller parameters, see their effect on the virtual experiment and get a better understanding, or confirm your knowledge of, automatic control.

Can you distinguish the effects of each parameter of the inner loop controller and the outer loop controller? Try to detune each of them in turn.

Is the ball position control performance the same for the central position and right or left positions? Why?

Can you notice differences between the models used in Sysquake and the model used in virtual reality?