Skip to content

NadmanFaisal/Visual_Navigation_System

Repository files navigation

2025-group-07

Project Status

Setup

This will walk you through a guide on the tools you need as well as how to clone, build and run the project

Tools to use

Cloning the Project

Before building the project, please clone the project using your SSH key. To clone this repository, open a new folder and navigate it through your command line and write in your command line:-

git clone git@git.chalmers.se:courses/dit638/students/2025-group-07.git

Building the project

After you have cloned the project, you can build it in two ways:-

Local Build

To build the project locally, please navigate to the build file using your terminal and write:

cd build

Then remove previous builds files in the build folder using:

rm -f -r * 

Warning

Ensure you are in the build file when writing this command since it deletes all files within the folder.

Finally, create the build files and run the project using:

cmake ..
make
make test

You have built the program, to run it you can type:

./helloworld 23

Then it will output:

Last Name, First Name; 23 is a prime number? 1

That's it, you have built and ran the program through a docker container!

Dockerized Build

Important

To start, remove the build folder you have in your project to ensure no issues arise when Docker tries to make their own build folder.

To build the project in a docker container, start a terminal and navigate to the source folder then run:

docker build -t 2025-group-07/example:latest -f Dockerfile .

If the build was created successfully, run:

docker run --rm 2025-group-07/example:latest 42

That's it, you have built and ran the program through a docker container!

Project Workflow

As a group working on this project, we set standards and steps while working to minimize errors, reduce time waste and deliver a product that meets the expectation of this course.

Git Workflow

To follow a seamless Git process, we ensure that every member uses this concept when developing a feature:-

Feature Branching: Branches are to be made according to atomic features.

Code Review: Code review is done by someone who has not contributed to the branch at all. In the case that everyone in the group has contributed to the branch, the person with the least merge reviews will be posted as the reviewer.

The reviewer must ensure that the functionality of the newly added feature is functioning as well as not breaking any other features of the system. If otherwise, the review will leave a review stating where the bug occurred in what line/ in what code module or features that it has broken, so that the Assignee can fix the occurred bug.

Branch Merges: Branches are created from the main, and merged to main. In the case that a branch (branch-2) has been made from another branch (branch-1), then branch-2 should be merged to branch-1, then branch-1 will be merged to main. Branches that are being merged to main must follow the “Code Review” convention stated above.

Bug Fixes: Bugs found after merging to main will be fixed by creating a bug-branch, which follows the convention of “Branch merges” as above.

Git Commits: The commits must contain atomic implementation and not simple code line fixes unless it's a bug fix branch. (need language restructure). The implementation name’s first word must be imperative and kept short to a single sentence. Any further explanation should go to the body of the commit by using -m. For example, if you co-authored a user or explanation to a commit.

Git Commit Structure

“#<issue num> implementation_name”

“#<issue num> implementation_name -m “Co-author: @author””

Examples:-

git commit -m “#01 implemented car steering method”

git commit -m “#01 implemented car steering method” -m “Co-author: @cid, @cid”

Process & Team Management

Adding New Feature: New implementations are added through initiating a new issue and having a separate branch for it. Developers will be assigned to work on it, based on their learning and interest.

Fixing unexpected behaviours in existing features: Unexpected behaviours in existing features shall follow the same concept as described in the “Bug fixes” convention stated in the Git Workflow section.

License

The team has chosen to use the MIT license. Reason to choose: A short and simple permissive license with conditions only requiring preservation of copyright and license notices. Licensed works, modifications, and larger works may be distributed under different terms and without source code.

About

An advanced the data-driven project for self-driving miniature vehicles. This project emphasizes software engineering aspects such as requirements analysis, architecture, testing, continuous integration, and continuous deployment.

Resources

License

Code of conduct

Stars

Watchers

Forks

Packages

 
 
 

Contributors

Languages