Ardupilot on OpenPilot Revolution - Page 185 - RC Groups
Thread Tools
May 13, 2018, 12:04 PM
Registered User

FRSKY passthru telemetry on Omnibus F4 Pro V3


FYI, I just verified that the FRSKY passthru telemetry is working fine.....Using the YAAPU LUA script (https://github.com/yaapu/FrskyTelemetryScript) on my Taranis for the first time....very cool!

Craft&Theory kindly sent me a cable (thanks Florent)....it will be here tomorrow....however, I jury-rigged a dual inverter adapter for UART1 to SPORT on my XSR since I had time on my hands....it allowed me to verify that FRSKY passthru was working on the bench using YAAPU script....will test fly next week when my new Omnibus F4 FC arrives (I smoked mine by accident) and the neater C&T cable will allow it to be used in the Z-84....

EDIT: Cable came...very small...works great and fits well in my smal Z-84 wing
Last edited by Atx_Heli; May 14, 2018 at 01:27 PM.
Sign up now
to remove ads between posts
May 14, 2018, 08:57 AM
Registered User
wkf94025's Avatar
I downloaded latest binaries (29bba65) and tried the new Omnibus V3 (Plane) on my FC. It flashes okay, boots okay, but then trying to save a few parameters, it's no longer recognized by Windows when I plug it back in to USB after power cycle. I reflashed the AirbotV2 firmware, and it behaved normally. Everything working on the AirbotV2 setup except GPS. SBus in, airspeed sensor on I2C, battery and current pins setup. Is it possible that @sh83 fix on master could be applied to SBus-in / GPS conflict under F4Light system for these Omnibus V3 boards?

Kelly
May 14, 2018, 09:36 AM
Registered User
The same fix already applyed to latest f4light build. Something strange going on here.
May 14, 2018, 10:09 AM
Registered User
NG what exactly is the difference between the OmnibusV3 and AirbotV2 builds? up till now we've been using the AribotV2 build for Omnibus Pro V2/V3 boards....

the boards read.me files are identical


also, myself and at least one other user of the Omnibus Pro V3 have experienced that the 5/7/2018 version apparently has an issue with navigation not longer functioning....everything else seems fine, but no Loiter or RTH...just keeping flying straight,even though OSD home distance and direction display correctly.....we have arming checks in place (except INS) and are using DCM....the 4/13 version seems to work fine except for OSD RSSI display....

any suggestions on how to proceed?
Last edited by Atx_Heli; May 14, 2018 at 10:18 AM.
May 14, 2018, 10:14 AM
Registered User
New target was made for non pro omnibuses(without current sensor). The only difference is (hopefully) working uart6 on omnibus f4 v3(nonpro).
May 14, 2018, 12:08 PM
Registered User
Quote:
Originally Posted by Sh83
New target was made for non pro omnibuses(without current sensor). The only difference is (hopefully) working uart6 on omnibus f4 v3(nonpro).
the pin defines are the same for these boards in the code (except I2C which is changed to a piname instead of pinnumber)....so I still dont know what the difference really is...

in my post https://www.rcgroups.com/forums/show...postcount=2171 I list the board versions that I am aware of...

the noncurrent sense boards (Airbot calls them AIO boards...the cloners sometimes call them Omnibus Pro Vx boards).... early versions have an inverter from RX in to UART1 (these use f4light_AirbotV2) for SBUS with iNav/BF,etc. which is not needed with this firmware, just like the current sense ones do...they are electrically the same except a current sensor is on board and attached to the CUR input pin)....most of the clone boards are V2 or V3 board copies....after V3 Airbot moved the inverter from UART 1 RX to UART6 RX (at this point I am not sure which firmware runs on this board....the WIKI is incomplete for this board....perhaps the new Omnibus firmware is targeted at this, but I dont see any board define differences)....Airbot Omnibus AIO F4 V5 is this style as is RTFQ FLIP 32 - F4 - OMNIBUS V5

As far as I can tell the F4light_Airbot code targets the first rev (OA) of the Airbot F4 AIO board which had no SD card and the board defines imply that data flash is used for logging...but I could be reading the board define files wrong....

it would be really nice to understand the basic differences between the two, now three versions for the Omnibus F4 boards....with details as given in the PRO wiki for the board....

if the RX is attached to the PPM path, then the sbus inverter will not interfere with the UART its attached to and that UART can be used together with the remaining UART for telem and gps....

I know how to setup for the PRO boards , and clone non-current sensor boards....but not the V5 non-current sense boards which have the inverter from RCVRin to UART6 rx...
May 14, 2018, 02:18 PM
Registered User
wkf94025's Avatar
Helpful info @Atx_Heli. I agree it would be great to get all the Omnibus variants understood. I have a V3 (bought off Amazon/Crazy Pony) and two V5's (sent direct from Airbot). Still scratching my head on the differences between V3 and V5 w.r.t. SBus/PPM selection. On the V3 it's the either/or solder pads. Unclear on the V5. Most interested in finding a path for SBus in that doesn't burn a UART, so I can have GPS and bi-directional telemetry, as well as I2C.

Kelly
May 14, 2018, 03:22 PM
Registered User
wkf94025's Avatar
I traded PM's with @teralift a few weeks ago, and wanted to share one of his responses that may be of benefit to those here trying to solve for SBus-in/PPM-in without sacrificing a UART:

Re: Can't get GPS working on Omnibus F4 V3 or V5

Using PPM to free up UART6 is possible.

Below is a Airbot F4 / Omnibus F4 AIO (gen 1), but idea is the same.
https://www.rcgroups.com/forums/show...-Accessing-PPM

ALL variants of Omnibus with three UARTs shares one of them with SBUS.


Kelly
May 14, 2018, 07:31 PM
Registered User
Quote:
Originally Posted by wkf94025
I traded PM's with @teralift a few weeks ago, and wanted to share one of his responses that may be of benefit to those here trying to solve for SBus-in/PPM-in without sacrificing a UART:

Re: Can't get GPS working on Omnibus F4 V3 or V5

Using PPM to free up UART6 is possible.

Below is a Airbot F4 / Omnibus F4 AIO (gen 1), but idea is the same.
https://www.rcgroups.com/forums/show...-Accessing-PPM

ALL variants of Omnibus with three UARTs shares one of them with SBUS.


Kelly
Kelly, I am not sure the relevance of this....Teralift was showing how to access PPM in pin for other exotic uses...

on ALL the Omnibus boards, current sensor or no, the Reciever (be it SBUS, PPM, or DSM) should be routed to the PPM input of the processor and not to the SBUS inverter input, in order to free up the UART (normally UART1 on every board except the Omnibus F4 AIO V4 or V5) for telemetry...


the wikis state this clearly

you have said that you are using a V5 AIO board....to my knowledge, there is no firmware available for that board....the Omnibus variant has appeared i the last build but NG has not stated the details of UART assignments and its target yet on this thread (the new Omnibus board pin defs still state that the inverter is on UART 1 not UART6 as is the case...maybe somewhere else is its properly assigned in the code)....it would need to use the direct PPM input for whatever type of receiver....assignment of UART1/6 to Telem and GPS is up to the developer....UART3 conflicts with I2C bus used for compass or digital airspeed


perhaps NG will tell us that information...
May 14, 2018, 08:37 PM
Registered User
wkf94025's Avatar
I will respond in more depth later, but NG's AirbotV2 firmware is working well on the Omnibus V5. Just need to solve the SBus/UART conflict, so I can get GPS, telemetry, and I2C airspeed.

Kelly
May 16, 2018, 08:33 PM
Registered User
Well, here are my results........

Z-84 with an Omnibus Pro V3.

U-block M8N GPS, L9R receiver, 4S LiOn battery pack, Runcam Eagle 2, Aomway 5.8G VTX

- GPS was running fine
- RSSI was working via RSSI pad and pin 47 and very stable
- telemetry was working via UART1 (and selecting PPM instead of SBUS pads)
- OSD was working, although it seems to switch screens very shortly by its own, as i regularly saw message "screen 1", which normally only appears after purposely switching screens, which I was not

I am new to Ardupilot, so I had a few other observations:

- loiter radius and RTL radius was very large. Even when setting both to 20m in the configurations and have a max banking angle of 60 degrees the autopilot only commanded a much larger radius than set and larger than what the plane is capable of. The loiter radius was little over 100m in reality

Is there any other setting which controls this radius ? As the accuracy of the radius is good, just way too large.

When flying normal WP's the autopilot is using much tighter radius.


So far, kind of good.

All auto modes were working, including auto launch and auto landing.


