Category: Uncategorized

Final Report: Project Belka

We believe that most of our original project can be maintained, since the crux of the project is software that will be loaded onto CubeRover’s modules.  Since we can no longer simulate the protocols using physical components, we intend to simulate the protocols. Because the hardware aspect is no longer feasible, we plan on re-focusing our project to create, implement and test various error detection and correction algorithms to determine which methods best meet CubeRover’s specifications and hardware specifications.  Creating these various error detection and correction protocols are the priority; a stretch goal would be creating the GUI to make our error detection and correction simulations more presentable.

Error Detecting and Correcting Algorithms that we will be creating and testing:

Currently, we’ve decided to start looking into and implementing Forward Error Correction Codes, LDPC Codes, and Turbo Codes; a reach goal is researching and implementing other error correction and detection methods.

Current State:

Right now, we are finished writing and verifying the correctness of the initial error correction and detection methods that we decided on implementing (reflected in our most recent Gantt Chart created before spring break).  Our current implementations, however, are designed to send data to the microcontrollers; we will therefore spend a few days modifying our current implementations to be simulated and verified using test benches. 

Old vs. New Phases:

We have updated our previous phase plans to reflect the changes that we have made to the project; instead of verifying the accuracy of the data being passed to and from the microcontroller, we will instead shift to writing more algorithms to determine which error detection and correction implementations best fit the requirements of the project.

New Tasks + Splitting New Tasks Between Team Members:

ProjectBelkaDesignDocument

When approaching this design I wanted initially to implement a full TCP protocol using UDP packets. This would essentially work by using the body of the UDP packets to store the information needed for the TCP protocol. This would provide a way to retrieve lost packets. I settled on the packet design below:

Packet Design

Protocol Design

While this data exchange looks to be the exact same at a standard TCP protocol, the key is that it will be performed using UDP packets. Doing this parts of the design will have to be limited as we will not have to deal with cases where we have to do intense tasks such as streaming video.

We have partitioned our API into two parts of control and status. Since our current plan is to implement our GUI and Microcontroller to run micro-python, the API examples will be in Python3.

Control from GUI:

We are defining two different ways to control from the GUI, either by bits or by packets. API sketch below:

Status from MCU:

We are sending status to the computer only in one command, which is sendStatus. API sketch below:

In the previous posts, we discussed the progress of our API design.  With this design, we have began researching the best ways to implement transactions between the MCU and GUI using either the USB or USART/UART port on the STM32 Microcontroller connected to the computed to display on the GUI.  So far, we have decided that the computer will receive and send data from the MCU connect the via the USART port on the MCU because:

1. The USART port can send data via bytes serially.  With the current rough draft of our API design, the protocols on each component will be determining what error codes to send to the GUI.  These error codes will be given to the MCU, which will send it to the GUI via the USART port.
2. The USART port can transmit data via bytes serially; by sending bytes serially, we can enumerate and send control signals to the MCU that will indicate what type of error we would like to simulate.
3. If we do implement combinations of errors, we could enumerate the combinations of errors into error and control signals, allowing for us to simultaneously test the detecting of multiple errors.

Currently, we are deciding between implementing this in C or microPython.  Using C, it would be less of a learning curve and would be able to integrate better with our programs that we are already writing in C.  However, using microPython would be less difficult given the various built-in libraries and would allow for us to integrate easily with external C programs that we could write if the built-in functions are insufficient.  Furthermore, microPython offers libraries custom to STM32. We feel that deciding whether to use C or microPython will depend on what will integrate best with the remaining aspects of our design that still need to be determined.

To-Do:

1. Research more into microPython and C implementations of USART and determine which one will fit best with our design.
2. Determine how the remaining components like the communication between MCU to I2C, SPI etc. will be implemented

We have begun our hierarchical design between the GUI and MCU and between the MCU and each component. This is shown below:

Our GUI is designed such that it serves as our control center on how we would like to manipulate data and we want this manipulation to be real-time. Our desire is to have a clear divide of GUI and MCU through our defined API. The GUI will only be able to send control signals on how data should be manipulated and the MCU should only be able to send status signals on successful recovery/successful protocol calls. We imagine both the GUI and MCU to deal with concurrency with two threads running simultaneously, one for sending and one for receiving data. Our MCU will likely have at least four threads running in addition to handle the cases of each protocol concurrently. The reporting back to the GUI will be in serial transmission, so we’ve decided to place a protocol status buffer within the MCU which will hold the success of each call made.

Our initial API design is here:

Below is an example of how the microcontroller would interact with one of our components:

We have placed the responsibility of packet generation on our microcontroller for now. We’ve decided that this is an simpler framework that allows for easier unit testing of each error correction/detection wrapper protocol. At the end of the project the goal is to remove the microcontroller entirely and still have the protocols working as suspected. The microcontroller will predetermine what the response from the client component should be and add to the protocol status buffer the result of whether the responses matched.