Using an Omega 2+ with an expansion board as a fixed wing flight controller
-
Hey there,
I got bored over my summer holidays, so I drew out a design for a fixed wing 2 or 4 engine drone. As I am wanting to get back into coding, more specifically into coding with my Onion Omega 2+ that I got, played with, bricked, fixed, and never touched again, I thought to myself that if I could code a program that could run on my OO2+, that would go into the drone and actually act as a flight controller, wouldn't have to spend too many moneys on more expensive pre-built flight controller that might not actually fit my purpose. Plus coding experience with this would help me with developing other programs for my OO2+, mainly to do with rocket control and sensor use.So this is where this post, and by extension the reader, comes in. Do you have any tips for me in this projects developmental phase? What do you think I should do/use?
I will continue to update this thread with development as I go through the steps. Attached below is a first draft of what the drone would look like from the top. If need be, I can go into specifications of the drone, and other information about what I want it to do further down the line.
Drone Preliminary Design 1: [https://imgur.com/a/xEYRi]
Dankeschun,
Orion(I'm Australian, not German, please don't talk to me in German I will not understand you.)
-
@Nicholas-Coles
Sounds like a fun project. Good luck !!
-
@Nicholas-Coles
Most of these flight-controllers are based on STM32 uC for reasons of multiple PWM in and output ports, many IO leads, some A/D and D/A capabilities.
IMO, MT7688 isn't really a good fit.
-
Indeed, this is a bad idea.
A complex Linux system with many undocumented corners and unresolved bugs is the last thing you'd want for a flight computer. In the case of the Omega 2+ even simply compared to other boards with the MT7688 chip, there's also the issue that an error in the choice of the companion flash chip on the module means that if the MT7688 experiences an unprepared reboot (for example from a glitch, or a watchdog) without the flash chip power cycling, a disagreement of addressing mode means that it will hang and be unable to boot.
Actual flight controllers are quite simple computers. A few years ago they were typically 8-bit ATmegas or STM8's, though fortunately that era is now in the past. Today they are typically simple ARM Cortex M0, M1, or M3 parts, from the likes of STM, Gigadevices, Nuvoton, or Asia-only vendors relatively unknown in the west. These run with internal flash and ram and have the rich I/O that @ccs-hello mentioned. For these purposes they run simple main-loop style bare metal firmware, drastically simpler and more responsive than what you would get from a multithreaded architecture. If you're interested in experimenting with this the realm of tiny featherweight platforms, there are a number of published open source replacement firmwares for toys like the H8mini, CX10, etc - ironically, the smaller (and therefore twitchier) the aircraft, the faster the control system needs to be.
If you do choose to fly a system like the Omega 2+, it should be limited to optional features, for example, you might use it to log data that you'd like to have, but the loss of which would not cause the aircraft to crash.
-
@Nicholas-Coles said in Using an Omega 2+ with an expansion board as a fixed wing flight controller:
Dankeschun
look at the teensy 3.6., uNAV, Diymall Mpu-9250.
-
@Chris-Stratton said in Using an Omega 2+ with an expansion board as a fixed wing flight controller:
the smaller (and therefore twitchier) the aircraft,
The drone i'm designing is around 80cm wide, 50 long, and I don't need it to be particularly twitchy. I see what you mean about a system that needs to be simple, and very stable, so that a failure doesn't lead to a Rapid Unscheduled Disassembly. will comment again later when not busy
