iRM Embedded Control Software 2017 V1.2.2

Release Notes

Fix CAN transmit failure issue caused by STM32CubeMX software miss labeling the Auto-Retransmission tag

iRM Embedded Control Software 2017 V1.2.1

Release Notes

This release does not have significant code changes. But to make our code structures easier to maintain and to be reused, we isolated Applications to a git submodule

iRM Embedded Control Software 2017 V1.2

Release Notes

Major Update

• Migrate HAL libraries from v1.18.0 to v1.21.0
• BSP layer adapt to the new CAN APIs in HAL libraries
• Configuration headers are moved out of the generic libraries since they are board specific / robot specific
• Kill switch functionality is added to chassis and gimbal libs, to ensure safety when testing those actuators that can sometimes go violently wrong in reality

Minor Changes / Bug Fixes

• Change HAL_Delay to osDelay in haptor control libs
• Add power module status FSM

iRM Embedded Control Software V1.1

Release Notes

Major update

• Motor Control API changes to adapt both CAN motors and PWM motors
• Power Module support is added to the BSP layer
  • current / voltage calibration
  • module online / offline detection
• PWM Control API changes to generalize to all timer and channels

Minor changes / bug fixes

• fix gaps between buzzer tones
• improve buzzer sound quality
• fix IMU task potential stack overflow
• increase IMU task frequency from 50Hz to 1000Hz
• ADC read a lot faster: fixed size average filter changes to a variable size average filter

iRM Embedded Is Coming To Public!

iRM Embedded Control Software V1.0 Release Notes

Finally we come to the point where we make our hardware control repository public! This repo, implemented on STM32F427II platform, contains all embedded control softwares for DJI RoboMaster Competition. It belongs to Team UIUC - Illini RoboMaster. All source codes are subjected to a GPL-3.0 License, meaning that you may modify and / or reuse our source codes whenever you want!

About This Project

This project is built upon the official drivers and HAL libraries for STM32F4xx series. For the sake of team consistency, we decided to use a generic CMake compilation system, which, in theory, should support any operating systems. However, as for the current release, we do require a UNIX based OS (e.g. MacOS, Ubuntu, etc.) to guarantee a build pass. Unfortunately, we do not have much time until the competition so we gave up supporting Windows users, specifically the ones using Keil development environment. If you are a master of CMake, you can go through my compilation tutorials and try to make it work in Windows systems :)

We separate our code structure into three layers: BSP, Libraries, and Tasks. This repo is specifically built to adapt our hardware designs, which means most of the user defined constants are related to our specific mechanical configurations. However, the three layers are built to be generic and adaptive to different mechanical design or even hardware control logic, and that is why we compress all types of robots into ONE code repository. So you may find it helpful to look straight into our source code for some generic functionalities. Below are a more detailed description of our layers.

BSP - Board Supporting Package

BSP layer handles direct interactions with hardware drivers and HAL libraries. It currently supports control for ADC, UART, GPIO, CAN, Generic IMU, Key Press Debouncing, Laser, LED, Debug Printing (through UART6), and PWM. In this layers, everything is built to be generic so that it may be reused by any higher level control logic libraries.

Libraries

Libraries layer is built upon the BSP layer. In this layer, we develop control logic for a higher level abstraction of hardware such as motor control, pid calculation, fusion kalman filter for sensor denoising etc. Some modules such as gimbal / haptor control may be developed to specifically adapt to our hardware settings, but most of them are built to achieve generic functionalities within control areas.

Tasks

Tasks layer integrates main control loops with multi-threading library FreeRTOS. The tasks are created and started right after all level initializations. This layer uses mostly Libraries APIs and some BSP APIs to boot up the robot to start doing tasks the way we want it to be.

Tests

Tests layer is independent of the main program. It is only used when the RUNTEST flag is set to ON when compiling the project. We create these Tests, either unit tests or runtime functionality tests, to insure the modules we developed are working properly before putting them into the main program. So it contains all levels of tests ranging from BSP layers to Libraries layers. However, it is currently poorly documented, so you might need some time to go through the source code to find out how we tests our own modules.