Home

Contents

• 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

Software Function Introduction

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 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. This codebase also is designed for longevity and testability in mind. Architecture has been designed such that control systems engineers are able to work with high level APIs, allowing more focus to be spent on improving control system code as opposed to monkeying around with low level HALs. Additionally, the architecture has been designed with unit tests in mind. Support for running unit tests in googletest and googlemock has been integrated into the repository. This is especially important as the amount of on-robot testing time the last year has been limited. These can be easily written, and a simulation framework has been set up such that all of our code can be compiled and ran on a Linux machine.

Capabilities and Results (Software effects display)

Dependencies and Hardware/Software environment

This is the hardware and software we use on our production soldier robot. Other miscellaneous hardware for other robots is not listed, but includes linear distance sensors and IMUs.

Hardware

• 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
  • Referee system (currently interfaces with 2019 version)
• Jetson Xavier and periphery vision tools

Software

• 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++)[https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads]
  • GNU/Linux gcc/g++
• Openocd, an on-chip debugger
• Visual Studio Code
• modm, a C++-native HAL generator

Installation and Compilation

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 instead you would like to avoid using Docker, for complete but depreciated manual installation guides refer to the following pages:

• Windows Setup
• Windows WSL Setup
• Debian Linux Setup

File directory structure and usage

Refer to the page named File Directory Structure for information on the directory structure.

Software and hardware system block diagram, data flow diagram

Refer to the following pages that include hardware and software system block diagrams and control flow diagrams.

• Soldier Hardware Block Diagram
• Main Control Loop

Principle introduction and theoretical support analysis

See the following pages:

• Command subsystem framework

Software architecture or hierarchy diagram

Future development

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.

Some large goals are as follows:

• Moving forward, with a base architecture intact, we plan on beefing up our unit test suite and integrating our code with a full simulator currently being developed. It is still unlikely that we will be able to work fully with robots until potentially 2021 aside from short periods of verification, so unit tests and simulation will have to be our main method of validation that we will use while developing new systems.
• We plan on improving integration with computer vision algorithms. This includes testing and integration of a more complex turret gimbal controller that utilizes path planning.
• We plan on integrating a capacitor bank design into our soldier and optimizing chassis power consumption. A lot of development has already gone into improving how we handled chassis power optimization, and we plan on improving and integrating our chassis power limiting algorithm and replacing our simple speed controller with a state space controller that optimizes current draw.
• We plan on 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.
• We plan on expanding upon the in progress work being done on error logging and debugging that 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.