You are not Logged In!

Difference between revisions of "Public:GitHub/Telemetry"

From Illini Solar Car Wiki
Jump to navigation Jump to search
(Created page with "hi")
 
(Moved from Github main page)
Line 1: Line 1:
hi
+
{{OutOfDateNotice|reason=Need more info about each repo and pages per repo}}
 +
 
 +
The [[Strategy and Telemetry|strategy and telemetry group]] currently has 3 repositories: Telemetry, data-analysis, and Athena-v2.
 +
 
 +
Information about these repositories and their setups can be found in the README.md files in each repository.
 +
 
 +
clone the repository using <code>git clone --recursive <repo></code>  and <code>git clone <repo></code>  for the other two.
 +
 
 +
The <code>--recursive</code> option looks for submodules in the repo and clones them into the correct directory. If this option was omitted during the initial clone, run the command <code>git submodule update --init</code> to find any un-cloned submodules and clone them. This only applies to the Telemetry repo that contains the CAN submodule with the CAN messages for the car.
 +
 
 +
=== About Repos ===
 +
The Telemetry repo primarily holds the code for the [[telemetry]] [[Server and Database Documentation for the Telemetry Application|application]], the app that allows us to view and analyze car data in real time to diagnose issues and make informed decisions.
 +
 
 +
The data-analysis repo hold code used to analyze datalogger race data after the races to better understand the car and its performance.
 +
 
 +
The [[Athena Version 2|Athena-v2]] repo has code that is currently an in-progress project currently delayed until more man and woman power is available to code. The project is a car simulation and optimizer to determine optimal strategy decisions in a calculated and methodical way.
 +
 
 +
=== Workflow ===
 +
The workflow of branches and commits should be similar to how the FW repo works. All work should be done in separate branches if multiple people are working on one feature, they should each have their own branches and merge them together when possible. Branches should not be merged into master until they are known to work without breaking the system.
 +
 
 +
To merge a branch in to master a pull request should be made and at least two reviewers should be requested. Once these reviewers have approved the pull request can be merged into master.
 +
 
 +
If changes need to be made quickly and shared and there is not time to follow the review process (for example during a race) a separate branch of master should be made for this. The changes should then be reviewed and cleaned when there is time and then the standard merging procedure should be followed to pull the changes into master.
 +
[[Category:Stub]]

Revision as of 22:00, 29 September 2020

InfoIcon.png Out of Date
Content on this page may be out of date. Please verify with a group lead. If you are knowledgeable of the content, please update it or remove this label if it is here in error.
Reason: Need more info about each repo and pages per repo


The strategy and telemetry group currently has 3 repositories: Telemetry, data-analysis, and Athena-v2.

Information about these repositories and their setups can be found in the README.md files in each repository.

clone the repository using git clone --recursive <repo> and git clone <repo> for the other two.

The --recursive option looks for submodules in the repo and clones them into the correct directory. If this option was omitted during the initial clone, run the command git submodule update --init to find any un-cloned submodules and clone them. This only applies to the Telemetry repo that contains the CAN submodule with the CAN messages for the car.

About Repos

The Telemetry repo primarily holds the code for the telemetry application, the app that allows us to view and analyze car data in real time to diagnose issues and make informed decisions.

The data-analysis repo hold code used to analyze datalogger race data after the races to better understand the car and its performance.

The Athena-v2 repo has code that is currently an in-progress project currently delayed until more man and woman power is available to code. The project is a car simulation and optimizer to determine optimal strategy decisions in a calculated and methodical way.

Workflow

The workflow of branches and commits should be similar to how the FW repo works. All work should be done in separate branches if multiple people are working on one feature, they should each have their own branches and merge them together when possible. Branches should not be merged into master until they are known to work without breaking the system.

To merge a branch in to master a pull request should be made and at least two reviewers should be requested. Once these reviewers have approved the pull request can be merged into master.

If changes need to be made quickly and shared and there is not time to follow the review process (for example during a race) a separate branch of master should be made for this. The changes should then be reviewed and cleaned when there is time and then the standard merging procedure should be followed to pull the changes into master.