Hi all. Among the two F745 autopilots that ArduCopter is now supporting, the Kakute F7 is seeing extensive use while the Omnibus F7 is apparently less well used or documented. I am planning a build with the latter, so here I’d appreciate if somebody could sanity check my setup / wiring.
By reading the hwdef I have worked out the wiring as follows:
USART1 -> Telemetry Radio
USART2 -> SBus (If a PPM signal is connected to the SBus pin, does the autopilot auto-detect PPM?)
USART3 -> Pins used by I2C for external compass
USART6 -> GPS
USART7 -> BlHeli32 telemetry
A crude diagram is prepared too. Don’t hesitate to point out errors, I’ll correct any immediately.
I don’t think there’s a specific reason why Kakute is more popular than the omnibus F7 in the community. Pros and cons to each: the omnibus has dual imu’s which is nice, the Kakute is easier to solder to in a quad (at least the version I have).
From a development and support perspective, Holybro are more engaged with the dev team.
Re ppm, I haven’t tried but had assumed it would work, as ArduPilot auto detects protocol on the rc input. The reason dsm is sometimes different is that you need to be able to toggle the power pin to put it in bind mode.
Re Here2 baro: I’m not sure it’s exposed by the current firmware on the gps, but if it is then you’d have to check it doesn’t conflict with the onboard baro. @proficnc
Could be the reason that on Kakute you have PWM5/6 exposed, for camera trigger and pitch control, for example.
On the Omnibus as it is it’s impossible to use the HERE v2 baro. MS5611 is linked via SPI to its internal F3 microcontroller. One would need a CAN transceiver mounted on one Omnibus serial port to use the HERE v2 in CANBUS mode, granting access to its 10DOF IMU. But even if the MS5611 inside the HERE was acessible via I2C, alongside the mag (which in I2C mode is not connected to the internal F3 uC) it wouldn’t’ve conflicted with the Omnibus baro - BMP280 - which resides at a different address. I haven’t run into a dual-baro setup so far, so I don’t know if there’s a bitmask parameter to adjust to be able to disable one or the other, but in a normal build, having one baro in the GPS, above the propellers plane, and one on the FC, below the propeller plane, with different air-current shielding is only going to make EKF unhappy.
PPM input is defined by software, not by a silkscreen print. If it works on Omnibus, it will also work on the Kakute. For ArduCopter it’s an USART RX pin on the F7 chip, simple as that.
I’ve fiddled some with RFD radios, and I’m not impressed. For their (illegal in my country) 1W power the performance is not so impressive compared to good-quality 100mW legal radios. Don’t even try to compare them with the likes of TBS or FrSky R9 without some fancy directional antennas and tracker. And their choice for PPM instead of SBUS, blows my mind.
Thanks for the intel on the HERE v2! My original hope was that by using the HERE’s baro, enclosed inside the GPS module’s casing, I can bypass entirely the exposed baro on Omnibus/Kakute-type boards.
Roger that about PPM. To lay the issue to rest, can anyone with a Kakute try to confirm that using actual hardware?
I beg to differ on the RFD point. RFD900X is mainly a telemetry system with PPM passthrough, while TBS / R9M are mainly RC systems with very limited telemetry capability. In my case, long range telemetry is more important. It seems that Dragonlink is the only alternative for long range RC and telemetry in one RF link, but that is too expensive.
though the baro in the Here2 is connected via I2C, it is possible to emulate the I2C in the F302… Can is a better option… and will be available soon… all the code will be available soon for the here2, just a bit flat out on the herelink at the moment, but will get to it ASAP
