Hello.
I have a problem in one of my practical works to the university.
This work is on Erlang and I have to build an Airplane Traffic and Collision Avoidance System.
My problem is: how can a simulate an airplane trajectory, taking into account the velocity? I thought of using a process...
Does anyone have some idea?
Best reguards.
Perhaps a set of processes each representing a plane. Have a "Radar Ping" event they respond to that returns current course, heading, speed, and location. Program your logic from there.
I'm probably oversimplifying what they need to do but you get the idea. A process would definitely be one way to do this.
The other option is just to maintain an AST of all the planes. Without knowing more detail about what your project has to do exactly it's hard to give much more information.
Does anything have to be realtime? If not, really, it's just some simple velocity calculations you can do in a gen_server or gen_event process. Just spawn a supervisor to spawn gen_server children for each plane, and then when time elapses, do a handle_call for each airplane and have them update their information.
My problem is: how can a simulate an airplane trajectory, taking into account the velocity? I thought of using a process...
Sounds like basic physics in 3d coordinates to me. If you know the orientation of the plane then you can calculate the new position (let's say in 1 second from now) of the plane by calculating the distance from the velocity. After you got the distance you then need to calculate the new coordinate of the plane knowing the orientation and the distance.
Usually these kind of simulations run a virtual "clock" and recalculate the positions of all aircraft by incrementing the (virtual) time tick by tick (e.g. one second or one minute per tick). By connecting the "dots" of the position calculations you get a trajectory.
You might be interested in this paper (see page 21) about buidling simulations in Erlang. It proposes a solution with a world process plus one process for each active entity.
You haven't really provided very much detail about the full scope of your project, but it seems to me you might want to look into aviation related open source projects, such as for example flight simulators, in order to see how they're doing this sort of thing, and possibly even in order to see how these could be leveraged to simplify your effort.
FlightGear for example provides support for AI traffic nodes, as well as multiple clients connected in a multiplayer-like fashion. Referring to the earlier concept of using a parent process as the 'world' process and having any number of client processes emulating aircraft, the multiplayer server would be the world process.
So, in your specific case, the AI traffic component in FlightGear looks particularly relevant, because it shows you how 4D trajectories are computed and provided to other clients. Basically, in FlightGear this is using a central server called fgms (FlightGear Multiplayer Server), which basically dispatches the lat/lon, altitude (including velocities and orientation) to other clients.
Assuming that your effort's scope is related to computing TCAS like trajectories using groundbased radar data, you could simply interface your code to their open source multiplayer server, and then poll/query the server for positional updates, thereby emulating radar interrogations.
In fact, just having looked at their server code, it seems there's yet another way of doing it: the fgms code supports the concept of relay servers, where all client data is automatically mirrored onto another server, so your radar system could also be implemented as a listener to that server and pretend to be a mirror/relay server, so that it can process all traffic without having to explicitly poll the server. This seems to be a better approach than what I suggested previously, because that way you'll be automatically provided with positional updates without having to do any processing yourself (looking at the network protocol, it seems that the packets are just XDR encoded PODs).
So, assuming that you need to concentrate on the radar system, you could simply 1) download their multiplayer server, 2) build it, 3) set up your erlang system as a relay server, 4) run the server and 5) process all updates and build a 3D radar image of the corresponding airspace.
If you want to keep it simple in the beginning, you could similarly just run a couple of instances of the flight simulator while connecting it to your local multiplayer server, so that whatever you do in the flight simulator, will be propagated to your radar system.
Leveraging components of existing projects seems to be a pretty promising approach: depending on your project's scope, you might even be able to simply connect your erlang code to FlightGear (or rather its multiplayer server), so that you can directly concentrate on the most relevant work in your effort (assuming that is the TCAS calculations)
Also, if you have the need to inject arbitrary traffic into your airspace, their multiplayer server is straightforward enough to create pretty much arbitrary traffic.
The previously mentioned AI traffic system in FlightGear provides support for creation of virtual flight plans to route the AI traffic, aircraft performance characteristics can also be customized by editing an XML file.
Note that their current implementation of the multiplayer server is really very simple and basically boils down to a packet multiplexer, that simply forwards data from each client to all other clients (see this for more details).
The server's source code is pretty much self-contained and doesn't have any non-trivial dependencies, at the moment it only compiles on nix platforms, though (if you are running Windows you may want to check out cygwin or colinux to get to run their server).
Note however that the server component is generally considered unmaintained at the moment, in other words it hasn't really been updated in 3 years. On the other hand, the code itself has been in regular use for a number of years now. So the status of being unmaintained at the moment, doesn't really say anything about the code itself or its usability, it really only affects.
So while there are a number of planned changes for fgms (such as adding DIS support), noone is actively working on the server, and it is just being used as is, among those planned features, is one that seems relevant to your effort:
Protocol to publish multiple aircraft/vehicles from one client SF.net
Interestingly, there has previously been a discussion about possibly porting their fgms component to be implemented in erlang instead of in C++, so if you find that you need to enhance or re-implement the server code using erlang, your contribution might actually be very much appreciated, especially due to their own server being basically unmaintained at the moment.
Should you decide to take a look at using FlightGear for some of your project, you'll probably want to subscribe to the FlightGear developer's mailing list.
In order to come up with aircraft performance data, you may want to check out this aircraft performance database.
Also, you might want to have a look into this FlightGear related discussion which provides various other links concerning the computation of aircraft performance in general, and 4D trajectory prediction in particular.
In particular, the EuroControl BADA project seems possibly interesting.
Even if you should eventually find that your project's scope differs too much from a conventional flight simulator, using an open source flight simulator such as FlightGear might still help you visualizing your project in a very nice fashion, i.e. by actually examining traffic conflicts in a realtime fashion, inside a virtual 3D world.