# System identification on a system with constraints

I am trying to estimate a transfer function for a pan - tilt unit which is not as easy as I hoped.

Its input parameter is a velocity, but it is constrained to move from 0° - 359° and the other way around. Saying in another way, it is not capable of continuously pannning 360°. When it hits 359° it will not move in same direction, but has to move in the other direction. Pan can be moved with max velocity $\approx \frac{\pi}{2}$ rad/s and for the tilt is the max velocity $\approx$ 0.3 rad/s.

The same goes for the tilt, it is just limited to move within a more narrow field. Both the pan and tilt part is driven by stepper motors.

What kind of test can be performed to identify the system? I know its position and the velocity it moves with at all time. My idea was to change input direction when the position reaches a limit, but it would just mess up my sine sweep.

The system ID has to be used to apply a proper controller by using pole placement, and make the system act as i want it. The system has to be able to track a face.

The input to the system is a Pixel displacement which by using some simple math can be converted into angular displacements => the input is the angular displacement.. The PTU has to center itself such that the camera mounted at the top keeps the face at the center at all time.

• It sounds like you are trying to characterize the system with a linear time-invariant (LTE) model, but hitting a limit is a highly nonlinear process. If you could add some information about what the Sys ID will be used for, then it might be possible to tell you a better way to characterize the system. May 18, 2015 at 19:23
• Edited - And yes it is exactly as you are saying. The system in centrum is this FLIR PTU D48 E: link
– bob
May 18, 2015 at 19:29
• @bob - From the link you posted (and from personal experience, what I thought was the case), " The PTU-D48E features internal wiring with slip-ring for 360-continuous pan. " So what exactly is the problem you're having with continuous pan? Dec 15, 2015 at 15:54
• What is the input and what is the output? Apr 13, 2016 at 14:27

## 2 Answers

"Design of experiments" could help you achieve the minimum number of tests to come up with a mathematical model (transfer functions) of your setup.

You can try two methods:

First is the BLACK BOX approach (you have no clue what the camera is doing). You could divide the whole movable region into sections, elevationwise and azimuthwise. By doing different SysId tests in intersections of those areas, you would find how location changes the dynamic behavior of your system. The difference might be a result of:

1. CG of the camera, which is not perfectly at the center and changes the inertial load on the servo motors.
2. differing servo specs at different angular positions (due to mechanism design)

After doing the sys-ID tests in those different positions, you would come up with a "non-linear model" in the sense that for different positions your model would be somewhat different. (I suspect that elevationwise difference would be more than the azimuthwise difference).

Your test inputs would be:

• square signals (with different amplitudes),
• ramp commands (with different speeds),
• sine sweeps (with differing frequencies). Remember that, your position should not hit the walls (limits), in order to not ruin the data. To do that, you need to define your limits beforehand.

For example: Suppose you are doing sine sweep at Azimuth, so elevation limits are no concern (for this case). And suppose you are doing it around 300degrees. The magnitude of your sine-sweep can be 5 degrees (and with different frequencies), 10 degrees, but not 60 degrees, as probably the camera would hit the limit.

It is a good practice to design your tests in a table format (Excel or otherwise), and use them as inputs to your "test conducting code".

Your test table might have the following data fields:

1. Azimuth_0 (starting point of the test-case)
2. Elevation_0 (starting point of the test-case)
3. Type_of_test (0,1,2, 0: square (sudden command), 1: ramp (different speeds), sine (sinusoidal) )
4. amplitude (the range to go)
5. Frequency (for sine inputs, 0 if it's not a sine sweep)
6. Speed (for ramp inputs, 0 if it's not a ramp input)
7. direction (0 for azimuth, 1 for elevation)

So at the end of allowable range, your model might not be great towards hitting the limits.

After getting your different systems, you could design separate control gains for separate regions, and may blend or just switch the gains as you switch from one region to the other.

SECOND Approach can be a more functional one: the GRAY BOX approach, where you know what the camera is doing when commanded. Here's a useful article describing the System Identification of a Pan-Tilt camera.

Hope this helps to define your experiments. Good luck.

• Wel the camera is providing the input, but i was thinking of provide it myself so the camera is out of scope at the moment.. but how will you design your experiment such that never hit a non linear area?
– bob
May 19, 2015 at 6:05
• But.. still that way i won't be able to "fully" be able to determine my transfer function.
– bob
May 19, 2015 at 7:29
• Sorry, I couldn't fully understand your comments, maybe I stuck to my solution :). The original question asks about getting the system transfer function, through tests. The method I've suggested finds *several transfer functions, representing the whole space. Are you in search of finding a single tranfer function, representing all the nonlinearities (boundaries, and dynamics)? May 19, 2015 at 9:46
• I am trying find one accurate function for the pan one for the tilt swell.
– bob
May 19, 2015 at 12:01
• but if i keep my velocity low, the estimated transfer function won't know that it can reach those speeds or am i misunderstanding something?
– bob
May 19, 2015 at 12:02

This partially an exploration of the question and partially a partial answer, but is not suited to the comment format.

The following is "obvious enough" but provides two simple rules to allow you to make (drastic) position adjustment decisions in the rotational direction.

Summary:

For desired position = P and
range of legitimate positions are 0 <= P <= 359 degrees.

Calculate desired P. Then -

• If P_modulo_360 < P adjust P by -360 degrees.

• If P < 0 adjust P by + 360 degrees.

Otherwise set camera to P by following whatever rules are established.

In the tilt direction, the rule is -
"If tilt is outside range then you cannot get there from here" :-(.

It seems that you CANNOT do what you want to do in all cases - eg if the face cannot be centred in the vertical axis by tilting because end of travel is reached then there is no way of centring it and you need to 'declare an exception' - probably by sounding an alarm to bring the situation to the operator's attention. However, when the "end of travel" is reached rotationally you can turn 359 degrees (or less) in the opposite direction to continue on the other side of the end-stop.

So, what you are asking is to identify situations where 'other action' is required. ie you say
"... The PTU has to center itself ... keeps the face at the centre at all times." Two different actions are required for rotate and for tilt.

Tilt is "easiest" because there is nothing you can do to point the camera correctly if the end of travel is reached. You can only bring the situation to an operator's attention.

Consider a rotate unit that can assume absolute positions from 0 to 359 degrees and
camera position in degrees is "P".

This portion is obvious but 'sets the scene':
If while eg rotating clockwise you logically reach a hard boundary at absolute position = 359 degrees, while intending to reach absolute position P = "360 + X" degrees, you can instead rotate anticlockwise to P - 360 degrees.
Position will now be P = 360 + X - 360 = X as desired.

To achieve this transition "automatically" you simply compare P with P_modulo_360.
If P_modulo_360 = P all is well.
Any time (P_modulo_ 360) < P you need to adjust P by -360 degrees .

Attempts to pass the end stop while travelling anti clockwise attempts to set P < 0.
Any time P < 0 you need to adjust P by + 360 degrees.

Transiting between positions either side of the rotational stop obviously plays havoc with smooth tracking and is to be avoided if at all possible.

• The input can be simulated doesn't have to be from a camera..
– bob
May 19, 2015 at 6:26