Then i tried a failsafe by switching off the transmitter. The RTL function was already tested several times by manually selecting it. I did have problems with the L9R to set the failsafe at the receiver to induce a throttle failsafe, so it was still at the setting that it did not output SBUS signal when failsafe, which is a condition which is recognized by INAV, which I was running before with no problem whatsoever.

Also now the RTL kicked in and the plane came back. Upon arriving at the home point it started loitering as expected. However, whatever i tried, i could not regain control with the RC transmitter !!! In the OSD I could see that RSSI went up after switching the transmitter on, but for some reason the FC did not react.

I tried everything I could, even frantically doing a search on internet what could be the reason, but at the end only could wait till the battery died. With the LiOns that took almost an hour.....

Because of the earlier mentioned large RTL loiter radius the plane eventually ended up very, very high in a tree at a golfclub, where it still is now as there was no way to reach it. Hopefully the regular hard winds will bring it down sometime........


What can be the reason that I could not regain control ? Did the FC not recognize the sudden re-appearing SBUS stream anymore ? I have been using many different autopilots and this is the first time I do encounter this. I am very enthusiastic about the options which Ardupilot is giving, but this is the first plane I lost in many years of (long distance) FPV flying and I did not make me happy.........


Any pointers are appreciated


Ro
May 17, 2018, 05:08 AM
Registered User
vierfuffzig's Avatar

Ardupilot on OpenPilot Revolution


@ roald:

your effective loiter radius is determined by various parameters, mainly your airframe's aerodynamic limits, as well as the preset bank angle limits to avoid critical flight situations, plus an altitude scaling. while your individual airframe might be physically capable of maintaining a 20 m circle radius with no wind at sea level, the demanded radius likely exceeds the preset bank angle limits to maintain this course, even more so at a given altitude with non-zero wind conditions. mind that 20 m is less than half of the preset value. with the stock settings of 50 m, a typical ~50" wing achieves a real 60 m loiter radius at 100 m altitude, maintaining a near perfect circle regardless of 3-4 bft sindewinds:



reviewing the logs usually is quite helpful with nav and control tuning.

regarding your issues regaining control from long failsafe triggered rth, maybe take a look at the documentation: http://ardupilot.org/plane/docs/apms...-function.html

short fs will typically return to previous state automatically upon regain of control signal, while long fs rth will prevail throughout regained rc signal until flightmode is changed. testing not only getting into, but also getting out of failsafe prior to flight is quite essential though...



cheers, basti.
Last edited by vierfuffzig; May 17, 2018 at 06:01 AM.
May 17, 2018, 07:28 AM
Registered User
Hello,

has anyone a input/output pin definition for the Matek f405 CTR ?
( an frsky xsr receiver is considered here)

many thanks.
Last edited by _Tony_; May 17, 2018 at 07:33 AM.
May 18, 2018, 07:07 PM
Registered User
vierfuffzig's Avatar

Ardupilot on OpenPilot Revolution


@nightghost:
i‘ve been doing more testing on airbotV2 as well as osd v944 standalone and have been able to reproduce a systematic home arrow deviation on onboard and standalone version. i have a couple of standalone osds in use that all run v918 and have never shown any homedir issue of that sort.

what i did was let the board acquire sat fix, move away from home point a couple of meters and then slowly and steadily turn clockwise. this is fc yaw log:



the heading rose consequently and correctly showed a steady bearing increase.

the home arrow should have shown a steady turn counter-clockwise with bearing decrease, but it displayed a repeating systematic error:

https://vimeo.com/270784935/dce811eba9

it completely neglects bearings above 255°. when reaching 0°, it jumps straight to 255° on the first approach and back to 100° on the second turn. as the issue is present on standalone and onboard and it was introduced somewhere between 918 and now, but homedir panel code has not relevantly changed since then, i suspect a bug in osd_home_dir calculations‘ variable definitions. with the limitation to numbers up to 255 i wonder if there could be an erratic uint8_t somewhere?

it would be awesome if we could get this fixed.

cheers, basti.
May 21, 2018, 03:14 AM
Registered User
wkf94025's Avatar
I received a Matek F405-Wing last week and tonight was able to flash the ChibiOS ArduPilot on it and get SBus in working as well as air speed on i2c. Night_ghost has some work underway for this controller, but no binaries yet. Looking forward to trying both HAL's on this flight controller.

Kelly


Quick Reply
Message:

Thread Tools