feat(boards): add Amovlab Flycore support#27407
Conversation
|
No broken links found in changed files. |
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
| #endif | ||
|
|
||
| #ifndef BOOT_DEVICES_FILTER_ONUSB | ||
| # define BOOT_DEVICES_FILTER_ONUSB USB0_DEV|SERIAL0_DEV|SERIAL1_DEV |
There was a problem hiding this comment.
[error] bugprone-macro-parentheses [error]
macro replacement list should be enclosed in parentheses
| # define BOOT_DEVICES_FILTER_ONUSB USB0_DEV|SERIAL0_DEV|SERIAL1_DEV | |
| # define BOOT_DEVICES_FILTER_ONUSB (USB0_DEV|SERIAL0_DEV|SERIAL1_DEV) |
| @@ -0,0 +1,85 @@ | |||
| # Amovlab Flycore | |||
There was a problem hiding this comment.
Please remove all changes in the docs/zh path. If you want to translate this, you join crowdin and provide a translation there - then that round-trips from the English version.
| @@ -0,0 +1,99 @@ | |||
| # Amovlab Flycore | |||
There was a problem hiding this comment.
I have done a minor subedit, but this is too minimal. Ideally you might produce something like these:
- https://docs.px4.io/main/en/flight_controller/durandal
- https://docs.px4.io/main/en/flight_controller/accton-godwit_ga1
The information here is useful, but can you follow a more standard structure?
I've added some comments online.
| <!-- | ||
| Insert description | ||
|
|
||
| Insert image | ||
| --> |
There was a problem hiding this comment.
Minimally we need an image and description here. That tells us things like what are the ports available.
| ## Overview | ||
|
|
||
| - **MCU:** STM32H743 (Cortex-M7) | ||
| - **Onboard IMU:** Bosch BMI088 (SPI1), InvenSense ICM42688P (SPI2) | ||
| - **Onboard barometer:** MS5611 (SPI1) | ||
| - **PWM:** 10 FMU outputs (no PX4IO coprocessor) | ||
| - **CAN:** dual external CAN (FDCAN1 / FDCAN2) | ||
| - **USB:** product string `AMOVLAB FLYCORE` |
There was a problem hiding this comment.
Normally we would fill in everything here:
## Specifications {#specifications}
- **Processor**
- **Main FMU Processor**: STM32H743 (32-bit Arm® Cortex®-M7, 480 MHz, 2MB flash, 1MB RAM)
- **Sensors**
- **IMU**: BMI088 (SPI), ICM-42688P (SPI)
- **Barometer**: MS5611 (SPI)
- **Magnetometer**: TODO: list magnetometer(s)
- **Interfaces**
- **PWM outputs**: 10 (FMU)
- **Serial ports**: 7
- **I2C ports**: 2 (both external)
- I2C1 (external): free (no sensor detected)
- I2C4 (external): free (no sensor detected)
- **SPI buses**: 3
- BMI088 (IMU), MS5611 (barometer)
- ICM-42688P (IMU)
- **CAN buses**: 2
- **USB**: Yes
- **RC input**: Yes (PPM pin + serial)
- **Analog battery inputs**: 1
- **Additional analog inputs**: TODO: number of additional analog inputs
- **Electrical Data**
- **Operating voltage**: TODO: supply voltage range
- **Mechanical Data**
- **Dimensions**: TODO: dimensions (mm)
- **Weight**: TODO: weight (g)
|
|
||
| ## Where to Buy {#store} | ||
|
|
||
| TBD |
There was a problem hiding this comment.
Where can people get this
| | TELEM3 | `/dev/ttyS3` | CONFIG_BOARD_SERIAL_TEL3 | | ||
| | RC | `/dev/ttyS4` | CONFIG_BOARD_SERIAL_RC | | ||
| | GPS2 | `/dev/ttyS5` | CONFIG_BOARD_SERIAL_GPS2 | | ||
|
|
There was a problem hiding this comment.
IFF correct, add a section like this
| ## PWM Outputs {#pwm_outputs} | |
| This flight controller supports up to 10 FMU PWM outputs (MAIN). | |
| Outputs 1-7 support [DShot](../peripherals/dshot.md) and [Bidirectional DShot](../peripherals/dshot.md#bidirectional-dshot-telemetry). | |
| Outputs 8-10 do not support DShot. | |
| The 10 outputs are in 3 groups: | |
| - Outputs 1-4 in group1 (Timer1) | |
| - Outputs 5-7 in group2 (Timer3) | |
| - Outputs 8-10 in group3 (Timer4) | |
| All outputs within the same group must use the same output protocol and rate. | |
| | Port | Device | `default.px4board` | | ||
| | ------ | ------------ | ------------------------ | | ||
| | TELEM1 | `/dev/ttyS0` | CONFIG_BOARD_SERIAL_TEL1 | | ||
| | TELEM2 | `/dev/ttyS1` | CONFIG_BOARD_SERIAL_TEL2 | | ||
| | GPS1 | `/dev/ttyS2` | CONFIG_BOARD_SERIAL_GPS1 | | ||
| | TELEM3 | `/dev/ttyS3` | CONFIG_BOARD_SERIAL_TEL3 | | ||
| | RC | `/dev/ttyS4` | CONFIG_BOARD_SERIAL_RC | | ||
| | GPS2 | `/dev/ttyS5` | CONFIG_BOARD_SERIAL_GPS2 | |
There was a problem hiding this comment.
This is what my tool generates. It seems more complete?
| UART | Device | Port | Flow Control |
|---|---|---|---|
| USART2 | /dev/ttyS0 | TELEM1 |
✓ |
| USART3 | /dev/ttyS1 | TELEM2 |
✓ |
| UART4 | /dev/ttyS2 | GPS1 |
- |
| UART5 | /dev/ttyS3 | TELEM3 |
- |
| USART6 | /dev/ttyS4 | RC |
- |
| UART7 | /dev/ttyS5 | GPS2 |
- |
| UART8 | /dev/ttyS6 | Debug Console |
- |
| | TELEM3 | `/dev/ttyS3` | CONFIG_BOARD_SERIAL_TEL3 | | ||
| | RC | `/dev/ttyS4` | CONFIG_BOARD_SERIAL_RC | | ||
| | GPS2 | `/dev/ttyS5` | CONFIG_BOARD_SERIAL_GPS2 | | ||
|
|
There was a problem hiding this comment.
How is RC wired? Is there an IO board or is it connected to the FMU. Does it use RC_INPUT or COMMON_RC?
Depending on what you say, a section that looks something like this might be added
### Radio Control {#radio_control}
A remote control (RC) radio system is required if you want to _manually_ control your vehicle (PX4 does not require a radio system for autonomous flight modes).
You will need to [select a compatible transmitter/receiver](../getting_started/rc_transmitter_receiver.md) and then _bind_ them so that they communicate (read the instructions that come with your specific transmitter/receiver).
The ports and supported protocols are:
- `RC` (FMU): SBUS, DSM/DSMX, ST24, SUMD, CRSF, and GHST receivers
For PPM and S.Bus receivers, a single signal wire carries all channels. If your receiver outputs individual PWM signals (one wire per channel) it must be connected via a [PPM encoder](../getting_started/rc_transmitter_receiver.md#pwm-receivers).
| | TELEM3 | `/dev/ttyS3` | CONFIG_BOARD_SERIAL_TEL3 | | ||
| | RC | `/dev/ttyS4` | CONFIG_BOARD_SERIAL_RC | | ||
| | GPS2 | `/dev/ttyS5` | CONFIG_BOARD_SERIAL_GPS2 | | ||
|
|
There was a problem hiding this comment.
How are the GPS set up? Is GPS1 a port with a safety switch as well? Do these use pixhawk standard ports. Dependin gon your answere we'd add as section that is structured something like this:
### GPS & Compass {#gps_compass}
PX4 supports GPS modules connected to the GPS port(s) listed below.
The module should be [mounted on the frame](../assembly/mount_gps_compass.md) as far away from other electronics as possible, with the direction marker pointing towards the front of the vehicle.
The GPS ports are:
- `GPS1` (FMU): TODO: connector type — GPS, compass (I2C)
- `GPS2` (FMU): TODO: connector type — GPS, compass (I2C)
| | TELEM3 | `/dev/ttyS3` | CONFIG_BOARD_SERIAL_TEL3 | | ||
| | RC | `/dev/ttyS4` | CONFIG_BOARD_SERIAL_RC | | ||
| | GPS2 | `/dev/ttyS5` | CONFIG_BOARD_SERIAL_GPS2 | | ||
|
|
There was a problem hiding this comment.
HOw is the board powered? Below is what my tool output. Note that this assumes all sorts of things about ports, so this could be completely wrong. But this should help you understand the kind of information that would be useful.
## Power {#power}
The flight controller can be powered from a power module connected to the **TODO: POWER port label** port.
The power module must supply a regulated **5V** at a minimum of **3A continuous**.
Power ports:
- `TODO: POWER port label`: TODO: connector type
:::warning
The PWM output ports are not powered by the POWER port.
The output rail must be [separately powered](../assembly/servo_power.md) if it needs to power servos or other hardware.
This is generally true for VTOL and fixed-wing vehicles, but not necessarily true for MC vehicles.
:::
For battery and power module configuration see [Battery and Power Module Setup](../config/battery.md).
<!-- TOOL NOTE: num_power_inputs=1 (default; BOARD_NUMBER_BRICKS /
BOARD_NUMBER_DIGITAL_BRICKS not defined in board_config.h).
power_monitor_type=None — no CONFIG_DRIVERS_POWER_MONITOR_INA* in default.px4board.
The board uses analog ADC monitoring: ADC_BATTERY_VOLTAGE_CHANNEL (ch5, PB1) and
ADC_BATTERY_CURRENT_CHANNEL (ch18, PA4) are defined in board_config.h, but the
tool only detects BOARD_NUMBER_BRICKS for analog count. Power port label and
connector type require wizard data.
DISCREPANCY vs hand-written doc:
- Hand-written doc does not include a Power section. The tool always generates one. -->
<!-- power-source-data
{
"board": "amovlab/flycore",
"source": {
"num_power_inputs": 1,
"has_redundant_power": false,
"has_dual_battery_monitoring": false,
"has_dronecan_power_input": false,
"power_monitor_type": null
},
"power_ports_wizard": null
}
-->
| | TELEM3 | `/dev/ttyS3` | CONFIG_BOARD_SERIAL_TEL3 | | ||
| | RC | `/dev/ttyS4` | CONFIG_BOARD_SERIAL_RC | | ||
| | GPS2 | `/dev/ttyS5` | CONFIG_BOARD_SERIAL_GPS2 | | ||
|
|
There was a problem hiding this comment.
Last one - we commonly have these kinds of sections. So just for "discussion"
## Telemetry Radios (Optional) {#telemetry}
[Telemetry radios](../telemetry/index.md) may be used to communicate and control a vehicle in flight from a ground station (for example, you can direct the UAV to a particular position, or upload a new mission).
The vehicle-based radio should be connected to a TELEM port — **TELEM1**, **TELEM2**, **TELEM3** (if connected to **TELEM1**, no further configuration is required).
The other radio is connected to your ground station computer or mobile device (usually by USB).
<!-- TOOL NOTE: Three TELEM ports detected: TELEM1 (USART2), TELEM2 (USART3), TELEM3 (UART5). -->
<!-- telemetry-source-data
{
"board": "amovlab/flycore",
"source": {"telem_ports": ["TELEM1", "TELEM2", "TELEM3"]}
}
-->
## SD Card
This board has an SD card slot.
<!-- TOOL NOTE: has_sd_card=True — CONFIG_MMCSD_SDIO=y in nsh/defconfig and
CONFIG_SYSTEMCMDS_SD_BENCH=y in default.px4board. The board uses SDMMC2
(CONFIG_STM32H7_SDMMC2=y). The sdio.c file in src/ confirms SD card
initialisation. -->
<!-- sd-source-data
{
"board": "amovlab/flycore",
"source": {"has_sd_card": true}
}
-->
boards: add Amovlab Flycore support
PR Description
Solved Problem
PX4 does not currently include an upstream board target for the Amovlab Flycore flight controller.
This means Flycore users need to maintain the board port out-of-tree in a downstream PX4 fork.
There is no linked GitHub issue; this is a new board port.
Solution
This PR adds board support for the Amovlab Flycore flight controller, an STM32H743-based FMU.
The new board support includes:
boards/amovlab/flycore/NuttX configuration, bootloader configuration, and board-level drivers (init.c,spi.cpp,i2c.cpp,timer_config.cpp,can.c, etc.)amovlab_flycore_defaultandamovlab_flycore_bootloadertargetsboard_id106 infirmware.prototyperc.board_sensorsBOARD_UAVCAN_TIMER_OVERRIDE=6because the buzzer uses TIM2 on PA15docs/en/flight_controller/amovlab_flycore.mddocs/zh/flight_controller/amovlab_flycore.mdThe board has no onboard magnetometer. External I2C1 and I2C4 are documented for optional user-installed GPS/compass modules.
CONFIG_COMMON_MAGNETOMETERis enabled so compatible external compass drivers can be started manually from NSH, but the default firmware does not start any magnetometer driver.Changelog Entry
For release notes:
Alternatives
CONFIG_COMMON_MAGNETOMETER,CONFIG_COMMON_INS, orCONFIG_MODULES_UXRCE_DDS_CLIENTto reduce flash usage. The current default build uses about 94.6% of the 1920 KB application flash region.SYS_AUTOSTARTvalue forFLYCORE0000.Test coverage
Build environment:
arm-none-eabi-gcc10.2.1Build tests:
make amovlab_flycore_default— passmake amovlab_flycore_bootloader— passHardware tests on Amovlab Flycore with the default firmware:
ver all— reports:HW arch: AMOVLAB_FLYCOREHW type: FLYCORE000000HW version/revision: 0x000listener sensor_accellistener sensor_gyrolistener sensor_barosensor_magis published unless a user starts an external compass driverboard_id106 — OKContext
make amovlab_flycore_defaultmake amovlab_flycore_bootloaderboards/amovlab/flycore/amovlgf:pr/amovlab-flycore-boardFlycore is similar to Pixhawk 6C class FMUs, with the following board-specific differences: