I’m planning on gathering information and knowledge to begin designing my own flight controller for a project. The goal is to design an integrated solution for a smaller drone where we fit all on one board. I’m looking for some general advice and pointers to where I should start learning.
If I understand correctly, the FMUv3 and FMUv5 for example is a standard for the hardware itself. Which pins on the processor goes where. So if a board would be designed according to for example the FMUv5 standard the general FMUv5 firmware should in theory work on that board?
I myself won’t design the board since I don’t have the necessary experience in ECAD. The designer though has never worked on flight controllers or arducopter so I’ll need to collect all the bits and pieces of info for him.
So far I’ve found a github from holybro with the FMUv5 standard is explained. I don’t understand all of it but is that enough for someone with ECAD experience to design an arducopter compliant board?
Any pointers and experience is greatly appritiated!
If you copy open schematics board schematics and sensor orientations and do your own layout it will be the same as the original board as far as the autopilot is concerned.
Matek and likely others have multiple boards using the same target.
Where can I find open-source layouts? I want to use the board with Skybrush. They use a slightly modified version of arducopter and has only made compatible versions for a smaller range of boards. That’s why I was hoping the FMUv3 or v5 had schematics to go along with it.
Maybe I’m thinking of it all wrong. Never the less, where can I find some open source schematics to have a look at?
I don’t know about that. Since Ardupilot gave the boot to Droncode I have paid little attention. My comment about being a Foundation member was sarcasm.
Download | Holybro Here you can find the schematic of “FMUVX-Base”. I guess it is the base schematic from which all FMU versions are made. This in combination woth the required fmu version standard may be helpful to you.
Also, if you search, you can find the schematic of fmuv3 in github
One additional comment on this. All those “standard” boards have IOMCU’s which IMO have been a useless appendage for multirotor’s and I would guess true for your application also.
Yes an IOMCU would be a waste of space on our application as well. But as of right now we just need to fit an FC on our board along with all the other stuff.
Along the way when we’ve gathered some real experience designing boards we might make our own entirely. Right now the copy paste solution is fine.
Not sure about that. As long as an fmuv3 hardware is used, I think an fmuv3 firmware will work. Use whatever firmware is recommended for the Pixhawk Mini
We are using existing hardware right now. The custom board will be more than just the FC. Lots of the external components like BECs and wifi module will be integrated.
To be honest, I would also like to go for available hardware for a bit longer but I’m not the only one making decisions in this project. So the custom board is kind of a side quest right now.
Seems to me that dropping a 30x30 board onto a custom PCB with your other components would make sense. A Matek H743-Slim, Lucid H7 for example. Unless a cheaper F4 will do. I don’t see much reason to use anything called a Pixhawk.
I hope you know that when you put high current stuff along with low current, sensitive stuff like sensors, you need to appropriately partition your board into sections and routing the high current traces on a different layer of the PCB. And it’s better to use a dedicated LDO for sensitive sensors like the IMU. If it is a prototype, @dkemxr’s advice to have an off-the-shelf FC as a plug-in daughter board is the least time consuming.
One such method is designing a custom carrier board for Cube and similar autopilots. Still requires care to separate high current and noisy traces, but it’s a far cry easier than starting from scratch.
CubePilot isn’t the only modular autopilot on the market, and the “horribly limited” statement is very much a matter of opinion and use case. I’m not sure how an FMUv5 standard board would have fewer limitations…