How GitHub may be used with Innoslate to modify and store live code repositories.
1 Use GitHub Integrated in Innoslate
The GitHub integration in Innoslate provides an interface to exchange information between various users in an Innoslate project. Three actions can be performed to conduct the exchange of information between the two tools. These actions are Issues, Commits, and Pull Requests.
Issues are used to track work in GitHub. They can help the user organize and prioritize work that needs to be done within the current project. Issues can be differentiated using labels, assignees, and milestone relationships.
Commits are the history of a repository throughout development during the project. Commits tell a story through the progression of each repository in a project. Commits can be differentiated using assignees and timestamps.
Once a repository has been branched or forked, Pull Requests can be used to update and track its development in a project. The Pull Request is the final touch to tracing any Commits to their related Issues.
1.1 Login to GitHub View
A GitHub account along with a specialized token is required at login to access the GitHub View integrated with Innoslate.
When the unique token is used to access the GitHub View, any repositories and files attached to that token are opened and listed in the GitHub View dashboard. The figure below is a screenshot of the GitHub View maintained for the Lunar Rover Project.
There are four code repositories listed for the GitHub View in the Lunar Rover Project. Key features such as programming language, license, and date the repository was last updated are listed for each repository in the GitHub Dashboard.
1.2 View the Repository Dashboard
Each repository also has its own dashboard to display recent activity and a list of the information exchanged between GitHub and Innoslate. The figure below is a screenshot of the SPECTER Firmware repository in the Lunar Rover Project.
The Innoslate Repository dashboard has widgets to display the following information:
• Number of active Pull Requests
• Number of active Issues
• Recently opened Issues
• Rate of Commits made per week
• Recent Commits
1.2.1 Create GitHub Issues
GitHub Issues can be created in each Innoslate repository by navigating to the ‘Issues’ tab on the left side panel. When creating a GitHub Issue the following metadata is encouraged to differentiate the Issues: name, description, assignee, and labels. The figure below is a screenshot of the Issue Creation prompt.
Once created, the GitHub Issue is stored in Innoslate and cloned to GitHub.
1.2.2 Create GitHub Commits
Each GitHub Commit in Innoslate is a clone of the Commit found in GitHub. Commits can be easily understood as edits made within a file or code in the repository. Metadata that can be added to the Issue in Innoslate includes a description and assignee. Use this information to track the progress made in the repository. Below is a list of the Commits made to the SPECTER User Interface repository.
1.2.3 Create GitHub Pull Requests
GitHub Pull Requests are the final submission of an Issue. Each Pull Request is also a clone from GitHub. Innoslate notifies the user of each Pull Request to allow them to check the GitHub platform for the changes to be approved. Within GitHub, the user can view all the Commits and Issues related to the Pull Request.
If more information is required for the Pull Request, then comments can be added directly in Innoslate. Comments can be used to clarify any confusion in the Pull Request for provided feedback for the assignee or reviewer.
2 Use GitHub Repositories
The two LEO Rover GitHub repositories for developing the prototype’s firmware and user interface were cloned by the SPEC team to be modified for this Lunar Rover Project. The LEO Rover’s firmware sends messages to components in the prototype using the connection between the processor and the component that performs the specified function. The user interface is used by operators to view and create commands for controlling the rover’s actions and receiving diagnostics from the prototype’s hardware.
These two cloned repositories for the rover prototype are stored in Innoslate’s GitHub View, and they hold all the code to develop SPECTER’s firmware and user interface. LEO Rover’s default settings were kept for the firmware and user interface.
2.1 Modify the Firmware Repository
To gather data using SPECTER’s lidar, modifications were made to the firmware for recording the distance obstacles from the rover body as well as ambient temperatures. This information is used to provide data and diagnostics of the rover’s surrounding area. The following sections step through creating Issues and submitting changes to develop an interface for streaming the above metrics directly to the rover operator.
2.1.1 Assign the Lidar to the Processing Port
First, an Issue was created to alert SPEC’s software team of the new feature to be added to the user interface: including the lidar sensor in SPECTER’s robot operating system (ROS). The figure below is a screenshot of this Issue.
Once the Issue was published and cloned to the GitHub platform, it was assigned a SPEC software team member for the feature creation. Edits to the code were made in GitHub and submitted as Commits. These Commits exchanged the information from GitHub to Innoslate for publishing.
Once the Commit was made to allow SPECTER to communicate and send messages via the firmware, a reviewer from the SPEC software team examined the code written to verify it was ready for publishing. After reviewing the Commit, it was decided the code needed continuing edits and would not be published yet. The figure below displays the reviewer’s comment made to disapprove the Commit.
The original writer reviewed the reviewer’s comments and continued editing the code to meet SPEC Innovation’s software standards. These edits were also submitted as Commits. The figure below highlights the changes made.
Once the code updates were complete, the reviewer read the new Commits and determined the code to be ready for publishing. The Commits were then submitted as a Pull Request, and the Issue was closed. The figure below is the final comment resolving the Issue.
2.1.2 Transmit Temperature Data
An Issue was also created for developing an ambient temperature recording to be outputted from the Lidar sensor and displayed in the user interface. The figure below shows this GitHub Issue.
Once the Issue was published and cloned to the GitHub platform, it was assigned to a SPEC software team member to be addressed. Any edits to the code were made on the GitHub platform and submitted as a Commits to be exchanged with Innoslate. After the Commits were reviewed and approved, the edits were summited as a Pull Request, and the Issue was closed.
2.1.3 Transmit Distance Data
A final Issue was created for developing an output of distance data from the Lidar sensor to create an obstacle avoidance warning on the user interface. The figure below is a screenshot of the Issue created for this feature.
The same processes as mentioned with the other two Issues were followed. However, the reviewer noticed the units used for distance parameters were incorrect and needed to be converted to meters. The figure below displays this comment made by the reviewer.
Once the SPEC software team member made the edits and pushed the Commit, the Pull Request was submitted, and the Issue was closed.
2.2 Modify the User Interface Repository
SPECTER’s user interface allows the operator to view messages received from the prototype’s processor. These messages and interface features include:
• Ambient temperature recording
• Distance to obstacles from rover body’s front and rear display
• Warning signal if a certain distance is reached to an obstacle
The user interface features provide diagnostic feedback to alert the operator of the rover’s surrounding environment.
2.2.1 Display Lidar Data
An Issue was created to develop a display for the Lidar messages on the SPECTER’s UI.
Once the Issue was published and cloned to the GitHub platform, it was assigned to a SPEC software team member to be addressed. Edits to the code were made in GitHub and then submitted as a Commits to be published on Innoslate. The figure below displays a list of the Commits made in GitHub to create lidar message displays on the user interface.
Another SPEC software team member reviewed the Commits and decided the Lidar information needed to be parsed into two categories: Distance of Upcoming Obstacles and Ambient Temperature. The reviewer also recommended adding SPEC’s logo to the user interface. The figures below display the comments made by the reviewer on the Commits.
Once the code was updated and the changes were approved by the reviewer, the Commits were submitted as a Pull Request, and the Issue was closed.
2.2.2 Display Obstacle Warning Messages
Lastly, an Issue was also created to develop a warning alert display on the rover’s UI for when SPECTER’s body approaches an obstacle too closely. The figure below displays this Issue.
Once the Issue was published and cloned to the GitHub platform, it was assigned to a SPEC software team member to be addressed. Any edits to the code were made in GitHub and then submitted as a Commits to be published on Innoslate. The figure below displays a list of the Commits made in GitHub to create warning message displays on the user interface.
Once the code was updated and the changes approved by the reviewer, the Commits were submitted as a Pull Request, and the Issue was closed.
