Skip to content
matthew edited this page Sep 18, 2020 · 25 revisions

Contents

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 working 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

The following is the hardware and software we use on our production standard robot. 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

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

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.

Note: If the control flow diagrams are not clear, refer to the Control Flow Diagram Reference.

Principle introduction and theoretical support analysis

The main concepts on display in the following sections are the power and configurability of the developed framework.

See the following pages:

Software architecture or hierarchy diagram

Refer to the following pages:

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.

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.