Home
- Software Function Introduction
- Capabilities and Results (Software effects display)
- Dependencies and Hardware/Software environment
- Installation and Compilation
- File directory structure and usage
- Software and hardware system block diagram, data flow diagram
- Principle introduction and theoretical support analysis
- Software architecture or hierarchy diagram
- Future development
Welcome the the aruw-mcb wiki! This repository stores ARUW's "Main Control Board" (MCB) code for the RoboMaster competition.
The MCB is a RoboMaster Development Board Type A which directly operates all major systems on our robots. Among these are drive, turret, launcher wheels, and human input.
This repository includes all MCB code, including generated Hardware Abstraction Layers (HALs), periphery scripts, build and deploy tools, test code, and source code developed for the 2020 RoboMaster robotics competition and as of recently in anticipation for the 2021 RoboMaster robotics competition. This system is responsible for robot control for all robot types; however, due to the pandemic, it was decided that we only focus control code for the soldier robot. Much of the controls infrastructure written for the soldier will be modified and expanded in the upcoming season to provide robot code that fully supports an array of robots.
This repository replaces Keil MDK and CubeMX, which our team has used previously, with a custom
VSCode setup and a bare bones open source C++ embedded HAL generator called modm. As a result, all
of our code has been designed from the ground up in C++ since the end of last season.
Our embedded framework is set up with the following core design principles in mind:
This codebase has been set up with continuous integration (CI) and longevity in mind. We follow strict practices to ensure code is easy to read, modify, and interact with the codebase. While embedded code quality is not particularly interesting to display, a lot of time is spent adding or updating scripts used in our CI checks on GitLab. Below you can see what the output of a typical CI script that we use for automated verification when merging code into develop or master. As can be seen in the image, initial verification and an initial robot build is done in the first stage of the pipeline, and in the second, all other robot types are built. The first stage also checks to ensure that it matches the expected auto-formatting rules (enforced by clang-format).
Additionally, the architecture has been designed with unit tests in mind. A key feature that makes this possible is the same code that is run on the embedded system can run in an Ubuntu Linux environment. This is especially important as the amount of on-robot testing time the last year has been limited. Now that this framework is in place, we can easily unit test a piece of software off-robot. This will lead to more robust robot code and will allow us to be more efficient when we are testing on the robot.
The low level architecture has also been designed such that control systems engineers may work with high level APIs, allowing more focus to be spent on improving control system code as opposed to working with low level HALs. Below you can see some of the controls code developed in this repository including integration with the vision system, agitator control with jam detection, and chassis "wiggle" drive.
The following is a list of the hardware and software we use on our production standard (referred to as the "soldier" robot in this wiki and in the repository) robot. Miscellaneous hardware for other robots is not listed, but includes linear distance sensors and IMUs.
- Robomaster Type A Board (MCB)
- ST-Link V2 debugger or J-Link V10 debugger
- RoboMaster specific hardware:
- DR16 remote/receiver
- GM6020 gimbal motors
- M3508 P19 brushless motors
- M3510 gear motors
- M2006 P36 brushless motors
- C620 motor controllers
- C610 motor controllers
- 820R motor controllers
- Referee system (currently interfaces with 2019 version)
- Jetson Xavier and periphery vision tools
- Ubuntu 20.04 LTS docker container (see
aruw-mcb-dev-container), which includes
the following:
googletest/googlemock- clang-format-10, an auto-formatter
- scons, a build tool
- python 3
- lbuild, a generation tool
- arm-none-eabi-gcc/g++
- GNU/Linux gcc/g++
- Openocd, an on-chip debugger
- Visual Studio Code
-
modm, a C++-native HAL generator
See the README's new user guide for installation instructions. Refer to the README's building and running via the terminal section for compilation instructions.
The README's installation guide provides instructions on how to install our development Docker container. If you would like to avoid using Docker, refer to the following pages for complete but depreciated manual installation guides:
Refer to the page named File Directory Structure for information on the directory structure.
Refer to the following pages that include hardware and software system block diagrams and control flow diagrams.
Note: If the control flow diagrams are not clear, refer to the [[Control Flow Diagram Reference]].
- Software Architecture Layout
- Soldier Hardware Block Diagram
- Main Control Loop
- Vision System Serial Protocol
The main concepts on display in the following sections are the power and configurability of the developed framework.
See the following pages:
Refer to the following pages:
For up-and-coming software development projects on each of our robots see our GitLab milestones page. Here you will find defined goals for upcoming quarters.
Our general goals are as follows:
- With a base architecture in place, we are ready to expand our unit test suite and integrate our code with a full simulator that is currently being developed. Due to the impact of the coronavirus outbreak, it is still unlikely that we will be able to resume fully in-person with the robots until 2021, so unit tests and simulation will have to be our main method of validation that we will use while developing new systems.
- Improving integration with computer vision algorithms. This includes testing and integration of a more complex turret gimbal controller that utilizes path planning.
- Integrating a capacitor bank design into our soldier and optimizing chassis power consumption. Since the 2018/2019 season, a lot of development has already gone into reworking how we handled chassis power optimization, and we plan on improving our chassis power limiting algorithm and replacing our simple speed controller with a state space controller that optimizes current draw.
- Using the command/subsystem framework to build up a suite of subsystems, commands, and comprised commands to be used by the engineer robot. The command/subsystem framework will allow us to modularize and then heavily optimize automated collection.
- Expanding the in-progress error logging and debugging work. This utilizes the RoboMaster OLED board and serial debugging interface to provide members with a more efficient method of tracking down hardware faults during the competition. See this wiki page for design brainstorming.