Improving real close formation flight

From FlightGear wiki
Revision as of 20:15, 23 July 2012 by Xiii (talk | contribs) (Typos, caps, and space between sections.)
Jump to navigation Jump to search

The movies

First of all, I'd like to show you what's possible to achieve in Flightgear:


diamond formation flight

F-4 training in TFFG


Next is, how was it made:

  • take a plane with a JSBsim fdm (Yasim is buggy when it comes to display plane in the future cf this bug report ;
  • setup a local fgms on another PC ;
  • fly the first plane, sending to the local fgms, and record the outgoing UDP packet from the PC running Flightgear (Wireshark software with some adapted rules) ;
  • cheat the Flightgear source code (src/AIModel/AIMultiplayer.cxx and .hxx) to make the other planes displayed in the future, using the already present prediction system (and try to smooth the rubber band phenomenon) ;
  • find the best value that matches your configuration ;
  • now start Flightgear with the second plane, start recording again the UDP packets, and play again the previously recorded packets. Now it's time to show your flying skills!
  • do this again with the number 3 and 4, and during the 4th run record the video to have a first camera view ;
  • take the UFO (the video assistant was broken for me) and do another camera view ;
  • make the movie, and voilà...


Record replay mechanism

As described above, external softs were used to record and replay the planes: Wireshark, tcprewrite and tcpreplay. Maybe there's a way to do this from Flightgear, but it was the easiest for me.

How: The outgoing UDP packets from the FG machine are recorded (FG run with an input port different from the output port), while sending to a local fgms on another PC. After some tcprewrite magic, the recorded file is ready to be sent again to fgms from the FG machine, and this time the record will include the replayed packet as well as the new FG session (which use a different input port).

After the last run, the file include the 4 planes together, ready to be sent again any time to the local fgms. Now we can play it several time to have different camera views...


Multiplayer patch

The patch used was this one. It creates two properties in each mp plane:

  • controls/compensate-lag (bool) used to make the system work, or keep the old behaviour
  • controls/player-lag: the time to change the displayed time (referenced from the received packet time) a positive value display in the future (here I used 0.12) and a negative make the display be late, allowing to be more smooth in case of jitter (for the UFO pass, it was -0.2).

I plan to have the user set the server lag for this property (or better a nasal part) , for that I need some tests with others pilots.

For Windows users, I can provide a modified binary, along with the needed DLL, if you want to have a go and test it (32 or win64 ), just get in touch... Mac or Linux users have to compile the patched version :)


How FG currently deal with MP packets

I am far from being a C++ developer, but I can understand how it works, and I can try some easy code cheat. I will try to explain what I know, but keep in mind english in not my native language :) . For now, the received MP packets are first ordered by sending time , and then FG tries to keep the MP displaying in a manner that we are always before the last packet, to have only a linear interpolation between two packets to do. (That means for a 10 packets/s speed, we display the plane at least where it was 1/10s before the last packet.. The packets of no more use are then dropped from the stack.


Lag

In the case of multiplayer flight, we see the other plane retarded by:

  • the transmission lag (travel time between the sender and the receiver )
  • the lag added by the MP displaying code (more than 0.1s)

If we want a good formation flight, we need to display the other planes in the future, in my setup, I needed to display other planes 0.12 s in the future. If you want to have a look at this lag effect, simply use 127.0.0.1 as server, then you will see your plane, together with your AI counterpart, far behind once you've got some speed. With the patch and after some fine tuning, you can have a better matching.

Example with two MP planes in refuelling action


Jitter

The records were made on a local network, so the lag was here, but the jitter was minimal. What happens when we add jitter to the UDP packet, i.e. when the time taken to travel from a player to another varies? The multiplayer code has got a basic prediction system, but it is nearly never used, if the packets are retarded, FG makes the plane "waiting in the sky" and if they suddenly regain a fast lag travel, we will see the plane accelerating. This is what is called "rubber band phenomenon" among formation flightgear pilots, the thing that makes a refuelling impossible, or break a tow in a glider session... It is possible to address this jitter, by using the sending packets time, and guessing what is due to jitter, and what is due to clock drift between the sender/receiver, but for now I lack the skills. My patch just try to make the time adjustment system more smooth, thus using more the prediction system.

A thing to consider here is to choose the same server, and one which give minimal jitter.


Existing prediction system

Just a few words about the system used to display the planes in the future. It consists of Euler steps, starting from the last packet position and using the MP plane velocity and rotation data

  • It works only without wind for Yasim aircrafts, as the speed transmitted in the UDP packet is the speed in the air mass and not in the reference frame as the JSBsim planes do.
  • It was not intended to be used intensively, we always compute from the last packet position, and that charges the CPU if we try to predict to far in the future.
  • This look OK on straight line, but the more you rotate, the more jumpy the displayed plane become, see for example the top of the cuban half figure in the second video (0'36), where this effect is clearly visible in number4 internal view. Note that all the external views were made with the UFO, with a display of the plane in the past, so no prediction system is at use.


Next step

The next step is to try this with real mutiplayers, to see what's good, and what's wrong :)


TODO list

  • Write a nasal part, to choose which planes to display in the future: on a distance base, from a "friend/wingman list, go more in the past when no direct interaction is needed (with camera/ufo, if we are just observer)
  • Try something to guess what is jitter and what is clock drift ...
  • Improve the prediction system, by using a dt approach instead of starting from last packet time at each computation
  • Find what value is needed depending on the server ping, and the frequency of packet sending to have planes concordant positions from each player point of view.