The server program acts as the middle man between the vehicle hardware and the rest of the software. Anything related to the position, speed, heading, or any other vehicle related information is stored in the server. A client can connect to the server over TCP/IP and retrieve this information and then give commands to the vehicle through the server. Another key function of the server is to read in data from our wireless joystick to control the movement of the vehicle. This means that in order to drive the vehicle with the wireless joystick, the server must be running.

The idea behind the server program is to provide a layer of abstraction between any vehicle and any software. The sever has generic messages you can pass to it (to get information or control the vehicle). The server can then interface to the GPS, compass, encoders, and vehicle anyway it wants to achieve the message. This allows the same client program to work on any vehicle as long as it has a server that implements the same messages. For example, let's say the generic server interface has a message "STOP." The server can implement this anyway it wants as long as the end result is that the vehicle stops. If we have one server on wheelchair and a similar one on a car, a client can connect to either one and give the "STOP" command, not caring what vehicle it is sending the command to. This makes writing a path planner easier because it just has to worry about figuring out where to go and then telling the server where to go without caring what vehicle it is running on.

The server is also a good debugging tool as it displays all the sensor information on a GUI. With one quick glance, you can check if a sensor is working and is outputting the right information.