Development process

This page has information on the steps needed to start coding, as well as suggestions on how to manage the project, use git, and keep the code style consistent.

Making a change

ROS

Here are instructions for making a simple change to the ROS code and testing it. Say creating a ROS node and publishing "Hello world" to a ROS topic. Note that depending on the version of this repository you are using these files may already be there, but this describes how it was done.

1. Set up your development environment. See (Setup)[Setup].
2. Add the talk.py file from the (talker/listener ROS tutorial)[http://wiki.ros.org/ROS/Tutorials/WritingPublisherSubscriber%28python%29] to the ROS/src/rover_core/src folder (the source folder of the main ROS package in this project. See (ROS)[ROS]).
3. Edit the launch file in at ROS/src/rover_core/launch/rover.launch and add <node pkg="rover_core" name="talker1" type="talk.py"/>. This will run the talk.py file when ROS is started.
4. Start the ros-master service by opening a terminal, navigating to the rover repository folder, and running sudo docker-compose up ros-master --build.
   • Alternately run sudo docker-compose up --build to build and start all the services.
   • The ros-master container is configured to run the start.sh script on startup, which runs roslaunch rover_core rover.launch, which is what starts the nodes.
5. Open another terminal and run sudo docker-compose exec ros-master bash to get a terminal into that container.
6. Run source /opt/ros/melodic/setup.bash and source ROS/devel/setup.bash to configure the environment variables needed to interact with ROS.
7. Run rostopic echo chatter to print the messages talk.py is sending to the chatter topic.
8. After making sure it works, commit the change following instructions from the sections below.

Arduino code

Making a change to the motor driver code or other arduino code.

1. Set up your development environment. See (Setup)[Setup].
2. In VSCode, click the PlatformIO alien icon in the sidebar, click 'Open', then click 'Open project' and open the Arduino/ROS-motor-control folder.
3. Make your changes to the code and build and upload it the Arduino or Teensy by clicking Project Tasks > env:teensy4.0 (if using the Teensy4.0) > Upload.
4. Make sure it works and commit and push the code to the ROS-motor-control repository.
5. ROS-motor-control is a submodule of the main Rover repository, so to have it updated there you will need to commit and push the change to the submodule version.

Project Management

GitLab or GitHub projects (like our Rover Project support a KanBan type development process (alternatives include agile and waterfall). Basically, it is a way a to organize a project and keep track of work that's being done. Here is how we'll use it:

• Everything that needs to be done is turned into an issue. That list of issues is the called the backlog.
  • Issues can be tasks, bugs, requests, etc
  • Issues are grouped into larger milestones
• When we decide to work on an issue, it is added to the project board. This makes it easy to keep track of what everyone is doing and what needs to happen next.
  • Move issues between columns on the board as appropriate
  • Assign yourself to an issue while working it
  • Use comments on the issue for relevant discussion. User can be tagged (e.g. @johndoe) or other issues linked (e.g. #7)
  • When an issue is complete, put it in the review column and let someone else check and close it.

Git Workflow & Guidelines

We will use the feature branch workflow. This is a way of using git to allow multiple people to work on the same git repository and lets changes be reviewed before they are added to the master branch. Here are the basics of how code gets into the master branch and some guidelines:

• Make a branch to put your changes on
  • Name the branch after what it is for working on, e.g. "issue-15"
  • Branches can be deleted after they are merged
• Make your changes and commit them
  • Commits should always be linked to an issue, for example if the issue number is 24, put #24 at the end of your commit message. This makes commits show up on the issue's page, and makes it easy to find why changes to code were made. Useful with git blame.
  • Each commit should be for a single issue or logical change. See this page for more info.
• Push the changes to the branch
  • Do this often so you have a backup of your code and other people can see it
• Update documentation. Previous steps might cover this (comments, commit messages, and issue descriptions) so it might not be needed. Update relevant wiki pages.
• Submit a pull request to origin master
• The changes will get reviewed and merged

The feature branch workflow page has a step by step example of this process in action. The git style guide is a good reference good and bad git practices.

Coding Style

• Try to make code readable and self explanatory and explain the rest with comments
• Try to follow the generally accepted style for what you are working on
  • Use 4 spaces for indentation
    • Exception: use 2 spaces in Arduino code
  • Python
    • Todo: summarize
  • C++
    • Todo: summarize
• Style checkers can be added to the Build System so that style is checked whenever code is pushed to GitLab.