How and when to use Describing Function Method in Control Systems

The frequency response method is a powerful tool for the analysis and design of linear control systems. It is based on describing a linear system by a complex-valued function, the frequency-response, instead of a differential equation.

For some nonlinear systems, an extended version of the frequency response method , called describing function method, can be used to approximately analyse and predict nonlinear behavior. The main use is for the prediction of limit cycles in nonlinear system, as for example described in this  PhD thesis. Often, limit cycles tend to cause poor control accuracy and the constant oscillation can cause wear or mechanical failure of the control system hardware.

The basic assumptions for describing function analysis are:

  • there is only a single nonlinear component
  • the nonlinear component is time invariant.
  • the nonlinearity is odd
  • higher-frequency harmonics could be neglected

An introduction to describing methods can be found at this page and in the YouTube MIT course.


Football Championship

football-1-1200x330The most interesting football championship of the year has just come to an end. With a tied result after the regular time, and with both teams scoring one goal each in the extended time, the outcome of the final was determined by penalties. The winner was the runner-up of last year – TechUnited Einhoven!

The championship in question is of course RoboCup 2016! RoboCup is an annual academic competition consisting of various disciplines. TechUnited Einhoven won one of the largest leagues, for the middle-size football platform, but there are also humanoid and standard platform football leagues. Also, it is not all football . Other competitions include for example Rescue, in which the robots operate in a simulated disaster area (an area perhaps suitable for the Combine hexacopter or hexapod),  and @Home, which aims to develop service and assistance robots.

Leipziger Messe: Robocup 2016, Leipzig, 03.07.2016
Leipziger Messe: Robocup 2016, Leipzig, 03.07.2016. Photo: Leipziger Messe / Stephan Hoyer.

Looking at the football leagues, the concept is quite simple. Two teams, consisting of five players per team, play football under a set of predefined rules. The robots are fully autonomous, no interaction between robot and human is permitted during games (however, service and software updates may be performed between games). Thus, the robots must be able to move, track the ball, shoot, pass and most importantly communicate to succeed. The robots vary in shape and size, depending on the league. The middle-size robots have a height of approx. 80 cm with a focus on function rather than looks, while the humanoid robots must have a human-like appearance (i.e. consisting of a head, trunk, legs and arms) and must be able to walk upright and play with its feet. Being an open-source competition, all code and designs are shared between teams after the championship. The long term goal is to develop a team which is able to win against the human world champions – in 2050. Short term goals are of course to increase the knowledge in autonomous robots, vision systems etc. and (more importantly?) to have fun and increase public interest.

TechUnited Eindhoven TURTLE. Photo from TechUnited official website.

One of the keys behind TechUniteds success, according to themselves, is that they use MBD and MATLAB/Simulink to develop the robot software. This includes everything from motion and vision systems, to communication interfaces and controls. The benefits with using MBD, as always, are several, but to mention a few:

  • Being the only team that builds completely new robots each year, reusability of Simulink blocks and libraries is of course very important.
  • Modularity increases development speed, enabling students to focus on developing well tested blocks which can be incorporated in a full-scale model.
  • Code generation enables the team to make significant mid-tournament adjustments to the robot software. This is near impossible when developing the controls in C code directly, since the code is hard to maintain and harder still to test. Using Simulink, blocks are easily exchanged and the robot behaviour can be tested directly, before re-generating the code.

The humanoid platform has the added complexity of walking upright. It also provides us with an excellent opportunity to revisit the old example of failed robots. I give you: Robots vs. gravity.

For more info, have a look at the links provided above, or on TechUniteds official website (which includes all code and several scientific papers). I can also recommend Mathworks’ RoboCup website as well as the RoboCup goalkeeper webinar (which provides an excellent insight into the benefits of using Stateflow for implementing supervisory logics).

Have a great summer!