While it is highly unlikely that QuadF7 will meet its crowdfunding target on Indiegogo despite being my most successful campaign to date. It will however live on as a creative commons (CC-BY-NC-SA) project here. The Indiegogo campaign does not cover everything due to me not wanting to over-promise and under-deliver, but there were certain features that I added to the board that if works, will be great.
Base Flight Controller
First thing we will look at is the base controller. I've used the STM32F746NGH6 MCU due to its size. While harder to work with on a hobbiest scale, the TFBGA footprint saves 1mm from each edge of the package, over the LQFP package, and spreading the traces across the package has allowed me to maximise the pace used. This allows the centre of the flight controller to be shrunk to 26.6x26.6mm. Placing the typical 4 outputs for quads onto the mounting hole arms contributes to this reduction. The F7 was chosen in place of an F4 due to the F4 not containing inversion circuitry for UARTs. Like F3 and previous generation MCU's the F7 reintroduces this feature which saves some BOM cost and allows all serial ports to be used for any function unlike F4 FCs which have a dedicated SBUS port.
Due to reliability issues on other FCs the Quad F7 does not have a built in BEC, however can accept a supply from 3.4v-6v although 5V is recommended for powering a locator buzzer or RX. The FC is capable of being powered from USB or the 5V(+/-) input. USB power and 5V inputs are isolated from each other up to 20V to protect each other from voltage spikes and include reverse polarity protection.
USB is provided by direct connection to the MCU and communication with betaflight is achieved through the virtual communications port meaning that USB does not take up any of the UARTs available like in F0/1 boards, and some F3's. The FC also provides 3 UARTs which can also be used for RX connection. UART2 is designed for use with RX but any can be used except for with speksat where the T2 is designed for use as the bind plug.
While designed around quadcopters, there are 6 motor PWM's. 4 on the arms in a standard quad copter pattern and one each at the front and back. These are capable of all the communication modes available in betaflight including DSHOT.
There are pins for battery and current sensors also available on the board. Due to not using an integrated BEC a separate connection to VBAT is required. The safe input range of VBAT pin is 0-36v covering all packs from 1s-8s. There is a current sensor input also available. The current sensor input can take an output from a current sensing IC from 0v-3.3v. Scale of current measurement depends on the sensor. The PDB designed to match with this FC supports a current draw up to 70A safely.
Inertial Measurement Unit (IMU)
The IMU in the V20170212 design is untested in FC applications. This was one of the largest unknowns in the design. This design is going to test whether this IMU is capable of being used in an FC. I do have a backup design using the ICM-20608-G 6-DOF IMU, and a separate magnetometer if it doesn't work to expectations. The current design however uses a 9-DOF all-in-one IMU that includes an accelerometer, gyroscope, and magnetometer. Both designs read the data over SPI for the highest possible speed, and are centrally mounted for accuracy. The LSM9DS1 is an interesting IMU and I'm hopeful that it will work as intended.
Most of the other features are reasonably standard inclusions, like a button to boot into DFU in case of emergency, and flash memory for the black box. There is also a barometer for altitude-hold, and another device that I plan on testing to see how it works out.
A black box is a standard inclusion in most of the current F3 and F4 designs and this is no different. Some use NOR, others use a microSD card. While the reduction in size down to the 26.6x26.6mm core brings a reduction in weight, and in many mini-quad's brings the wire connection well inside the protection of the frame, there are some negatives. One of these is the inability to use a microSD card for the black box while keeping the card secure. Some push-push connectors will fit in the existing design, but push-push can easily lose a card from vibration or the forces experienced during operation. One option is a hinged microSD slot that locks into place, but there simply isn't enough room to accommodate this within the footprint. The compromise is 256Mbit/32MB of NOR which should be enough to store up to 20 minutes of flight data at 1kHz.
The barometer for altitude-hold is unremarkable in every way. It already has a driver in betaflight and has featured on other flight controllers before. There is nothing unique in its inclusion in this design. However one issue with using a baro for altitude hold is at lower elevations from the ground the inaccuracy makes it difficult to hold close to the ground. One solution for this is sonar. Sonar is a reasonable solution. Rated for up to 4m, but sonar does have issues with prop wash. Reasonable estimates are that sonar is accurate up-to somewhere between 1 and 2m from the ground.
My problem with sonar is that the sensors are bulky, and add a significant amount of weight to any frame. Something that the QuadF7 will test is a near IR time-of-flight sensor. It is rated with a 1.5% accuracy up to 2.3m with some conditions affecting its ranging distance. Best of all it has a 4.4x2.4mm footprint and contributes very little weight. This needs further testing and is one of the features I am most excited about. If it works well it is a very low cost alternative to sonar.
While not required for QuadF7, this is my recommended PDB design. For frames with a cutout under the PDB/FC mounting point this also contains a cutout to match the QuadF7's optical ranging sensor. It includes a current sensor which can output up to 5v. The PDB is only designed to handle up to 60A of current draw which will output a 3.3v signal for the flight controller. Also included is a 5V BEC with twin outputs. The regulator footprint supports 2 TI parts which are identical other than one is a low noise regulator. I recommend the low noise version if you intend on driving any FPV gear from the power supply. The circuit maker project for the PDB is available here
Software and Hardware
Next step for the software is to write drivers to support the currently unsupported IMU, Magnetometer, and optical ranging sensor for betaflight along with adding support for the board. A port to iNav is also a future option due to the better handling of baro/mag that exists in that tree.
For hardware the only direction forward is to build and test. The following link is the design available on OSH Park. These designs can also be downloaded from their circuitmaker project pages and made with your favourite board house. Currently the BOM requires multiple vendors to satisfy all requirements. I will be working on producing a list for Mouser/DigiKey/Element14(Farnell)/Arrow that allows you to get the required parts from the one provider so you only need to pay shipping once.
Please note: that while the designs are licensed under the non-commercial condition of Creative Commons
If you like my work you can tip me here