Passthrough telemetry over CRSF (crossfire)

yaapu · October 19, 2020, 2:19pm

thanks @vierfuffzig , that explains why you only get the warning and we do not enter failsafe, found the code here, should have looked better

/*
  return true if throttle level is below throttle failsafe threshold
  or RC input is invalid
 */
bool Plane::rc_failsafe_active(void) const
{
    if (!rc_throttle_value_ok()) {
        return true;
    }
    if (millis() - failsafe.last_valid_rc_ms > 1000) {
        // we haven't had a valid RC frame for 1 seconds
        return true;
    }
    return false;
}

vierfuffzig · October 19, 2020, 8:12pm

@yaapu tested latest code, basically the same behaviour as before. can’t wrap my head around the performance discrepancy on USART1 vs other UARTS

USART1: constant rate of 150 no matter what
other UARTs: basic rate of ~10 - 15, increasing to ~ 50 when USB connected (just plugged into PC, no active MAVLink connection). stalling to ~ 2 over time
intermittend No RC Receiver flags and unmotivated RMFD switching

my individual guess is that this is a melange of ardupilot UART handling and CRSF bandwidth saturation issues. without any profound insight, i don’t think we should lose valid RC Input for more than 200 ms unless intentionally choosing a low update rate.

two more points i noticed while testing:

the (dis-)armed panel consumes a noticeable amount of your insanely awesome map widget.
passthrough sensor_status_flags information is pretty verbose and cautious regarding severity level rating where the base-code is a bit more tolerant. i’ve noticed constant "CRT: Bad AHRS" flags, likely due to using_gps being flagged on my no-compass setup until EKF yaw gets aligned to GPS velocity vector. quite some effort has gone into avoiding the “Bad” label on an expected process. might be an option to use the “healthy” flag here instead.

yaapu · October 20, 2020, 7:04pm

Hi @vierfuffzig , one more version to test, this one should be much better, I relaxed a constraint that should not be necessary on full duplex link (discussed this with @andyp1per)
arduplane_matekf405wing_v2.zip (631.1 KB)

yaapu · October 20, 2020, 7:08pm

did you actually arm the vehicle? that huge disarm dialog goes away ad only comes back on next disarm, it never bothered me but since it’s pretty big I can understand that could disturb

Those “verbose” errors are there from the original authors of the library, it might be time to refresh them with updated messages

vierfuffzig · October 20, 2020, 8:29pm

@yaapu yes, i did arm, honestly i expected the disarm panel to go away when armed, but it didn’t. i’m a try again, maybe i just was too impatient

will try new version asap, thanks for your constant effort on this!!!

vierfuffzig · October 20, 2020, 8:55pm

@yaapu ok, the panel goes away when is_flying

vierfuffzig · October 20, 2020, 9:23pm

@yaapu aaaaaand MASSIVE improvement on last version!

USART1: packet rate ~ 160, no issues
UART3: packet rate ~60
no stalling
no change with USB connected
no relevant performance decrease compared to 160 frames on USART1
no more RC Input flags

on a sidenote DBG reports RFMD 2 though CRSF is in RFMD 1 (tested at distance with low output power / force telemetry mode)

awesome, thanks a lot!!!

yaapu · October 20, 2020, 9:26pm

finally good news, perhaps we have a version to fly

mhmm, what does the widget display on the top bar RS:[rssi]/[rfmode] ??

vierfuffzig · October 20, 2020, 9:44pm

crsf direct, ardupilot crsf and passthrough tlm (script link panel) report RFMD1, only DBG seems to always report RFMD2

…additionally, further testing revealed that the CRSF NanoRXes signal pins are not 5V-tolerant

yaapu · October 20, 2020, 10:14pm

ok @vierfuffzig , I’ll try to reproduce it

yaapu · October 21, 2020, 6:53am

…and you found it out the “wrong” way, I’m afraid

andyp1per · October 21, 2020, 8:27am

I’ve already flown this on my Y6B

master-of-desaster-8 · October 22, 2020, 12:12pm

Hello Alex,
very impressive project. The last summer I use for the RC channels the TBS and for the telemetry the FrSky. This works fine and so far no lost on planes. Exept that one’s where the failure whas between the ears.
I like the idea to have evertything on one RX/TX system. The Horus should be just a joystick and screen.
So I installed Your latest version on a plane and get it running so far.
From Ardupilot I use a Pixhawk 1 on that plane and from TBS a micro V2 receiver.
Firmwares:

Open TX: 2.3.10
ArduPilot: your latest repo 0.7
Horus: 190b_0.7
TBS: V3.72

Normaly I run this Pixhawk as s FMUV2. But if I compile it I get no telemetry connection. If I compile it as a Pixhhawk 1 it will work as wirtten in this thread.
As next I like to install the firmware on a “Holybro Durandal” for the next plane. For my understanding the telemetrie should run on all suported hardware.

Second question - is there a posibility to get the FrSky sensors on the Ardupilot or Crossfire?

At the weekend I will fly the plane to see how it will be work and respond.

Cheers, Markus

yaapu · October 22, 2020, 8:57pm

@master-of-desaster-8 Hi Markus, thanks for the kind words

Compiling for fmuv2 from my branch will not enable CRSF features, as you’ve found out you need to compile for Pixhawk1-1M or Pixhawk1.
The durandal has 2MB of flash and CRSF is enabled by default so it will work out of the box, I can compile it for you or you can compile it yourself.

As for frsky sensors in a crossfire ecosystem it’s not possible right now

yaapu · October 22, 2020, 9:01pm

