Skip to content
dureduck edited this page May 31, 2024 · 4 revisions

Welcome to the robocar wiki!

Ways to get familiar with the stack:

  • Try running the stack on the car
  • Attach the available

GitHub Project

Go to our GitHub Project Page and take a look at the structure.

  1. Tasks are categorized into iterations that represent time frames. For example, Spring Quarter Week 8-10
  2. Priority: P0-P2
  3. Assignees: People working on the task.
  4. Estimate (Hrs): Write down the estimated hours so you have a general sense of how much time you need.
  5. Size: Your estimated size of that task

If you have yet to be assigned to a task, don't worry we will coordinate on that. Please contact Winston, Alexander, or Rebecca and tell us your preference for tasks.

General Code Guidelines

Style Guidelines

  • Add TODO when a minor code smell is found, e.g. a hard-coded number that should be a parameter. (You are then welcome to fix them and propose the fixes in a pull request!).
  • Add docstrings to the code. To ease the setup in VSCode you can use the Python Docstring Generator extension.
  • Add comments expecially for the parts of the code that are not straightforward, or to explain why a certain approach was chosen.
  • In Python, use type-hinting for the parameters and the return values of the functions, when it's not obvious (e.g. init function and callback functions).
  • Unused imports and variables should be removed.

Feature Branches

  • A feature starts from the dev branch into its own branch. From the master branch, you should only use branch hotfixes because the master branch should always be the stable version of your software.
  • When a feature branch is done, it should be merged into name_dev (in our case, foxy_devel), then at some point, you should branch your next release from name_dev (including some features) into a new 'release/*' branch, which will be merged into the master once it is stabilized and well tested.
  • Convert the task you're working on in our GitHub project to GitHub Issue. Then, associate your pull request or feature branch to that issue.
  • To aid with workflow, it's best to include your name in your feature branch. For example, raymond/vesc

Overview ofrobocar stack structure

basestation_launch image

A Note for Submodule Management

We want to avoid using Git Submodule by using vcs-tool. vcs-tool helps you manage multiple external packages at once.

We can vcs import the vcs file. For example:

vcs import < my.repos

Subpackages:

vesc_odom: launch package. Its goal is to launch other packages. This is because the actual vesc package is in external. It will also control the priority of drive topics, which includes teleop and drive (autonomous)

sensors: uses livox-SDK2 and [livox_ros_driver2](https://github.com/Livox-SDK/livox_ros_driver2)

state_estimation: for localization. uses EKF from robot_localization

external: External repositories containing binary packages that were built from source during docker build. The benefit of using binary packages is that we can use the package from ros2 C++ or python and not necessarily the languages/frameworks the packages were written in.

# Want the environment to know package locations
source source_ros2.sh

build_ros2_pkg basestation_launch
  • planner: local planner
    • contains: planner, nav2_planner, nav2_controller, nav2_recovery
    • nav2_recovery deals with when we go off the track. Might not be needed since we're racing.
    • The controller we're using Regulated Pure Pursuit (RPP)
      • A possible alternative is Model Predicted Control (MPC)

global_planner: global planner

An approach: use nav_2 global planner as local planner for head-to-head race.

Try use obstacle avoidance on global planner.

Fun notes about ROS2:

After colcon build, the following directories will be created:

  • The build directory will be where intermediate files are stored. For each package, a subfolder will be created in which, e.g., CMake is being invoked.

  • The install directory is where each package will be installed. By default, each package will be installed in a separate subdirectory.

  • The log directory contains various logging information about each colcon invocation.

For more information, read the ROS2 Documentation