This post looks at synchronising push swings, by the participants controlling the force that they apply at the top of the swing.

**Metronome synchronising example**

Before jumping in to the push swing example, I found it useful to look at some similar examples. Synchronising metronomes is a well known synchronisation example as in this video here:

Veritasium: The Surprising Secret of Synchronisation starting at 295s

This introduces the idea that a small force can be used to synchronise systems, that the phase of the subsystems is important, and the Kuramoto Model used to describe synchronisation.

The Kuramoto Model is:

Figure 1. The Kuramoto Model, is a mathematical model used to describe synchronisation. Image from wiki/Kuramoto_model

And a paper on the topic can be found here:

The rhythm of coupled metronome

**A push swing model **

For the push swing example a number of participants are self propelling themselves on swings, pushing at the apex of the swings, with the aim of synchronising the swings.

A simple model of a push swing was created of this in Figure 2.

Figure 2. Simple push swing model. Icon for controller taken from vector.me

The basic swing model consists of a rigid bar connecting the top pivot to the centre of mass of the participant. The controller introduces a push at the apex of the swing. Currently the controller is implemented, so that it only performs the push at one of the apexes of the swing and not at both apexes.

The magnitude of the push is controlled by the controlInput signal; if the controlInput is -1 then the force applied to the swing is 0; if the controlInput is 1 then the control input is the maximum force.

The details of the controller are not provided in this post as the focus of this post is how synchronisation can be performed.

The swing model is simulated and the phase diagram is generated using the UserInteraction.Outputs.DynamicTrace block as shown in the following video.

Video 1. Animation of the swing model with the plot of the angular velocity versus the angle

The plot of the angular velocity versus the angle of the swing is useful for determining the phase of the swing as this is the property that the participants want to synchronise.

**Swinging together**

By pushing the swing harder the time for one oscillation increases, and by pushing less the time decreases. This small difference in the period is enough to be able to control the swings into synchrony.

There are many different control strategies that could be tried and if the Kuramato model were to be followed, the control input would be calculated as the second term of the Kuramato model that is:

However this seems a bit complex for the participants to be able to calculate, so a simpler method is proposed.

If the participants calculate how far they are from the average position of the swings and use this to determine if they should push more or less, it may be possible to synchronise the swings.

**The synchronising swing example**

Figure 3 is a model of multiple swings being controlled to synchronisation.

Figure 3. Model use to synchronise a number of push swings. The icon used for the push swing model is from vector.me

The icon of the push swing in Figure 3 represents the push swing model in Figure 2 for which the outputs are the angle and the angular velocity of the pivot of the swing.

The phase of the swings are determined by calculating the polar coordinate angle using the **toPolar** component vector. This phase angle gives an indication of where in the oscillation a swing is.

Swings coming towards the participant can be seen as swings that are behind, and swings that are going away from the participant are swings that are in front. So negating the swing angle before calculating the polar coordinates, results in the swing being pushed at 180 degrees. Swings behind this swing would have angles of less than 180 degrees and swings in front would have an angle more than 180 degrees.

These polar angles are then scaled to be a number between -1 and 1 to simplify the control process.

The average of the scaled oscillatory angles is calculated using the **totalSum** and **averageGain **components.

The relative position of each swing from the average is calculated using the **feedback** component vector. This relative position is in the range -1 to 1.

**Simulation of the model**

The model of the swings system is simulated and the animation is in video 2.

Video 2. Swings being controlled to synchronisation

The swings are all started with a pseudo random phi angle (determined using a Lehmer random number generator) and with zero angular velocity. Then over time they are controlled into synchronisation.

**Discussion**

The swings are controlled into synchronisation using the simple control method. Note that there is no proof that this method will drive all swings configurations to synchronisation. It is also seen that swings suffer from “chasing”, for example if swing A determines that they are far ahead of swing B it pushes hard, however when swing B gets to be pushed it can be far ahead of swing A and pushes hard; this may lead to the swings synchronising 180 degrees out of phase.

The method described would be difficult for the participants to implement as it is difficult to calculate the average of all the swing phase angles. A simpler control method was also used where a participant controls their swing based on the average of the phase angle of the neighbouring swings. This works although it takes about twice as long to synchronise the swings.

The swing model used is not very realistic and so should be refined; also it would be good to do the practical experiment.

If you would like to experiment with this swing model, you can access the code **here**.

**Written by: Garron Fish – Chief Engineer**

**Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion**