DroneCAN application
The following hardware are required:
| № | Required device | Example | Image |
|---|---|---|---|
| 1 | Target device | Mini v2 or Micro node |  |
| 2 | Programmer, CAN-sniffer | RL sniffer and programmer |  |
Actually the repository can be suitable for any RaccoonLab nodes with HW version v2 (it basically means a stm32f103 board with a few specific design rules), but it is primarily intended for RaccoonLab Mini v2 node.
You are expected to use the following software:
- stm32 related: cmake, arm-none-eabi-gcc, stlink,
- (optional) STM32CubeMX or STM32CubeIDE,
- gui_tool.
The project depends on a few libraries which are attached to the repository as submodules. The dependency graph can be illustrated as shown below:
A few notes:
- Libs/stm32-cube-project is a project generated with the STM32CubeMX. It is based on .ioc file corresponded to the default firmware of the Mini v2 node. You may only need to change it if you want to use an a different peripheral configuration.
- Src/libparams is a simple library with ROM driver implementation that allows to store configuration parameters in persistent memory.
- Libs/dronecan_application is a C library that brings up the DroneCAN libcanard, platform specific drivers and serialization together to build a minimal DroneCAN application.
The project is based on the CMake build system, but it is suggested to interract with Makefile. This is just a wrapper under CMake, useful for its autocompletion.
Check Makefile for additional commands and details.
The main commads are following:
1. Build an exacutable and run in SITL mode
make sitl_dronecan run2. Build and upload a binary
To build a binary and upload it to the target, you can type:
make dronecan uploadThe result binary will be built in automatically created build folder.
When you run make dronecan before actual build process, a few additional source files are automatically generated into build/src such as:
- build/src/git_software_version.h that has info about the software version based on latest git tag,
- build/src/git_hash.h with info about the current commit,
- params.cpp and params.hpp - C++ source and header files with parameters array and enums based on all associated yaml files with registers (you can find generated files in the same folder: build/src),
- Src/dronecan_application/README.md with info about the supported interface and not port-related registers.
The periphery initialization is done in main() function of Libs/stm32-cube-project/Core/Src/main.c file. This file as well as all peripheral related drivers are pre-generated based on the configuratation .ioc file called project.ioc. If you want to use a different peripheral configuration, you should update the .ioc with STM32CubeIDE or STM32CubeMX and regenerate the project.
The periphery drivers are divided into 2 groups.
The drivers interfaces are represented by classes defined in header files in [Src/periphery] folder as shown below:
An actual implementation toy can find in source files in [Src/platform] folder. Depending in which mode you are building the application (SITL ubuntu or stm32f103) and the board type (mini v2 or a custom one) it uses different implementations:
- stm32 implementations depend on STM32CubeMX generated HAL drivers (though it is not required and you can write your optimized implementation),
- Ubuntu drivers implementations usually are just a mock drivers.
A module is a specific independent unit of an application functionality. It can be implemented in a different way, for example as RTOS task. But let's keep it baremetal for a while because typically (but not always) a Cyphal/DroneCAN application is simple and resource limited.
An example of modules for a minimal CAN-PWM application is shown below:
Typically, we recommend having at least CircuitStatus module that is responsible for internal status measurements including:
- 5V (after DC-DC),
- Vin (before DC-DC),
- STM32 internal temperature,
- Hardware version (from ADC_VERSION).
Some boards can have a current sensor and external temperature sensor or other ADC sensors.
Each module is expected to have a yaml file with his parameters.
After the peripheral initialization the application goes to the application_entry_point() in Src/dronecan_application/application.cpp. It is assumed that a user will provide a custom application here.
4.1. Clone the repo with submodules
git clone https://github.com/RaccoonlabDev/mini_v2_node --recursive
cd mini_v2_node
git submodule update --init --recursive4.2. Build the project and run the firmware
make sitl_dronecan run4.3. Run gui_tool
dronecan_gui_toolgit clone https://github.com/RaccoonlabDev/mini_v2_node --recursive
cd mini_v2_node
git submodule update --init --recursiveAn example of connection scheme suitable for bench test for Mini v2 node and RL Programmer-Sniffer is shown below:
You can also use other sniffer and programmers. For details refer to: Programmer usage and Sniffer usage pages.
make dronecan uploadRun gui_tool.
Please, refer to the Mini node docs. It has a detailed steps about how to perform bench testing of the node.
The following steps assume that you are already successful with the default application provided in this repository and want to customize it.
Make a template or fork of the repository. Then clone it. Don't forget about the submodules.
git clone https://github.com/RaccoonlabDev/mini_v2_node --recursive
cd mini_v2_node
git submodule update --init --recursiveHere, instead of RaccoonlabDev you should type the name of your org or profile.
- Optionally remove everything related to Cyphal:
rm .github/workflows/cyphal.yml
rm -rf Src/cyphal_application
git rm Libs/Cyphal- Update README.md with description of your application
Mini v2 node has 6 user's pins. By default 4 of them are configured as PWM and 2 of them as UART RX. The pinout configuration is shown on the image below:
| Pinout | Default config |
|---|---|
 |
 |
If you want to use a custom periphery configuration, update the Libs/stm32-cube-project/project.ioc file with STM32CubeIDE or STM32CubeMX and regenerate the project.
Since Libs/stm32-cube-project is submodule, you can either use your own submodule (make a fork or template RaccoonLabHardware/mini-v2-software) or just remove the submodule and include the source code in the root repository.
The main application is started in Src/dronecan_application/application.cpp. By default it just blinks the RGB LED, subscribes to the setpoint topic to control PWM1 and publishes a feedback with the latest applied setpoint.
Note, that the application is as simple as possible: it controls only a single PWM and doesn't have safety features like TTL, but you are free to extend it as you want.
- Include a header file, for example:
#include "dronecan.h"
#include "uavcan/equipment/power/BatteryInfo.h"- Create a message and trasnfer id, for example:
BatteryInfo_t battery_info{};
static uint8_t transfer_id = 0;- Publish a message and increase the
transfer_id, for example:
dronecan_equipment_battery_info_publish(&battery_info, &transfer_id);
transfer_id++;#include "dronecan.h"
#include "uavcan/equipment/indication/LightsCommand.h"
void callback(CanardRxTransfer* transfer) {
LightsCommand_t lights_command;
int8_t res = dronecan_equipment_indication_lights_command_deserialize(transfer, &lights_command);
if (res < 0) {
// handle error
}
// do something with the received command
}
// Somewhere on the initialization step:
if (uavcanSubscribe(UAVCAN_EQUIPMENT_INDICATION_LIGHTS_COMMAND, callback) < 0) {
// handle error
}This section is in progress. Please, check examples or libparams for the details.
When you add your custom module, don't forget to add source file and path to the file with registers to Src/dronecan_application/CMakeLists.txt.
You can also easily create custom Integer and String registers. An example is shown in Src/dronecan_application/params.yaml.
make dronecan upload