@vierfuffzig I can’t reproduce this issue, but while testing I’ve found a minor bug on mode 2 custom telemetry rates, I’m building version 0.8 of my branch and in the meantime I built this for you with rate debug info enabled

arduplane_matekf405wing_v0.8.zip (631.3 KB)

VRquaeler · October 23, 2020, 2:00am

Funny,
I had exactly the opposite effect.
build my own,
changed this line

github.com

yaapu/ardupilot/blob/test/crsf_telem_passthrough/libraries/AP_RCTelemetry/AP_CRSF_Telem.cpp#L34


      
          #include <AP_SerialManager/AP_SerialManager.h>
          #include <AP_AHRS/AP_AHRS.h>
          #include <AP_Notify/AP_Notify.h>
          #include <AP_Common/AP_FWVersion.h>
          #include <AP_OSD/AP_OSD.h>
          #include <AP_Frsky_Telem/AP_Frsky_SPort_Passthrough.h>
          #include <math.h>
          #include <stdio.h>
          
          #if HAL_CRSF_TELEM_ENABLED
          
          // #define CRSF_DEBUG
          #ifdef CRSF_DEBUG
          # define debug(fmt, args...)	hal.console->printf("CRSF: " fmt "\n", ##args)
          #else
          # define debug(fmt, args...)	do {} while(0)
          #endif
          
          extern const AP_HAL::HAL& hal;
          
          AP_CRSF_Telem *AP_CRSF_Telem::singleton;

to get the debug output shown here:

Auto-detected serial ports are:
/dev/serial/by-id/usb-ArduPilot_omnibusf4pro_290030000A47373130373630-if00
Connecting to /dev/serial/by-id/usb-ArduPilot_omnibusf4pro_290030000A47373130373630-if00
Connect /dev/serial/by-id/usb-ArduPilot_omnibusf4pro_290030000A47373130373630-if00 source_system=255
Log Directory:
Telemetry log: mav.tlog
Waiting for heartbeat from /dev/serial/by-id/usb-ArduPilot_omnibusf4pro_290030000A47373130373630-if00
MAV> APM: Ground start
APM: Beginning INS calibration. Do not move plane
online system 22
INITIALISING> Mode INITIALISING
Init GyroAPM: RCInput: decoding CRSF
*APM: CRSF: custom telemetry initialized
**APM: Initialising ArduPilot
APM: CRSF: rf mode 0, rate 1
APM: Calibrating barometer
APM: Barometer 1 calibration complete
APM: No airspeed sensor present
APM: ArduPilot Ready
MANUAL> APM: GPS 1: detected as MTK19 at 115200 baud
APM: EKF3 IMU0 buffs IMU=17 OBS=7 OF=16 EN:16 dt=0.0200
APM: CRSF: rf mode 0, rate 115
APM: GPS 1: detected as MTK19 at 38400 baud
APM: CRSF: rf mode 0, rate 142
APM: CRSF: rf mode 0, rate 148
APM: ArduPlane V4.1.0dev (0b3bc7b4)
APM: ChibiOS: 331fe75d
APM: omnibusf4pro 00300029 3137470A 30363730
APM: RCOut: PWM:1-8
Received 1091 parameters (ftp)
Flight battery 100 percent
Mode MANUAL
APM: CRSF: rf mode 0, rate 148
APM: CRSF: rf mode 0, rate 148
APM: CRSF: rf mode 0, rate 148
APM: CRSF: rf mode 0, rate 148
APM: CRSF: rf mode 0, rate 148
APM: CRSF: rf mode 0, rate 148
APM: EK3: Changed EK3_GPS_TYPE to 1
GPS lock at 0 meters
APM: EKF3 IMU0 initialised
APM: CRSF: rf mode 0, rate 148
APM: EKF3 IMU0 tilt alignment complete
APM: CRSF: rf mode 0, rate 148
APM: EKF3 IMU0 origin set
APM: CRSF: rf mode 0, rate 148
APM: CRSF: rf mode 0, rate 147
APM: CRSF: rf mode 0, rate 147
APM: CRSF: rf mode 0, rate 148
APM: CRSF: rf mode 0, rate 148
APM: CRSF: rf mode 0, rate 147
APM: CRSF: rf mode 0, rate 148
APM: CRSF: rf mode 0, rate 148

The fullsize TX has shown: RFMD 2 on the OLED display on it’s back.

Don’t blame the old MTK19 GPS. just for bench testing…

Some more progress:
the RFMD indicator seems to work (different from my earlier tests)
yaapu_dev_01

Tested with fullsize TX on Frsky xLite.

jelkins · October 23, 2020, 2:13am

I can’t seem to get telemetry working. I have been testing CRSF protocol off the dev build of arduplane on multiple vehicles and haven’t had any problems.

I have switched to the current build here and discovering new sensors is not finding anything.
I can see on MP under messages the CRSF rf mode / packet rate msgs and have rc but am not able to get any telemetry on my T16 with crossfire full size module v3.78 & v4.05 and micro rx.
Not sure what I am doing wrong.

Shouldn’t there technically be two sets? the custom telemetry you have added and also the built in CRSF telemetry messages eg… attitude/gps/mode/batt?

Thanks for all the hard work btw!

James

VRquaeler · October 23, 2020, 2:18am

@jelkins
have you switched on RC_OPTIONS = 256 to enable crsf_passthrough ?

jelkins · October 23, 2020, 2:24am

@VRquaeler yep, my f405-wing was at 32 so 32+256=288… have also tried 286, had another f405 at 0 so tried 256… no luck yet.

VRquaeler · October 23, 2020, 2:26am

what about the switch in the yaapu-widget settings?
There is a dedicated switch for the crsf telemetry too.