-
Notifications
You must be signed in to change notification settings - Fork 1
Home
- Try running the stack on the car
- Attach the available
Go to our GitHub Project Page and take a look at the structure.
- Tasks are categorized into iterations that represent time frames. For example,
Spring Quarter Week 8-10
- Priority: P0-P2
- Assignees: People working on the task.
- Estimate (Hrs): Write down the estimated hours so you have a general sense of how much time you need.
- 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.
- 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.
- 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 fromname_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
basestation_launch
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
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)
- A possible alternative is
- contains:
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.
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 eachcolcon
invocation.
For more information, read the ROS2 Documentation