[Network] Create UDP packet based on SpaceX requirements

[rgw3d]

Check out page 13-16 of the SpaceX Rules and Requirements Document

You can download full document here on the wiki:
https://wiki.illinois.edu/wiki/pages/viewpage.action?pageId=679060314

SpaceX Pod Monitoring Telemetry
Teams shall send a binary telemetry frame to a SpaceX computer for displaying live Pod
information during the competition. The frame shall be sent via UDP to 192.168.0.1 port 3000 at no
greater than 50Hz and no slower than 10Hz. The packet must obey the following format, where the
type uintx is and unsigned integer of x bits in length and intx is a two's complement signed integer
of x bits in length.
The following fields are mandatory:

1. team_id
2. status
3. acceleration
4. position
5. velocity
   To stay compatible with the display system of previous years, the packet format has not changed;
   however, this year SpaceX is not planning to use any of the non-mandatory field values. All non-
   mandatory field values should be 0.

team_id | UINT8 | Identifier for the team,assigned by SpaceX
status    |  UINT8 | Pod status enumerationdefined below
acceleration |  INT32 |  Pod acceleration estimation in centimeters per second squared
position        | INT32  |  Pod position estimation in centimeters from starting position
velocity        | INT32  |   Pod velocity estimation in centimeters per second
battery_voltage | INT32 | Battery voltage in millivolts.
battery_current | INT32 | Battery current in milliamps.
battery_temperature | INT32 | Battery temperature in tenths of a degree Celsius.
pod_temperature     | INT32  | Pod temperature in tenths of a degree Celsius.
stripe_count |  UINT32 |   Count of optical navigation stripes detected in the tube.

Table 2 – Telemetry frame format
All multi-byte segments of the frame are expected to be received as big-endian values (also
known as network order).
The total length of the payload of the packet is 34 bytes. Frames with the wrong payload length will
be ignored by SpaceX software.
The Pod status field communicates the state of the Pod to SpaceX and the public and contains the
following states:
• 0: Fault – When the Pod is in any fault state.
• 1: Safe to Approach – Any state where the Pod is on, not moving and safe for team
members and SpaceX volunteers to approach. The Pod should go back to transmitting this
state at the end of the run.
• 2: Ready to Launch – Any state where the Pod is ready to launch but not accelerating.
• 3: Launching – Any state where the Pod is commanding propulsion with the goal of
achieving the highest velocity for the run.
• 4: Coasting – Any state where the Pod is moving but not accelerating or decelerating.
• 5: Braking – Any state where the Pod is decelerating using its braking mechanism, a Pod
can stay in this state after having come to a full stop but should eventually go to Safe to
approach.
• 6: Crawling – Any state where the Pod is commanding propulsion with the goal of moving
the Pod while not achieving the highest velocity for the run.
The actual Pod state machine is allowed to contain different states that are mapped to these
states. The coasting and crawling states are optional, since they are dependent on Pod design. All
other states must be sent out from the Pod.
This system is separate from team telemetry for controlling the Pod and the Pod health check.
Teams are allowed to send these frames from the team laptop that receives Pod telemetry.
However, if transmitting from the team laptop and there is a loss of communication with the Pod,
the team laptop must also stop sending frames to the SpaceX server.

[schmidtwmark]

This (and all the other UDP stuff) should probably be separate from the NetworkManager interface. It might be worthwhile to rename NetworkManager to avoid confusion.

[rgw3d]

This will be done on the base station side of things to ease the load off of the BBB