We are building our team completely from scratch since everyone who was on the team years before have now graduated. We have a lot of old materials and devices but no knowledge of how to use them. Specifically, we have a lot of type A development boards. I was wondering how to get these to communicate with the computer in order to deploy code onto them.
Thank you all in advance!
This is a good question!
Unfortunately, the DJI-provided situation on this front is nontrivial.
I will speak to the overall state of affairs, and provide the context I think is most relevant. What I don’t know is what resources are available from DJI that they would normally point a new team at – I’d appreciate others chiming in with anything they’re aware of.
This post is not going to be a tutorial – I’ll outline the puzzle pieces you have available and some leads to get started, but not the full process. Myself and others can surely give more targeted help as you get into it. And if others do have tutorials available to link, I’m sure those would be appreciated.
As noted below, I’m going to follow up in a separate post with what my team is actually doing for our software, replacing the “software” section in this post.
Before we get into how to do what you’d like, we should make sure you understand the hardware you have.
There are two (technically, 3, but we don’t talk about the estranged cousin) RoboMaster Development Boards: Type A and Type C. Type A is the original, and is what old(er) teams including ARUW use. Type C is newer and DJI recommends it for new teams, but it isn’t clear that it’s actually better. I will refer to “dev board” in general to refer to the commonalities between both types.
A dev board is a custom circuit board designed by DJI which includes, among other things:
Note that the dev boards have manuals, schematics and other related information available online. I won’t include them all here but if you’re looking for those resources, feel free to ask. They aren’t great but do get the job done often.
That SWD debug port is how you program the board – but you need some hardware to interface with that port.
The typical solution is an ST-Link – in particular, usually an ST-Link V2 Mini. They look something like this:
You plug the SWDIO, GND, SWCLK and 3.3V lines into the SWD port on the dev board – they’re labelled. The ST-Link itself plugs into your PC via USB.
To connect them, you’ll need an appropriate cable. I’ve never ordered these things, so I can’t be of much help on their proper name. But the specs page lists the connector as:
4-Pin SWD Cable：1.25-mm pitch 4-pin / 2.54-mm pitch DuPont & 26 AWG flexible flat & 500mm
Perhaps others can chime in with a good link to order the “0.1in header” to “DuPont something-or-other” cables.
The primary alternative to ST-Links are J-Links. They’re made by a different company, and come in a few variants (“real” J-Links, Chinese knock-offs, and “J-Link Edu Mini”, perhaps among others). They have some extra capabilities and mostly separate software ecosystem. Some teams use them (including us) – we’re looking to buy a bunch of the “J-Link Edu Mini”, assuming they work.
The Dev Boards are purely hardware – a microcontroller and some devices it can talk to. Unlike, say, Arduino, there’s no software toolkit that comes with it. You have to pick some tools and libraries to use, and they’re going to be a lot lower-level than what you may be used to with consumer/hobbyist boards. You are on your own to pick the tools you use, so long as it produces a compatible ARM binary in the end.
Below, I’m going to describe the “default” option promoted by DJI. I’ll follow up in a separate post with what we actually do, and what a handful of other teams are collaborating with us on.
If on Windows, you’ll need the ST-Link driver from ST’s website. The toolchain I’m discribing below only works on Windows, so that’s really all there is to it.
However, for later reference if using other tools – for Linux, this software is what we’ve used (GitHub - stlink-org/stlink: Open source STM32 MCU programming toolset). We have also gotten it working on Mac but I don’t recall the details.
Most teams use Keil MDK-Arm: Keil MDK – Arm®. It’s an IDE with built-in compiler that is the de-facto standard for programming ARM chips with vendor software.
Keil is paid. There are crackers available freely, which I think most RM teams use (shhhhh – but ping on Discord if you need it). There’s a somewhat limited evaluation version, which is what you’ll probably use anyway.
The built-in compiler supports C and at least some C++ if you decide to use it. It has a built-in debugger which is pretty fully-featured and works with the ST-Link.
I’m lumping two things together here because they probably won’t vary independently for a new team:
The HAL that most teams use is one generated by STM32 Cube MX: STM32CubeMX - STM32Cube initialization code generator - STMicroelectronics. You open the software and tell it the board in use, configure the involved pins, and select how the hardware should be configured. It then spits out some HAL code for you.
To go along with this, DJI provides some example code. Teams often copy the CubeMX project from here as a starting point, and then edit it to suit their needs. They also typically copy in the motor driver code and related logic. GitHub - RoboMaster/DevelopmentBoard-Examples
Note that the above link is for the Type A board. The Type C examples are significantly more thorough, and in English. GitHub - RoboMaster/Development-Board-C-Examples. Most of what they do here is also applicable to the Type A, but the specific pins and CubeMX configuration is different.
This combination of HAL and drivers requires a fair amount of knowledge (which you can learn over time) to be comfortable. It also produces extremely ugly, hard-to-maintain code. But it’s the most widely tested approach. And you can progressively replace DJI’s sample code with e.g. your own motor drivers – they aren’t truly hard to write.
The above is primarily targeted at C. Some teams enable the C++ features of CubeMX/Keil and write C++, but I don’t have any experience with that.
This is your own robot control logic. Most of it is up to you, and particular controls questions warrant their own threads. People here would be happy to help.
The main point I’d like to make here is: most of robot programming is taking in inputs (remote control, motor encoders, referee system data) and then producing outputs (motor commands, driver feedback) in a loop. So your code will likely have a top-level loop which is responsible for doing those things – read from some inputs, call functions that handle operating your major subsystems, and then write the final results. And you do that at some high frequency.
The high-level overview is:
Lots of teams have open-sourced their controls code, mostly to compete for the “open-source prize” that DJI awards each year. You or others are free to create a new thread to link open source submissions and I can post some of the ones I’m familiar enough. Most of them will be a lot more advanced than what you’ll start out with, but they’re nonetheless potentially helpful.
In my last post, I discussed the “default” state of affairs. In this one, I’ll describe what my team actually does, and how it may help you.
This is also covered in video form here, with much more detail: Taproot Introduction Meeting (July 24th, 2021) - YouTube. I’d recommend watching that in full (even if on 2X speed 
) if you want to go this route.
In short, ARUW has developed an open-source library called Taproot which replaces Keil, CubeMX, and the DJI-provided software. It’s a custom C++ codebase, which is closer to languages that most university students are familiar with. It comes with a HAL (an external library we use called modm), drivers for most/all DJI devices, and various useful building-blocks. It isn’t perfectly documented, but we’re working on it – it’s certainly better than what DJI provides.
There are some rough edges – perhaps the most notable is that the tooling primarily supports Linux host PCs for development, so most of us develop in Linux virtual machines from Windows. It works for our needs fairly well.
See the main repo for more information and links to “getting started” materials: aruw / controls / taproot · GitLab
Also, if you’re interested, join or Discord server! It’s linked at the top of the repo README.
Small update here: we ordered a handful of J-Link Edus ($20 each from Adafruit) and they work with Ozone, the official J-Link software. So those would be great choices for debugging.
