Could someone please guide me to hardware, Circuit schematics and documentation to build my own flight controller that is compatible with ardupilot?
I’m planning to make flight controller based of RP2040 which is a 32-bit dual ARM Cortex-M0+ microcontroller. This should also communicate with companion computer like raspberry pi.
Thanks for the reply.
I have some experience with electronics and drones but not to the extent that I could write custom HAL. I thought I could retrofit but I was wrong.
If you want we can try. I am software developer and electronic too. I am interested but need more free time.
Actually ChibiOS have some support for RP2040, so we can use the ChibiOS HAL already included on Ardupilot.
Bumping this thread in light of terrifyingly unending STM32 shortage for the commonners
RP2040 has fantastic stock health and price point at the moment, really unbeatable in the environment where MCUs pop out of shelf availability overnight.
I’m seriously considering doing the porting, but I’m a SW developer with limited hardware design experience, so if that is something that has a wider appeal, maybe someone can assist? For now I’ll probably just dumping questions aloud here.
For now some back of the envelope thoughts and questions:
RP2040 has 30 GPIO spare pins. ADC is only available on 4, so I’d reserve that for analog tasks. If we are up to design a multipurpose board, following Matek logic that would be battery voltage, battery current, analog RSSI and something else (analog baro? saw that in F405TE definitions, but is that actually used?)
There are 2 I²C controllers available without going PIO, is there a practical reason to use both, has anyone had experience when a single bus was inadequate in Ardupilot application?
We probably need SPI for IMU and for flash/µSD. Again looking at Matek F405TE those two are on seprate controllers with DMA priority for IMU. Is this critical? Having 2 SPIs can eat a lot of spare pins.
RP2040 uses an expernal SPI flash chip (up to 16 Mb as per datasheet), it can probably be reused for dataflash purpose. It’s connected via a dedicated QSPI controller. I’m unsure if one can daisychain anything else to that. Any input here is really welcome.
Out of the rest we can have up to 16 PWM outputs. Datasheet states there’s an option for PWM input too so that probably can be used for “hardware accelerated” sonar readings maybe? But it ovreall looks very niche.
Do we need hardware flow control of UART for anything? There’s reservation for that on Mateks on one UART, but so far all I’ve seen online in Ardupilot context is complaints, but maybe I wasn’t looking diligently.
For the pins, we can use PIO to have each pair of pins as U(S)ARTs or CANs (or something else, but I doubt we need a third I²C etc). There are a total of 8 state machines, IIRC we need 1 for UART/CAN, but I may be wrong. Theoretically this gives us up to 10 UARTS (2 hardware + 8 PIO) or up to 8 CANs.
UART/PWM decision can even be done by the end user and configured in software if we don’t want to lock the free GPIO function split beforehead. CAN requires transeivers so I’m unsure if we can have those onboard with this flexibility. Maybe reserve 2-3 CAN pairs with transievers on, but also route the pins before going into transievers to be able to be used as a spare UART/PWM.
Unsure if this leaves us any spare GPIO for relays in a typical Ardupilot application, so might be a good idea to use an external I²C GPIO extension IC since relays are “dumb” GPIOs that don’t need much bandwith.
No FPU means we might not be able to run Copter or QPlane since the loop is scheduled at much higher rate than plane’s 50 Hz. Kind of a bummer, but we have a second core so might as well put heavy math completely in the background, also the RP2040 ROM contains optimized floating point functions.
ChibiOS fork is lagging behind the upstream support of both RP2040 and multicore operation. Might be a good idea to create a separate HAL for now like there is one for ESP32 just not to mess with updating ChibiOS that might affect another targets, but I’ll be trying both ways to see whichever is less messy.
If you really wanna work on it then we can gather a team who are interested and get things goings. RP2040 is very cheaply available in the market. It would balance out the drastic price fluctuations we are currently looking at the FC market
What is a “flight gyro” for you?
ArduPilot uses gyroscopes and accelerometers for the past 15 years, so its already developed. What exactly do you mean? Be specific and explicit.
That product exists in the form of a fairly cheap gyro-enabled RC receiver and is nothing new or complex. You don’t need ArduPilot if you just want basic stabilization, and you don’t need to invent anything new.
