Skip to content

Conventions

Jonathan Liu edited this page Aug 14, 2023 · 7 revisions

Coordinate system

Same as apriltag coordinates but meters. Origin is at corner of blue alliance driver station, +x is towards red player station, +y is towards blue player station, and positive rotation is counterclockwise.

For robot frame, +x is pointing towards front of robot, +y is perpendicular and to the left, and positive rotation is counterclockwise.

Make sure that robotX and worldX are distinguished by using different variable names, like below

vec::Vector2D robotX; // robot-oriented coordinates
vec::Vector2D worldX; // world-oriented coordinates

The exact name doesn't matter, just make sure another person understands what you mean.

drawing

Merging & Pull Requests

All new features should be on new branch, Do not commit to main, branch from main before making any changes.

Make sure that each branch = new feature. If one feature requires another to write/test, then branch off the branch of the other feature, then submit PR into the branch of the other feature, not main.

Before merging any pull request, pull from main to get the latest code and resolve merge conflicts on your own branch.

Make sure the resolved code, still builds.

TEST BEFORE MERGING AND AFTER PULLING FROM MAIN to make sure that code on main actually works

Lastly, Do not delete your branch

Tagging Code

Use annotated tags, tag only on main after making sure that the robot code works

  • Naming convention: semantic versioning
  • Use annottated tags - SPECIFY WHAT IS WORKING, not everything has to work before tagging but if something wasn't working before and it works now specify that

Proposals

  • Submit as a GitHub Issue
  • Assign yourself or someone assigned to do the work.
  • Use the appropriate label

Testing

Test on your own will, but don't spend too much time.

Make sure all tests you write are on your own branch. You may merge tests to the main branch, if they are Unit Tests. Comment tests that are not unit tests (special robot code written specifically to test your feature)

Again, TEST BEFORE MERGING AND AFTER PULLING FROM MAIN

Documentation

  • Put in comments (doxygen)
  • For classes and methods, use doxygen to generate code documentation.
  • For general concepts, create a new page here in the wiki.
  • You can make references to your code in the wiki, but make sure you document well in the code

Refactoring

  • clang-format or just use VSCode's format document
  • 2 space tabs is preferred, but 4 also works as well
  • Don't use tab characters; a tab = 2 or 4 space characters
Clone this wiki locally