How I tried to understand the FixedUpdate() method...

Information below are not from my head - I have collected and copypasted them from several sources. The reason I put it on a single place was that I simply need to understand FixedUpdate() method on my own, which I am doing by coding, testing and blogging about it at the same time.

Unity documentation says that the FixedUpdate() method is called at regular interval, while Update() function is called as many times as possible, so we say it is called every frame, see there. Having a fixed interval is pretty useful, because of physics: E.g. if we add a force every Update() instead of FixedUpdate(), the game would run differently depending on the frame-rate.

Now, if you have call like the one below:

  void FixedUpdate ()
  {
    Debug.Log("FixedUpdate time :" + Time.deltaTime);
  }

You will notice in the console window that the deltaTime property, which returns in seconds time it took to complete the last frame, will return always the same fixed time. This is little misleading - Unity detects if the current call to Time.deltaTime is originated during FixedUpdate() call and returns Time.fixedDeltaTime value instead.

As mentioned here, calling something in regular intervals is not possible because of different devices performance. The solutions is that if FixedUpdate() hasn't been getting called often enough to average out to the correct interval between calls, it gets called multiple times (or isn't called if the frme rate is too high).

It is mentioned aslo in the Unity documentation: "FixedUpdate is often called more frequently than Update. It can be called multiple times per frame, if the frame rate is low and it may not be called between frames at all if the frame rate is high."

In pseudo code I think the game loop is something like the one below. The physicsTime  is a virtual time, which si increased by adding physicsStep fixed value every time all FixedUpdate() method on all game objects are called. If we e.g. set the physicsStep to 0.02 and in the while loop is the difference between virtual time and real time (Time.time - physicsTime) is 0.07, because of e.g. low hardware performance during the scene rendering, the FixedUpdate() will be called 5 times in a row before next Update() call will be executed:

  while (1)
  {
     while ( physicsTime < Time.time )
     {
         CallOnAllGameObjectsFixedUpdate();
         physicsTime += physicsStep;

     }
 
     CallOnAllGameObjectsUpdate();
  }

In other words, first the appropriate number of physics steps are executed in order to "catch up" with the real time (and each step, FixedUpdate() is called on each object which implements it). Next, the graphics for the frame are rendered, followed by Update() on each object which implements it.

So, it is not true that FixedUpdate() is called in regular interval, but it is guaranteed that the same (almost) number of  FixedUpdate() calls will be executed every second.

See another nice explanation:
Let's set the physics timescale is 0.02, which this gives us 50 physics updates per second. If our game were running nice and fast at 100fps, we'd have two frame renders for every physics step - and therefore two calls to our Update() functions, for every call to our FixedUpdate() functions. (Key: "F" for FixedUpdate and "U" for Update)

0                                                0.1
|                                                 |
.____.____.____.____.____.____.____.____.____.____.___ 
F         F         F         F         F         F
U    U    U    U    U    U    U    U    U    U    U

If our game is running slower, say - at 30 frames per second (and therefore 30 calls to all Update() functions per second), it would mean that we actually sometimes have more than one physics step between each frame render. In the case of 30 fps, the result would be that sometimes two physics steps are executed between frames, and sometimes one, which would look something like this, for the first 10th of a second:

0                                                0.1
|                                                 |
.____.____.____.____.____.____.____.____.____.____.___ 

F         F         F         F         F         F
U                U               U                U

So, in most normal circumstances, you'll always get the desired number of physics steps per frame, and interleaved with these will be the visual frame updates, at as fast a rate as possible.