Central Computing

State Machine

Description:

This is a Finite State machine that will be running on the BeagleBone Black. Essentially it will be the heart of the pod, responding to commands and regulating what happens in each phase of the competition. A finite state machine allows for precise control over what can happen when. This is not a glorified else if or case. This is a standalone class, with extendable states, actions, and transitions. Adding a state does not result in mom's spaghetti, and is the reason we will use it.

Tasks:

• Design a C++ Finite State Machine class fsm.h and fsm.cpp

Requirments:

• States: An operating mode
• Actions: What happens inside a state. Also, what cannot happen when in a given state.
• Transitions: What the next state can be, given the current state. In terms of CS173: F(current_state, data or command) --> next_state. F is the transition function. It returns either Null (no state to transition to) or the next state to transition to given the current command or data. It should not be implemented exactly this way, but the idea is clear -- there is only a certain mapping of transitions between states.
• Clean start: #include "fsm.h" ... fsm * pod_fsm = new fsm(...); Or similar, when running from main.cpp or calling method
• Easy(ish) to extend -- can add more states, transitions without overhauling entire class
• States/actions/transitions should not be defined in main.cpp or calling method. Must be defined in fsm.h (in the form of some sort of enum, static map, or even a typedef) or fsm.cpp (inside the constructor).
• Public functions allowing:
  • Return current state as a string
  • Pass in command, respond accordingly (transition function)
  • Pass in data, respond accordingly (transition function)

Connection to XMEGAs

Tasks:

• Build SPI communication package for 2-way communication between BBB(Master) and XMEGAs(Slaves)
• Client for BBB
• Client for XMEGA (must be reusable)

###Requirements:

• Robust, disconnect recoverable protocol. (Does not hang on disconnect)
• As high of a Baud/bit rate as possible
• Expandable system, that can handle multiple XMEGAs
• Common data format, regardless if master or slave
• BBB side:
  • FIFO queue to abstract away SPI interface (Allows for BBB sensor class to easily access data)
  • Continual polling between XMEGAs.
  • FIFO queue to send commands to XMEGA
• XMEGA side:
  • Allow interface to collect sensor data atomically upon request

Rewrite Sensor Thread

Tasks:

• Mark you need to fill this in

###Requirements:

• Mark

Rewrite Server Thread

Description:

The old server.cpp and server.h enabled 2-way asynchronous communication over TCP, and surprisingly never had any problems, and was one of the most reliable parts of Pod1 software. But it is time to rewrite it, into a much neater and readable form.

Communication was facilitated with boost::asio. Boost is a great cross platform library in general, and its networking libraries are easy enough to use. boost::asio (ASync I/O) works great for non-blocking TCP. Some teams have created their own network protocol and implemented that to allow for a speed advantage, since ideally you have a protocol between UDP and TCP. But TCP is solid, already implemented for us, Boost supports it, LabVIEW supports it, and its fast enough.

Tasks:

• Create two separate classes: server.h and connection.h, and their corresponding implementations. Server handles the connections, Connections handle the data flow.

Requirements:

• Should work as reliably as old server
• Designed to run in its own thread, to decrease wasted time on blocking I/O (Since even with asynchronous design, there is time wasted waiting)

Create system to log data

Description:

Storing all of the sensor data and actions taken is critical when something goes wrong and we need to see what happened. All incoming data is stored in LabVIEW already, but in case of network disconnect it needs to be stored locally on the BBB.

Tasks:

• Create a logging system that allows input of sensor data, and active commands. What should be written to the file is everything the BBB sees and does.

Create simulation suite

Tasks:

• Mark needs to fill this in

Measure Network use

Tasks:

• Once server and sensors are implemented, measure how much data is actually being transferred (not just plain text, but TCP protocol too) over the network. Must be less than 5 megabits/second, to satisfy SpaceX requirements.

Measure Control latency

Tasks:

• Once Server and fsm are implemented, measure how long it takes a command sent from LabVIEW to affect change (actuating brakes, changing states, ect...)